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

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

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

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

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

1. p=none — наблюдение. Доставка не меняется, отчёты собираются. Держат две-четыре недели.
2. p=quarantine — непрошедшие письма уходят в спам. Включают, когда в отчётах не осталось легитимных отправителей с провалом проверки.
3. p=reject — непрошедшие письма отклоняются на входе. Конечная цель и требование Gmail с Yahoo для массовых отправителей.

Пример записи

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

Публикуется TXT-записью на имени _dmarc.example.com. Тег v должен идти первым, p — вторым, остальные в любом порядке. Запись на организационном домене действует и на поддомены, если у них нет собственной.

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

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

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

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

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

Форензик-отчёты (ruf=) содержат фрагменты самих писем и поэтому почти никем не отправляются, потому что провайдеры не хотят пересылать персональные данные. Рассчитывать на них не стоит.

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

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

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

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

DMARC проверяет не только то, что подпись валидна, но и то, что домен из неё совпадает с доменом в видимом поле From. Из-за этого типична ситуация, когда SPF и DKIM формально проходят, а DMARC нет. Рассылочный сервис подписывает письмо своим доменом, а в From стоит ваш.

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

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

Самая частая жалоба звучит так: обе проверки по отдельности зелёные, а DMARC красный. Причина в выравнивании: DMARC смотрит не только на результат проверки, но и на то, чей домен в ней участвовал.

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

Лечится подключением собственного домена внутри сервиса: отдельный DKIM-селектор на вашем домене и поддомен для конверта. После этого хотя бы одна из проверок начинает совпадать с From, чего DMARC и требует: достаточно одной, не обязательно обеих.

Сколько ждать между шагами

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

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

Эта строка означает, что письмо не прошло DMARC и домен отправителя велел такие письма отклонять. Получатель выполнил инструкцию. Опубликованную вами же.

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

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

Лечится подключением собственного домена внутри сервиса: отдельный DKIM-селектор на вашем домене и, если сервис это поддерживает, поддомен для конверта. После этого хотя бы одна проверка начинает совпадать с From, чего DMARC и требует.

Строка dmarc policy not enabled означает обратное: политики нет или она стоит в p=none, и отклонять получателю нечем. Это не ошибка доставки, а сообщение о том, что защита не включена.