Приветствую, Хабр! В этой статье будет инструкция по настройке DKIM/SPF/DMARC записей. А побудило меня написать эту статью полное отсутствие документации на русском языке. Все статьи на эту тему, которые были мной найдены, были крайне не информативны.

1. DKIM


DKIM (DomainKeys Identified Mail) — это метод e-mail аутентификации, основанный на проверке подлинности цифровой подписи. Публичный ключ хранится TXT записи домена.

Принцип работы DKIM (взято с Wikipedia)

Зачем же он нужен?


DKIM необходим для того, чтобы почтовые сервисы могли проверять, является ли отправитель достоверным или нет. Т.е. защищает получателя письма от различных мошеннических писем (которые отправлены с подменой адреса отправителя).

Настройка DKIM подписи и DNS записей


Для это нам необходимо создать пару ключей:

openssl genrsa -out private.pem 1024 //генерируем секретный ключ длинной 1024

openssl rsa -pubout -in private.pem -out public.pem //получаем публичный ключ из секретного

Или можно воспользоваться онлайн-сервисом, чего я крайне не советую.

Далее необходимо указать путь с секретному ключу в файле конфигурации (для этого лучше почитать документацию) почтового сервера и публичный ключ в DNS.

Примером записей является
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 записей


Примером обычной 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 записей


Типичная запись выглядит так: _dmarc.your.tld TXT "v=DMARC1; p=none; rua=mailto:postmaster@your.tld"
В ней не предпринимаются никакие действия, кроме подготовки и отправки отчета.

Теперь подробнее о тегах:
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:postmaster@your.tld, так же можно указать несколько email через пробел (rua=mailto:postmaster@your.tld mailto:dmarc@your.tld)
Пример отчета
<record>
 <row>
 <source_ip>1.1.1.1</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>your.tld</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>your.tld</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>your.tld</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record>
 <record>
 <row>
 <source_ip>1.1.1.1</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <reason>
 <type>forwarded</type>
 <comment></comment>
 </reason>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>your.tld</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>your.tld</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>your.tld</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record> 


ruf — отчеты писем, не прошедшие проверку DMARC. В остальном все так же, как и выше.

Эпилог


Мы научились настраивать DKIM/SPF/DMARC и противостоять спуфингу. К сожалению, это не гарантирует безопасность в случае взлома сервера или же отправки писем на серверы, не поддерживающие данные технологии. Благо, что популярные сервисы все же их поддерживают (а некоторые и являются инициаторами данных политик).

Эта статья — лишь инструкция по самостоятельной настройке записей, своего рода документация. Готовых примеров нет намеренно, ведь каждый сервер уникален и требует своей собственной конфигурации.

Буду рад конструктивной критике и правкам.
Поделиться с друзьями
-->

Комментарии (6)


  1. a_mastrakov
    26.02.2017 17:56
    +3

    Не вижу ни слова о том, что такое Dmark, spf и dkim и как это работает. Только пример записи и первые пару строк описания из википедии. В чем смысл статьи? Для кого она?


    1. tech42
      26.02.2017 20:58
      +3

      Эта статья — лишь инструкция по самостоятельной настройке записей, своего рода документация.
      Подразумевается то, что читатель хотябы поверхностно знаком с данными методами, но не знаком с тем, какие существуют аргументы для более детальной настройки. При этом иллюстрации вполне себе раскрывают принцип работы данных методов.


  1. Godless
    27.02.2017 10:58

    Народ, пачку отчетов DMARC распарсить кроме этого и этого есть чего? Без БД. просто ворох файлов залить и поглядеть суммарно статистику...


    1. foxmuldercp
      27.02.2017 12:57

      В чем проблема набросать скрипт на питоне/руби/перле или жаве с сишарпом?
      Рубишная nokogiri распарсила код отчета из под спойлера в структуру.


      1. Godless
        27.02.2017 15:11

        Ни в чем. Сперва искал готовое только. Самому пока некогда.


  1. egorist
    27.02.2017 15:52
    +1

    Неплохая статья, некий чеклист для, тех кто разбирается ). Теперь я знаю как генерить DKIM самостоятельно.
    Одно замечание: ADSP лучше не применять. Этот стандарт канул в лету в 2013 году, и сами авторы рекомендуют его не использовать: пруф.
    DKIM, SPF, DMARK — вот и все что нужно.
    Иногда замечаю, что в некоторых доменах прописано несколько SPF записей. SPF запись может быть только одна для домена.
    Не используйте «spf2.0» — это устаревший стандарт.
    Для проверки валидности SPF есть масса сервисов, например вот