Приветствую, Хабр! В этой статье будет инструкция по настройке DKIM/SPF/DMARC записей. А побудило меня написать эту статью полное отсутствие документации на русском языке. Все статьи на эту тему, которые были мной найдены, были крайне не информативны.
1. DKIM
DKIM (DomainKeys Identified Mail) - это метод e-mail аутентификации, основанный на проверке подлинности цифровой подписи. Публичный ключ хранится TXT записи домена.Зачем же он нужен?
DKIM необходим для того, чтобы почтовые сервисы могли проверять, является ли отправитель достоверным или нет. Т.е. защищает получателя письма от различных мошеннических писем (которые отправлены с подменой адреса отправителя).Настройка DKIM подписи и DNS записей
Для это нам необходимо создать пару ключей:Openssl genrsa -out private.pem 1024 //генерируем секретный ключ длинной 1024
openssl rsa -pubout -in private.pem -out public.pem //получаем публичный ключ из секретного
Или можно воспользоваться онлайн-сервисом, чего я крайне не советую.
Примером записей является
mail._domainkey.your.tld TXT "v=DKIM1; k=rsa; t=s; p=<публичный ключ>"
Где
mail - селектор. Можно указать несколько записей с разными селекторами, где в каждой записи будет свой ключ. Применяется тогда, когда задействовано несколько серверов. (на каждый сервер свой ключ)
v - версия DKIM, всегда принимает значение v=DKIM1 . (обязательный аргумент)
k - тип ключа, всегда k=rsa . (по крайней мере, на текущий момент)
p - публичный ключ, кодированный в base64. (обязательный аргумент)
t - Флаги:
t=y - режим тестирования. Такие отличают отличаются от неподписанных и нужны лишь для отслеживания результатов.
t=s - означает, что запись будет использована только для домена, к которому относится запись, не рекомендуется, если используются субдомены.
возможные:
h - предпочитаемый hash-алгоритм, может принимать значения h=sha1 и h=sha256
s - Тип сервиса, использующего DKIM. Принимает значения s=email (электронная почта) и s=* (все сервисы) По-умолчанию "*".
; - разделитель.
Так же стоит прописать ADSP запись, которая позволяет понять, обязательно должно быть письмо подписано или нет.
_adsp._domainkey.example.com. TXT "dkim=all"
Значений может быть три:
all - Все письма должны быть подписаны
discardable - Не принимать письма без подписи
unknown - Неизвестно (что, по сути, аналогично отсутствию записи)
2. SPF
SPF (Sender Policy Framework) - расширение для протокола отправки электронной почты через SMTP. SPF определен в RFC 7208 (Wiki). Если простым языком, то SPF - механизм для проверки подлинности сообщением, путем проверки сервера отправителя. Как по мне, данная технология полезна в связке в другими (DKIM и DMARC)
Настройка SPF записей
Примером обычной SPF записи является your.tld. TXT "v=spf1 a mx ~all"Здесь:
v=spf1 является версией, всегда spf1
a - разрешает отправляет письма с адреса, который указан в A и\или AAAA записи домена отправителя
mx - разрешает отправлять письма c адреса, который указан в mx записи домена
(для a и mx можно указать и другой домен, например, при значении a:example.com , будет разрешена а запись не домена отправителя, а example.com )
Так же можно добавлять и отдельные ip адреса, используя ip4: и ip6: . Например, ip4:1.1.1.1 ip6: 2001:0DB8:AA10:0001:0000:0000:0000:00FB . Еще есть include: (include:spf.example.com), позволяющий дополнительно подключать spf записи другого домена. Это все можно комбинировать через пробел. Если же нужно просто использовать запись с другого домена, не дополняя её, то лучше всего использовать redirect: (redirect:spf.example.com)
-all - означает то, что будет происходить с письмами, которые не соответствуют политике: "-" - отклонять, "+" - пропускать, "~" - дополнительные проверки, "?" - нейтрально.
3.DMARC
Domain-based Message Authentication, Reporting and Conformance (идентификация сообщений, создание отчётов и определение соответствия по доменному имени) или DMARC - это техническая спецификация, созданная группой организаций, предназначенная для снижения количества спамовых и фишинговых электронных писем, основанная на идентификации почтовых доменов отправителя на основании правил и признаков, заданных на почтовом сервере получателя (Wiki). То есть почтовый сервер сам решает, хорошее сообщение или плохое (допустим, исходя из политик выше) и действует согласно DMARC записи.
Настройка DMARC записей
Типичная запись выглядит так: _dmarc.your.tld TXT "v=DMARC1; p=none; rua=mailto:[email protected]"В ней не предпринимаются никакие действия, кроме подготовки и отправки отчета.
Теперь подробнее о тегах:
v - версия, принимает значение v=DMARC1 (обязательный параметр)
p - правило для домена. (Обязательный параметр) Может принимать значения none , quarantine и reject , где
p=none не делает ничего, кроме подготовки отчетов
p=quarantine добавляет письмо в СПАМ
p=reject отклоняет письмо
Тэг sp отвечает за субдомены и принимает такие же значения, как и p
aspf и adkim позволяют проверять соответствиям записям и могут принимать значения r и s , где r - relaxed более мягкая проверка, чем s - strict.
pct отвечает за кол-во писем, подлежащих фильтрации, указывается в процентах, например, pct=20 будет фильтровать 20% писем.
rua - позволяет отправлять ежедневные отчеты на email, пример: rua=mailto:[email protected] , так же можно указать несколько email через пробел (rua=mailto:[email protected] mailto:[email protected])
Пример отчета
ruf - отчеты писем, не прошедшие проверку DMARC. В остальном все так же, как и выше.
Эпилог
Мы научились настраивать DKIM/SPF/DMARC и противостоять спуфингу. К сожалению, это не гарантирует безопасность в случае взлома сервера или же отправки писем на серверы, не поддерживающие данные технологии. Благо, что популярные сервисы все же их поддерживают (а некоторые и являются инициаторами данных политик).Эта статья - лишь инструкция по самостоятельной настройке записей, своего рода документация. Готовых примеров нет намеренно, ведь каждый сервер уникален и требует своей собственной конфигурации.
Буду рад конструктивной критике и правкам.
Недавно мы настраивали SMTP-сервер для нашего проекта. Вопрос стоял так: что нужно сделать, чтобы письма, отправленные нашим пользователям, не попадали в папку со спамом или попадали туда как можно реже?
Было найдено несколько интересных и полезных статей на эту тему (ссылки в конце статьи), на основе которых и было всё сделано в итоге. Но получив сегодня утром очередную порцию рассылки от достаточно известных русскоязычных ресурсов и увидев, что они пренебрегают описанными правилами, я решил кратко и в одном месте собрать все действия, которых достаточно для решения проблемы. Надеюсь, что после этого количество сайтов, отправляющих почту как надо, возрастет.
Приведенные советы актуальны только если вы используете свой собственный SMTP-сервер. При использовании, например, SMTP сервера Google всё уже сделано за нас. Как правило. В любом случае рекомендую проверить (см. подразделы Как проверить?
).
Пункты расположены по степени значимости. Лучше не приступать к следующему, не завершив предыдущий.
Пропишите Reverse DNS
Название говорит само за себя. Reverse DNS lookup - процедура обратная DNS lookup. По IP адресу мы, а точнее почтовый сервер пользователя, получаем доменное имя. Если он совпадает с доменным именем в поле From, отправляемого письма, то всё в порядке.Как сделать?
В большинстве случаев вы сами не сможете это сделать, если не являетесь владельцем диапазона IP-адресов. Поэтому единственный способ сделать данную настройку - попросить сделать это вашего хостинг-провайдера.
Как проверить?
Используйте любой из online-сервисов Reverse DNS lookup. Например, этот . Достаточно ввести IP-адрес сервера, с которого производится отправка почты. Если в результате отображается ваш домен, то всё в порядке.
В большинстве случаев достаточно следующей записи:
example.com. TXT v=spf1 a mx ~all
Эта запись говорит о том, что почту можно отправлять с любого IP, указанного в записях A (AAAA) и MX данного домена и только с них.
Как проверить?
Отправьте почту через ваш сервис на любой GMail-аккаунт. Откройте полученное письмо и выберите в меню действий пункт Show Original.
Если вы найдете следующие строчки, то всё в порядке:
Received-SPF: pass
Authentication-Results: ... spf=pass
Итого
Описанные действия должны значительно уменьшить вероятность попадания ваших писем в спам. Все остальные приемы связаны с содержимым письма или с тем как на него реагируют пользователи (часто ли они помечают ваше сообщение как спам?). Но это уже отдельная история.Серверов, с которых разрешена отправка электронной почты. Это необходимо для защиты репутации домена и снижения вероятности попадания писем в спам. Дело в том, что при отправке письма, можно подставить абсолютно любой адрес отправителя в поле "From:" , чем и пользуются злоумышленники при рассылке спама и фишинга от чужого имени. Такие рассылки могут значительно навредить репутации вашего домена, и создать проблемы с доставкой электронной почты с вашего домена. А вот IP адреса почтового сервера, с которого была произведена отправка, подделать нельзя. Соответственно если SPF запись для домена есть, то почтовые службы сначала проверят с того ли IP адреса идет рассылка и если не с того, то будут действовать согласно правилам указанным в SPF.
Как создать SPF запись
Как уже писалось выше, SPF это обычная текстовая запись, но данные указываются с использованием определенного синтаксиса, который мы сейчас и рассмотрим.Пример SPF записи: " v=spf1 +a +mx -all " . Означает эта запись следующее — принимать почту с IP адресов, которые указаны в DNS записях типа A и MX для этого же домена (имеется ввиду домен, для которого это запись указана), со всех остальных почту отклонить. Можно ее немного укоротить и написать так: " v=spf1 a mx -all " , результат работы будет тот же. Рассмотрим синтаксис более детально.
- "v=spf1" — используемая версия SPF. На текущий момент она одна, первая версия.
- "+" — принимать почту. Этот параметр установлен по умолчанию, его отсутствие означает то же самое, что и его наличие.
- "-" — отклонять почту.
- "~" — принимать почту, но помещать ее в спам.
- "?" — относится нейтрально. То есть, принимать как обычное письмо.
- "mx" — содержит IP адреса всех серверов, указанных в DNS записях типа MX для домена.
- "ip4" — позволяет указать конкретные IPv4 адреса .
- "ip6" — то же, что и "Ip4", только указывается IPv6 адрес .
- "a" — указывает на IP адреса, которые указаны в DNS записях типа A для домена.
- "include" — разрешает получение почты, согласно SPF другого домена.
- "all" — все остальные, не перечисленные в SPF записи.
Рассмотрим сложный пример SPF записи
"v=spf1 mx a ip4:154.56.125.94 a:some-domain.com mx: some-domain.com include: some-domain .com ~all"mx — принимать почту со своих почтовых серверов.
a — принимать почту с серверов, которые указаны в записях типа A для своего домена.
ip4:154.56.125.94 — принимать почту отправленную с IP 154.56.125.94. Также можно указывать подсети в формате 154.56.125.0/24.
a:some-domain.com — принимать почту с серверов, которые указаны в записях типа A для домена some-domain.com. Здесь также есть возможность указать подсеть в формате some-domain.com/24.
mx:some-domain.com — принимать почту с почтовых серверов, указанных в записях типа MX для домена some-domain.com. Возможно указание подсети аналогично с a:some-domain.com.
include:some-domain.com — разрешает получать почту согласно правилам, указанным в SPF для домена some-domain.com.
~all — помещать в спам все письма, отправленные с адресов, не указанных в SPF. Если указать -all, почта будет отклонятся.
Это наиболее часто используемые конструкции для создания SPF, но есть и другие, редко используемые, но о которых стоит знать.
- "ptr"
— проверяется PTR запись IP адреса отправителя на совпадение с указанным доменом.
"v=spf1 ptr:your-domain.com -all" - "exists"
— проверяется резолвится ли домен по какому либо IP адресу, причем IP адрес может быть абсолютно любой.
"v=spf1 exists:your-domain.com -all" - "redirect"
— говорит о том, что правила в SPF записи необходимо проверять на другом домене, а не на текущем.
"v=spf1 redirect:some-domain.com -all" - "exp"
— позволяет указать текст, который будет отправляеться отправителю письма в случае не соответствия правил, указанных в SPF. Указывается самым последним.
"v=spf1 a mx -all exp=spferror.your-domain.com"
Небольшое пояснение, для того, что бы отдавался текст ошибки, необходимо создать домен spferror.your-domain.com и добавить для него TXT запись с желаемым текстом.
Дата изменения раздела: 2013-05-09
С помощью сведений в этом разделе можно определить наилучший способ управления записями и параметрами DNS, MX и SPF при настройке и использовании службы Forefront Online Protection for Exchange (FOPE).
Записи DNS
При оформлении подписки на службу FOPE для проверки домена рекомендуется добавить запись TXT в записи DNS домена или в параметры домена поставщика услуг Интернета. При добавлении записи TXT в параметры домена поставщика интернет-услуг следует помнить, что для создания и изменения записей DNS потребуется обратиться к поставщику DNS.
Записи TXT
TXT или текстовая запись состоит из произвольной текстовой строки, которую можно присоединить к узлу DNS. Этот узел может иметь несколько записей TXT.
Активация службы FOPE для любого домена возможна только после проверки домена. Предпочтительным методом проверки домена является добавление записи TXT для каждого домена. Запись TXT добавляется в домен на этапе проверки домена в центре администрирования FOPE. Дополнительные сведения о проверке и включении домена см. в разделе Проверка и включение доменов .
Записи, относящиеся к электронной почте
Для электронной почты используются три основные записи: записи почтового обменника (MX), записи указателя (PTR) и записи инфраструктуры политики отправителей (TXT).
Записи MX (почтового обменника)
Запись MX указывает системам электронной почты способ обработки сообщения электронной почты, отправленного в конкретный домен. Иными словами, запись обмена электронной почтой указывает серверу, отправляющему сообщение электронной почты, куда необходимо отправить сообщение. Для надлежащей работы службы FOPE запись MX должна указывать на mail.messaging.microsoft.com, а не на IP-адрес. Это обеспечивает ретрансляцию сообщения электронной почты, отправленного в домен организации, в FOPE для фильтрации.
При наличии в организации нескольких доменов, принимающих сообщения электронной почты, потребуется изменить запись MX для каждого домена, для которого требуется фильтрация сообщений электронной почты с помощью службы FOPE.
Примечание
Если записи TXT недоступны для домена, как альтернативный метод проверки домена можно использовать обновление записи MX. Дополнительные сведения см. в разделе Проверка и включение доменов .
Записи PTR (указателя)
PTR (запись указателя) - это запись, которая используется для обратного поиска в DNS. Эта запись является противоположной записи A и используется в файлах зон обратного просмотра для преобразования IP-адреса (IP версии 4 или IP версии 6) в имя узла. При отправке сообщения электронной почты конечный сервер получает IP-адрес отправителя и проверяет запись PTR, чтобы убедиться в том, что IP-адрес является адресом домена.
Записи SPF (инфраструктура политики отправителей)
Инфраструктура политики отправителей - это запись, которая используется для предотвращения спуфинга электронной почты. С помощью одной записи TXT можно указать все IP-адреса, используемые для отправки почты, и указать принимающему серверу, что разрешены только исходящие серверы, указанные в списке.
Пример записи TXT с определениями для каждой ее части приведен ниже.
| Формат записи TXT: “v=spf1 mx ip4:{IP-адреса всех серверов, используемых для отправки} include:spf.messaging.microsoft.com ~all” | |
|---|---|
| Используемая версия SPF. |
|
| Этот параметр указывает, что разрешена отправка с любого сервера, указанного в записи MX. |
|
| Список разрешенных IP-адресов сервера (не требуется для серверов FOPE, если включена запись SPF FOPE и отправка производится только через FOPE). |
|
| В этом параметре перечислены дополнительные записи, разрешающие отправку для домена. |
|
| Параметр all содержит три ключа: - : принимать сообщения электронной почты только от отправителей, перечисленных выше (жесткий отказ). ~ : не принимать сообщения электронной почты, если отправитель отсутствует в указанном списке (мягкий отказ, сообщение будет принято, но помечено как нежелательное). ? : указывает на наличие дополнительных серверов, которые могут отправлять сообщения из домена. |
|
Обычная запись TXT для клиента, который отправляет электронную почту только через службу FOPE, может выглядеть следующим образом: "v=spf1 include:spf.messaging.microsoft.com ip4:192.168.254.254 -all"
Дополнительные сведения о том, как служба FOPE использует записи SPF, см. в разделе Рекомендации по настройке FOPE , подпункт "Параметры записи SPF".
Хочу обратить ваше внимание на важную, на мой взгляд, проблему, которой пренебрегают даже самые крупные и инновационные компании мира. Проблема заключается в отсутствии у большинства доменов SPF-записи, которая защищает домен от его несанкционированного использования в электронной почте.
SPF (Sender Policy Framework) представляет из себя текстовую запись в TXT-записи DNS домена. Запись содержит информацию о списке серверов, которые имеют право отправлять письма от имени этого домена и механизм обработки писем, отправленных от других серверов.
Например, SPF-запись «example.com. TXT «v=spf1 +a +mx -all»
» говорит о том, что отправлять письма от имени домена «example.com» могут сервера, указанные в A и MX-записях этого домена, а письма, отправленные от других серверов должны быть удалены (Fail).
Важно понимать:
- SPF-запись не наследуется на поддомены. Для каждого домена третьего (и ниже) уровней необходима своя запись.
- SPF проверяет только HELO и MAIL FROM поля.
Почему это важно?
На текущий момент все продвинутые анти-спам системы используют 3 основных типа анализа писем (и их вариации):- Анализ IP-адреса сервера отправителя: его репутация, корректность A и PTR-записей.
- Анализ SPF/DMARC записей домена и цифровой подписи DKIM.
- Анализ содержимого: заголовки, тема, текст, ссылки и т.д.
Примеры
В качестве примера я отправил 3 простых письма с помощью telnet и SMTP команд. 2 письма покажут работу спам-фильтра SpamAssassin (сервис mail-tester.com), а последнее письмо будет проходить анти-спам фильтр Gmail. Для чистоты экспериментов я использовал «чистый» IP-адрес (найти его было не так и сложно) и текст без ссылок и HTML.Письмо №1:
Письмо №2:
Письмо №3:
Как видно из результатов, письмо от домена «microsoft.com» не прошло бы анти-спам фильтр, даже если у него идеально чистое содержание. А вот письмо от имени домена «microsoft.ru» прошло проверку и у SpamAssassin и у Gmail, так как оно не защищено.
- Перед установкой SPF-записи удостоверьтесь, что учтены все сервера, отправляющие письма в интернет. Не забудьте про web-сервера и другие внешние системы, иначе вы можете потерять часть писем, и тем самым навредить себе и бизнесу.
- Правильно выбирайте механизм обработки писем (Pass, Fail, SoftFail, Neutral). При безусловной переадресации вашего письма из одной почтовой системы в другую может возникнуть проблема, так как SPF проверяет только последний «хоп».
- Рекомендуется создавать SPF-записи для всех доменов второго уровня, которые принадлежат вам или вашей компании, даже если вы не отправляете от их имени письма. Для таких доменов желательно использовать простую запись «v=spf1 -all », которая говорит, что никто не можем отправлять письма от этих доменов.
- Домены третьего уровня защитить можно с помощью wildcard-записи типа «». Но, обратите внимание на то, что wildcard работает только для несуществующих поддоменов. Например, если у вас есть поддомен moscow.example.com с MX-записями, запись «*.example.com. IN TXT «v=spf1 -all»
» не будет на нее распространяться. Подробнее описано в статье на Wikipedia и RFC 1034 .
Moreover, the wildcard is matched only when a domain does not exist, not just when there are no matching records of the type that has been queried for. Even the definition of «does not exist» as defined in the search algorithm of RFC 1034 section 4.3.2 can result in the wild card not matching cases that one might expect with other types of wildcards.
- SPF-записи рекомендуется создавать не только для доменов, но и для почтовых серверов, которые занимаются отправкой писем в интернет. Это необходимо, чтобы пройти HELO/EHLO Test принимающего сервера. Стандартная запись: «mx.example.com. IN TXT «v=spf1 a -all» ».
- Если у вас много доменов, которые обслуживаются несколькими основными MX-серверами, то советую использовать механизм «redirect». Например, основной домен «example.com» имеет SPF-запись «v=spf1 +a +mx -all », то остальным доменам (example1.com, example2.com и т.д.), для упрощения обслуживания, можно прописать запись «v=spf1 redirect=example.com ».
- Если у вас много доменов и много почтовых серверов отправителей, распределенных географически и организационно, то можно использовать механизм «include» и отдельную зону «_spf.example.com». Как пример можно посмотреть запись для домена gmail.com – «v=spf1 redirect=_spf.google.com ».
- Кроме защиты своих доменов рекомендуется защитить свою почтовую систему и пользователей, включив проверку SPF/DKIM/DMARC записей на ваших внешних почтовых серверах. Это будет хорошим дополнением даже для таких мощных программно-аппаратных комплексов, как Cisco IronPort.
- Как только полностью разберетесь с SPF, советую изучить вопрос подписи ваших электронных писем с помощью технологии DKIM и политики DMARC, это существенно увеличит репутацию ваших исходящих писем.
Товарищи айтишники, не подставляйте себя и свою компанию – установите SPF-записи для всех своих доменов и MX-серверов.
