Проверка DMARC-записи домена

Что такое DMARC и что он добавляет к SPF и DKIM

DMARC (RFC 9989) — это TXT-запись на имени _dmarc.example.com, в которой владелец домена говорит получателям три вещи: какие письма считать подлинными, что делать с остальными и куда присылать отчёты.

SPF и DKIM отвечают на технические вопросы: разрешён ли этот сервер и не изменилось ли письмо. Ни один из них не говорит получателю, что делать, если проверка не прошла, и ни один не смотрит на поле «От кого», которое видит человек. DMARC закрывает оба пробела. Он задаёт политику и требует, чтобы проверенный домен совпадал с доменом в From.

Второе, ради чего его ставят, это отчёты. Раз в сутки или чаще почтовые провайдеры присылают сводку о том, сколько писем пришло от вашего имени, с каких адресов и какие прошли проверку. Без этих данных вы не знаете ни о подделках, ни о собственных рассылках, которые тихо не проходят аутентификацию.

Как DMARC выносит вердикт

Получатель берёт домен из поля From и ищет запись на _dmarc этого домена. Если там пусто, он поднимается по дереву DNS к организационному домену. Этот обход добавил RFC 9989, прежде опирались только на список публичных суффиксов. Дальше письмо засчитывается, если верно хотя бы одно из двух:

• SPF прошёл, и домен конверта выровнен с From;
• DKIM прошёл, и домен из тега d= подписи выровнен с From.

Условия проверяются независимо, и вам достаточно одного. SPF, прошедший для чужого домена, DMARC ничего не даёт, с DKIM то же самое. Если не выполнено ни одно условие, получатель применяет политику из тега p (или sp и np для поддоменов).

Про выравнивание доменов

Режим задают два тега: aspf для SPF и adkim для DKIM. По умолчанию у обоих r, нестрогий режим: домены должны иметь общий организационный домен, поэтому подпись от news.example.com засчитывается для From на example.com. Строгий режим s требует буквального совпадения, и поддомен уже не пройдёт.

Строгое выравнивание нужно редко. Оно мешает подделывать письма от поддоменов, но только если каждый путь отправки подписывает ровно тем доменом, что стоит в From. Включить его при рассылках через сервис значит уронить собственную почту.

Почему DMARC не проходит при рабочих SPF и DKIM

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

Лечится подключением собственного домена внутри сервиса. Для DKIM вы публикуете у себя селектор, обычно CNAME на ключ сервиса, и подпись начинает нести ваш домен. Для SPF настраиваете свой Return-Path на поддомене, если сервис это умеет. Хватит и одного из двух, но опираться лучше на DKIM: при пересылке SPF ломается, а подпись остаётся верной, если письмо по дороге не правили. Выравнивание конкретного письма видно в анализе заголовков.

Три ступени внедрения

• p=none: наблюдение. Доставка не меняется, отчёты собираются.
• p=quarantine: непрошедшие письма обрабатываются как подозрительные, обычно уходят в спам.
• p=reject: непрошедшие письма отклоняются, обычно ещё во время SMTP-сессии, и не попадают ни во входящие, ни в спам. Это конечная цель для домена, который хочет защититься от подделки.

Флаг t=y заменил прежний pct. С ним получатель применяет политику на ступень мягче: quarantine работает как none, reject как quarantine. На отчёты флаг не влияет, а при p=none ничего не меняет.

С февраля 2024 года Gmail требует DMARC от тех, кто отправляет на его ящики больше 5 000 писем в день, Yahoo от массовых отправителей. Обоим достаточно p=none, если проверка проходит и домен From выровнен. При этом сам по себе DMARC попадания во входящие не гарантирует. Подробности в разборах требований Gmail и требований Yahoo.

Пример записи и её теги

v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r

По RFC 9989 первым обязан идти тег v, порядок остальных не важен. Прежний RFC 7489 требовал ставить p сразу за ним, поэтому записи обычно так и пишут. Запись на организационном домене действует и на поддомены, если у них нет собственной.

• p, sp, np: политика для самого домена, для его поддоменов и для поддоменов, которых нет в DNS. Письма от несуществующих поддоменов почти всегда поддельные. Без np действует sp, без sp действует p.
• t: тестовый режим, описан выше.
• rua и ruf: адреса для агрегированных отчётов и для отчётов о сбоях.
• adkim и aspf: режим выравнивания.
• fo: когда присылать отчёты о сбоях; psd: пометка для публичных суффиксов и сложных иерархий доменов, обычному домену она не нужна.

Теги pct, rf и ri из RFC 9989 убраны и не действуют у получателей, перешедших на новый стандарт. Исключение одно: черновик BIMI по-прежнему не принимает pct меньше 100 при p=quarantine, и логотип тогда не покажут.

Порядок ужесточения политики

Резкий переход к p=reject чаще всего и приводит к потере писем: неправильно настроенный DMARC вредит доставке. Работающая последовательность занимает пару месяцев:

1. p=none и адрес для отчётов. Ничего не блокируется, вы просто смотрите, кто отправляет от вашего имени. Держат две-четыре недели.
2. Доведите всех своих отправителей до dkim=pass с выравниванием домена.
3. p=quarantine, на первые недели с флагом t=y, пока отчёты не подтвердят, что своя почта проходит. Потом флаг убирают, и подозрительные письма уходят в спам, а не пропадают.
4. p=reject. К этому моменту в отчётах не должно оставаться легитимных источников с ошибками.

Сокращать этот срок мы не советуем. Время нужно, чтобы в отчётах накопилась статистика по всем отправителям. Редкие источники вроде годовых уведомлений и сезонных рассылок иначе просто не попадут в выборку и сломаются в самый неподходящий момент.

Как читать отчёты DMARC

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

Смысл первых недель не в поиске злоумышленников, а в инвентаризации. Почти всегда обнаруживается два-три легитимных отправителя, о которых забыли: сервис счетов, форма обратной связи на сайте, CRM бухгалтерии. Их нужно довести до прохождения проверок, и только потом ужесточать политику.

Если отчёты должны уходить на чужой домен, например в сервис разбора отчётов, тот обязан подтвердить приём записью example.com._report._dmarc.сервис.com со значением v=DMARC1. Без неё получатели адрес пропустят, и отчётов не будет, причём без всяких сообщений об ошибке. Чекер выше проверяет такие записи для каждого внешнего адреса.

Отчёты о сбоях (ruf=) содержат фрагменты самих писем, а это персональные данные, поэтому многие провайдеры их не отправляют. Строить на них процесс не стоит.

Что чаще всего сделано неправильно

• Запись годами висит в p=none. Отчёты никто не читает, защиты нет, но галочка «DMARC настроен» стоит.
• Нет rua. Политика есть, а обратной связи нет, и непонятно, кто проваливает проверку: злоумышленник или ваш собственный сервис рассылок.
• rua на чужом домене без авторизации. Отчёты не приходят, и это никак не проявляется, просто тишина.
• p=reject при живых поддоменах с рассылками. Письма с поддоменов начинают отклоняться, если у них нет своей аутентификации.
• sp=none при строгом p. Поддомены остаются открытыми для подделки.
• SPF есть, DKIM нет. Пересланные письма теряют SPF, и выровненной проверки у них не остаётся вовсе.

Email rejected per DMARC policy: почему письмо отклонили

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

Ошибки Gmail 4.7.40 и 5.7.40 говорят об обратном: у домена нет DMARC-записи или в ней не задана политика, а Gmail требует её от массовых отправителей. С 4.7.40 письма притормаживают, с 5.7.40 отклоняют. Хватит записи с p=none, собрать её можно в генераторе DMARC.