MX, SPF, DKIM и DMARC: как они работают вместе

Четыре типа DNS-записей решают, как доставляется почта вашего домена и верят ли получатели, что она действительно ваша. Обычно их объясняют по одной, и от этого теряется главное: каждая закрывает брешь, которую оставляют остальные.

Здесь разобраны все четыре, ошибки, которые чаще всего встречаются в реальных зонах, и порядок внедрения, при котором ваша легитимная почта не пострадает.

Коротко

MX говорит, куда доставлять почту, адресованную вашему домену.
SPF говорит, каким серверам разрешено отправлять почту с вашим доменом в адресе отправителя конверта.
DKIM добавляет криптографическую подпись: она доказывает, что сообщение авторизовано доменом и не изменено по дороге.
DMARC привязывает SPF и DKIM к адресу From, который люди действительно видят, сообщает получателям, что делать, когда обе проверки не пройдены, и присылает вам отчёты.

MX отвечает за приём. Остальные три — за отправку.

MX: куда идёт почта

$ dig +short MX example.com
10 mx1.mail.example.net.
20 mx2.mail.example.net.

Отправители сначала пробуют сервер с наименьшим числом приоритета, а при неудаче переходят к большим. Равные числа делят нагрузку.

Что важно в MX-записи:

Целью должно быть имя хоста с записью A или AAAA. Ни IP-адрес, ни CNAME не допускаются.
Если MX-записи нет, отправители обращаются к собственной записи A/AAAA домена. Это почти никогда не то, что вам нужно.
Домен, который вообще не должен принимать почту, может опубликовать null MX: 0 . (приоритет ноль, цель — одна точка). Тогда отправитель получает отказ сразу, а не повторяет попытки несколько дней.

SPF: каким серверам можно отправлять

SPF — это одна TXT-запись на домене:

example.com.  TXT  "v=spf1 include:_spf.mail.example.net ip4:192.0.2.10 -all"

Принимающий сервер берёт домен из отправителя конверта (Return-Path, а не видимый заголовок From), запрашивает его SPF-запись и проверяет, подходит ли под неё IP-адрес подключившегося сервера. Что делать со всеми остальными, решает all в конце: -all означает fail, ~all — softfail, ?all — «мнения нет».

Два ограничения заложены в саму конструкцию:

SPF проверяет домен, которого получатель никогда не видит. Сам по себе он никак не мешает подделать ваш видимый адрес From.
SPF ломается при пересылке. Когда письмо пересылают, к конечному получателю подключается IP пересылающего сервера, а его в вашей записи нет.

DKIM: подпись, которая путешествует вместе с письмом

При использовании DKIM отправляющий сервер подписывает закрытым ключом выбранные заголовки и тело письма и добавляет заголовок DKIM-Signature. Открытый ключ лежит в DNS:

s2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

s2026 — это селектор. Это произвольная метка, которую выбирает отправляющая система; в заголовке подписи она стоит как s=s2026 рядом с подписывающим доменом d=example.com. Селекторов у домена может быть сколько угодно: по одному на каждый отправляющий сервис и на каждую ротацию ключа.

Отсюда следствие, на котором многие спотыкаются: «DKIM-запись домена» нельзя просто взять и найти. В DNS нет способа перечислить имена под _domainkey. Нужен селектор, а надёжный способ его узнать — открыть заголовки письма, которое домен действительно отправил.

Обычную пересылку DKIM переживает, потому что подпись едет вместе с письмом. Ломается он тогда, когда посредник меняет подписанное содержимое, а именно это делают многие списки рассылки, добавляя подвал или метку в тему.

DMARC: выравнивание, политика и отчёты

DMARC — это TXT-запись на имени _dmarc:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Она добавляет три вещи.

Выравнивание (alignment). Письмо проходит DMARC, если SPF пройден и домен конверта совпадает с доменом From, либо если DKIM пройден и домен из d= совпадает с доменом From. Одного выровненного прохождения достаточно. По умолчанию выравнивание нестрогое (relaxed), поэтому mail.example.com считается совпадающим с example.com.

Политика. p=none просит получателей ничего не предпринимать, p=quarantine — считать непрошедшие письма подозрительными (обычно это папка «Спам»), p=reject — отклонять их. sp= задаёт отдельную политику для поддоменов.

Отчёты. Получатели ежедневно присылают на адрес из rua сводные XML-отчёты: с каких IP шла почта от вашего имени, сколько было сообщений, прошли ли SPF и DKIM и было ли выравнивание. По этим отчётам вы и находите отправителей, о которых забыли.

Именно из-за выравнивания письмо может «пройти SPF» и всё равно провалить DMARC. Платформа рассылок, которая использует собственный домен для возвратов, проходит SPF для своего домена, а он с вашим не совпадает. Лечится это обычно настройкой собственного return-path или, что лучше, DKIM-подписью вашим доменом на этой платформе.

Ошибки, которые мы видим чаще всего

Несколько SPF-записей

example.com.  TXT  "v=spf1 include:_spf.mail.example.net ~all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

