Что такое согласование DMARC

Коротко

DMARC спрашивает не «прошло ли письмо проверку». Он спрашивает «прошло ли письмо проверку по тому домену, который видит получатель». Разница между этими двумя вопросами и есть согласование — и именно на ней спотыкается большинство настроек, которые на первый взгляд выглядят завершёнными.

Почему одной проверки мало

В письме два разных «отправителя»:

• Технический — адрес в обратном пути (Return-Path), который видит почтовый сервер и по которому проверяется SPF.
• Видимый — адрес в поле From:, который видит человек в почтовом клиенте.

Получатель читает второе, а SPF проверяет первое. Если не требовать, чтобы они относились к одному домену, злоумышленнику достаточно завести собственный домен с безупречным SPF и поставить в From: ваш. Формально проверка пройдена — фактически это подделка.

Согласование закрывает ровно этот разрыв.

Как это работает

DMARC считает письмо успешным, если выполняется хотя бы одно из условий:

• SPF пройден и домен обратного пути согласуется с доменом в From:, либо
• DKIM пройден и домен подписи (d=) согласуется с доменом в From:.

Достаточно одного механизма. Оба — лучше, но не обязательно.

Relaxed и strict

Режим согласования задаётся в записи DMARC двумя тегами: aspf для SPF и adkim для DKIM.

Режим	Тег	Что считается совпадением
Relaxed (по умолчанию)	aspf=r, adkim=r	Достаточно организационного домена: mail.example.com согласуется с example.com
Strict	aspf=s, adkim=s	Нужно точное совпадение домена

Relaxed подходит почти всем и потому стоит по умолчанию: поддомены для рассылок — нормальная практика. Strict имеет смысл, когда вы осознанно контролируете каждый поддомен и хотите, чтобы никакой другой не мог выступать от вашего имени.

Типичный случай: рассылка через стороннюю платформу

Вы настроили рассылку, платформа рапортует «SPF и DKIM настроены», а DMARC всё равно проваливается. Почти всегда причина одна:

• в From: стоит news@yourbrand.com;
• SPF проверяется по домену платформы, например bounces.vendor.net;
• DKIM подписан доменом d=vendor.net.

Обе проверки пройдены — и ни одна не согласована с yourbrand.com. Решение тоже одно: настроить на стороне платформы собственный поддомен для отправки и собственный ключ DKIM, чтобы d= стал вашим доменом.

Как прочитать это в отчётах

В сводных отчётах DMARC разница видна напрямую. Блок auth_results показывает «сырой» результат проверки, policy_evaluated — согласованный, тот, по которому и принимается решение:

<policy_evaluated>
  <dkim>fail</dkim>
  <spf>pass</spf>
</policy_evaluated>
<auth_results>
  <spf><domain>bounces.vendor.net</domain><result>pass</result></spf>
</auth_results>

SPF pass в сыром результате, домен — чужой. Это и есть рассогласование в чистом виде. Как читать такие отчёты целиком, разобрано в статье «Как читать сводные отчёты DMARC».

Что с этим делать

1. Перечислите все системы, которые отправляют почту от вашего имени: CRM, биллинг, служба поддержки, маркетинговые рассылки.
2. Для каждой проверьте, какой домен стоит в d= подписи DKIM и в обратном пути.
3. Там, где домен чужой, настройте собственный поддомен и собственный ключ DKIM.
4. Убедитесь по отчётам, что согласование появилось, и только потом ужесточайте политику.

Текущее состояние записей своего домена можно посмотреть бесплатной проверкой.