1. DKIM
DKIM (DomainKeys Identified Mail) — это метод e-mail аутентификации, основанный на проверке подлинности цифровой подписи. Публичный ключ хранится TXT записи домена.
![Принцип работы DKIM (взято с Wikipedia)](https://habrastorage.org/files/21b/c58/7bb/21bc587bbdac415a9ec9d6134ec46c7a.png)
Зачем же он нужен?
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=sha256s
— Тип сервиса, использующего 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 (взято с просторов интернета)](https://habrastorage.org/files/ea8/e66/0a1/ea8e660a16ed424da391c3e5d54392f9.png)
Настройка SPF записей
Примером обычной SPF записи является
your.tld. TXT "v=spf1 a mx ~all"
Здесь:
v=spf1
является версией, всегда spf1a
— разрешает отправляет письма с адреса, который указан в 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 (взято с просторов интернета)](https://habrastorage.org/files/7e0/7c1/fd6/7e07c1fd6c2e414cb0139e13938e4503.jpg)
Настройка 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)
Godless
27.02.2017 10:58Народ, пачку отчетов DMARC распарсить кроме этого и этого есть чего? Без БД. просто ворох файлов залить и поглядеть суммарно статистику...
foxmuldercp
27.02.2017 12:57В чем проблема набросать скрипт на питоне/руби/перле или жаве с сишарпом?
Рубишная nokogiri распарсила код отчета из под спойлера в структуру.
egorist
27.02.2017 15:52+1Неплохая статья, некий чеклист для, тех кто разбирается ). Теперь я знаю как генерить DKIM самостоятельно.
Одно замечание: ADSP лучше не применять. Этот стандарт канул в лету в 2013 году, и сами авторы рекомендуют его не использовать: пруф.
DKIM, SPF, DMARK — вот и все что нужно.
Иногда замечаю, что в некоторых доменах прописано несколько SPF записей. SPF запись может быть только одна для домена.
Не используйте «spf2.0» — это устаревший стандарт.
Для проверки валидности SPF есть масса сервисов, например вот
a_mastrakov
Не вижу ни слова о том, что такое Dmark, spf и dkim и как это работает. Только пример записи и первые пару строк описания из википедии. В чем смысл статьи? Для кого она?
tech42
Эта статья — лишь инструкция по самостоятельной настройке записей, своего рода документация.
Подразумевается то, что читатель хотябы поверхностно знаком с данными методами, но не знаком с тем, какие существуют аргументы для более детальной настройки. При этом иллюстрации вполне себе раскрывают принцип работы данных методов.