Две записи, начинающиеся с v=spf1, — это постоянная ошибка (permerror). SPF не проходит ни для одного письма. Обычно так выходит, когда кто-то буквально выполняет инструкцию нового поставщика. Объедините их в одну запись с обоими include.

Лимит в 10 запросов

При проверке SPF получатель может выполнить не более десяти DNS-запросов. Считаются include, a, mx, exists, redirect и ptr, причём include вкладываются друг в друга: один include поставщика сам по себе может стоить трёх-четырёх запросов. ip4, ip6 и all не стоят ничего. Больше десяти — и результатом снова будет permerror.

Способы исправить, в порядке предпочтения: убрать сервисы, которыми вы больше не пользуетесь; вынести массовых отправителей на поддомен с собственной SPF-записью; для сервисов, которые это умеют, положиться на выровненный DKIM и удалить их include. С «уплощением SPF» (flattening), при котором IP-адреса поставщика копируются в вашу запись, будьте осторожны: оно устаревает без предупреждения, как только поставщик меняет свои диапазоны.

`+all`

v=spf1 +all разрешает отправку любому серверу в интернете. Это хуже, чем отсутствие записи: вы прямо заявляете, что поддельная почта легитимна. ?all ненамного лучше.

Механизм `ptr`

Медленный, ненадёжный, и сама спецификация SPF не рекомендует его использовать. Уберите.

`p=none` навсегда

p=none — это режим наблюдения. Он даёт отчёты и не даёт никакой защиты: кто угодно по-прежнему может поставить ваш домен в строку From, и получатели доставят такое письмо так же, как доставили бы и без записи. Множество доменов публикуют p=none ради галочки в требованиях к массовым отправителям и дальше не двигаются. Если отчёты чисты уже несколько недель, оставаться на этом уровне незачем.

Забытые домены, с которых почта не уходит

Припаркованные домены и домены, на которых есть только сайт, подделывают как раз потому, что за ними никто не следит. Закройте их:

example.org.         TXT  "v=spf1 -all"
_dmarc.example.org.  TXT  "v=DMARC1; p=reject"
example.org.         MX   0 .

Как внедрить DMARC безопасно

Составьте перечень отправителей. Почтовый провайдер, письма сайта и приложений, CRM, сервис рассылок, выставление счетов, служба поддержки, оповещения мониторинга. Ломается то, о чём забыли.
Приведите в порядок SPF. Одна запись, меньше десяти запросов, в конце ~all или -all.
Включите DKIM везде. Для каждого сервиса настройте подпись вашим доменом в d=. Это самое важное: именно благодаря DKIM проверка DMARC проходит и после пересылки.
Опубликуйте p=none с адресом rua. Используйте отдельный ящик или сервис обработки отчётов: читать сырой XML глазами неприятно.
Читайте отчёты две-четыре недели. Ищите легитимные источники, у которых нет выравнивания. Каждый исправляйте у источника.
Перейдите на p=quarantine. При большом объёме двигайтесь постепенно с помощью pct=, например 10, затем 50, затем 100. Отчёты продолжайте читать.
Перейдите на p=reject. Отдельно решите, нужна ли поддоменам собственная политика sp=.
Продолжайте наблюдать. Новые инструменты начинают использовать, не предупредив того, кто отвечает за DNS. Узнаёте вы об этом из отчётов.

Небольшой остаток сбоев, которые исправить нельзя, будет всегда: в основном от списков рассылки и необычных пересыльщиков. Многие получатели обрабатывают такие случаи с помощью ARC или собственных эвристик. Это повод двигаться осторожно, а не повод оставаться на p=none.

Чего записи не могут

Правильные записи MX, SPF, DKIM и DMARC означают, что получатель может убедиться: почта авторизована вашим доменом. Они не означают, что письмо окажется во входящих. Почтовые провайдеры учитывают ещё репутацию домена и отправляющих IP, долю жалоб, качество базы адресов, содержание писем и то, как получатели с ними обращаются. Ничего из этого в DNS нет.

Аутентификация — это входной билет. Крупные провайдеры теперь требуют её от массовых отправителей, и без неё вас отфильтруют раньше, чем посмотрят на что-либо ещё. С ней вас оценивают по тому, как вы на самом деле отправляете почту.

Проверка DNS не может доказать и того, что почта ходит. Она показывает, что опубликованная политика непротиворечива, а это как раз та часть, которой вы управляете из зоны.

Проверьте в OrbitProbe

Проверка MX-записей в OrbitProbe читает записи MX, SPF и DMARC домена и отмечает описанные выше проблемы: несколько SPF-записей, слишком много запросов, +all, отсутствие DMARC-записи или политику, застрявшую на p=none. Для DKIM найдите селектор в заголовках отправленного письма и запросите selector._domainkey.example.com (со своим селектором и доменом) как TXT-запись. Если хотите знать, когда эти записи меняются, наблюдение за изменениями DNS в рабочем пространстве ведёт их историю.

Что читать дальше: если письма уже уходят в спам, пройдите чек-лист DNS для писем, попадающих в спам; правила для MX и TXT в общем контексте описаны в статье типы DNS-записей; а перед правкой SPF или DMARC полезно вспомнить, что такое TTL в DNS.