DMARC отчеты: как читать агрегированный XML и находить неизвестных отправителей

1. Какие бывают DMARC отчеты

Стандарт DMARC описывает два вида отчетов. Агрегированные отчеты (aggregate reports, адрес из тега rua) присылают сводку за период: какие IP слали письма от имени домена, сколько писем, какие результаты дали проверки SPF, DKIM и выравнивания. Это основной рабочий инструмент при внедрении и эксплуатации DMARC.

Отчеты об ошибках (failure reports, известны как forensic, адрес из тега ruf) отправляются по факту конкретного письма, не прошедшего проверку, и могут содержать его заголовки или фрагменты тела. Их присылают не все почтовые сервисы, а формат создает риски по персональным данным, о чем ниже.

Дальше речь в основном про агрегированные отчеты: именно они отвечают на вопросы "кто еще шлет от нашего домена" и "почему часть почты не проходит DMARC".

2. Как включить прием отчетов

Отчеты включаются в самой DMARC-записи домена. Проверьте текущую запись командой:

dig TXT _dmarc.example.com

Минимальная запись с приемом агрегированных отчетов выглядит так:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Здесь p=none означает режим наблюдения: отчеты приходят, но письма не отклоняются. Именно с такого режима начинают внедрение DMARC, чтобы сначала увидеть всех легитимных отправителей и только потом ужесточать политику до quarantine или reject. Подробный сценарий безопасного внедрения: <a href="/blog/nastroit-dmarc-bez-poteri-pisem">как настроить DMARC без потери писем</a>.

Дополнительные теги: ruf задает адрес для forensic-отчетов, fo определяет, в каких случаях формировать отчет об ошибке (например, fo=1: при любом несовпадении SPF или DKIM с выравниванием). Для старта достаточно rua.

3. Структура агрегированного XML-отчета

Отчет приходит письмом с вложением, обычно сжатым в gzip. Внутри XML с тремя логическими частями: метаданные отчета, опубликованная политика домена и набор записей по каждому источнику. Упрощенный фрагмент:

<feedback> <report_metadata> <org_name>google.com</org_name> <date_range><begin>1717200000</begin><end>1717286399</end></date_range> </report_metadata> <policy_published> <domain>example.com</domain> <p>none</p> </policy_published> <record> <row> <source_ip>203.0.113.10</source_ip> <count>1520</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim><domain>example.com</domain><result>pass</result></dkim> <spf><domain>mail.example.com</domain><result>fail</result></spf> </auth_results> </record> </feedback>

Как это читать сверху вниз: report_metadata говорит, кто составил отчет и за какой период. policy_published показывает, какую политику увидел получатель (важно: если вы меняли запись в течение суток, часть трафика могла попасть под старую политику). Дальше идут блоки record: один на каждую комбинацию IP-источника и результатов проверки.

Внутри record ключевые поля: source_ip (откуда шли письма), count (сколько писем), disposition (как поступил получатель: none, quarantine или reject), результаты policy_evaluated для DKIM и SPF с учетом выравнивания, и auth_results с сырыми результатами проверок по доменам, которые реально проверялись.

Важный нюанс: в auth_results результат SPF привязан к домену из envelope from (Return-Path), а DKIM к домену подписи d=. Выравнивание (совпадение с доменом в From:) оценивается отдельно, и его результат вы видите в policy_evaluated. Итоговая disposition - это фактическое действие получателя, оно обычно совпадает с вашей политикой, но получатель может применить исключение (доверенный форвардер, список рассылки, локальные правила). Подробнее про механику: <a href="/blog/dmarc-alignment">DMARC alignment</a>.

4. Неизвестные отправители в отчетах

Главная практическая ценность rua-отчетов: полный список IP, которые шлют почту от вашего домена. Каждый неизвестный source_ip проверяется по дереву диагностики:

Шаг 1. Определите владельца IP через whois или PTR. Если это ваш ESP, CRM-платформа или почтовый сервис, который вы забыли (например, тикет-система или корпоративная почта), его нужно включить в SPF и настроить DKIM-подпись с вашим доменом.

Шаг 2. Если в auth_results DKIM pass, а SPF fail, это типичный след переадресации: письмо прошло с вашей DKIM-подписью, но пересылка сломала SPF на промежуточном сервере (форвардер сотрудника, список рассылки, корпоративный релей получателя). Такие записи не требуют действий с вашей стороны, если DKIM выровнен и проходит.

Шаг 3. Если IP неизвестен, обе проверки fail, а header_from ваш домен, это попытка подделки. Фиксируйте объемы: они станут аргументом для перехода к p=quarantine и затем p=reject. Разбор сценария: <a href="/blog/poddelyvayut-pisma-domena">что делать, если подделывают письма вашего домена</a>.

5. Forensic-отчеты (ruf) и персональные данные

Forensic-отчет формируется по конкретному письму, провалившему DMARC, и по стандарту может включать его заголовки и часть содержимого. В этом две проблемы.

Первая: в отчет могут попасть персональные данные ваших клиентов (имена, адреса, тексты писем), а отправляет его сторонний почтовый сервис на указанный вами адрес. Если вы работаете с российской базой, оцените это с точки зрения требований к обработке персональных данных и не указывайте ruf без необходимости.

Вторая: многие крупные почтовые сервисы forensic-отчеты не отправляют вовсе, поэтому отсутствие ruf-потока не означает, что проблем нет. Для операционной работы достаточно агрегированных отчетов: они показывают те же проверки, но без содержимого писем.

Если ruf все же нужен (например, для расследования фишинга под ваш домен), заведите отдельный почтовый ящик с ограниченным доступом и пропишите сроки хранения этих писем.

6. Почему DMARC отчеты не приходят

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

1. Синтаксис записи. Ошибка в теге rua (пробел, опечатка в mailto, лишняя точка с запятой) делает запись невалидной или отключает отчеты. Проверьте запись целиком через dig TXT _dmarc.вашдомен и валидатором: <a href="/tools/dmarc-check">проверка DMARC-записи</a>.

2. Отсутствие авторизации внешнего домена. Если rua указывает на другой домен, без записи _report._dmarc на принимающей стороне отчеты могут не отправляться (см. раздел 2).

3. Трафика мало. Многие получатели присылают агрегированные отчеты примерно раз в сутки и только если за период были письма от вашего домена. При малом объеме отправок отчетов просто нет в некоторые дни.

4. Письма с отчетами фильтруются. Вложения в gzip с незнакомых адресов нередко попадают в спам или режутся корпоративным фильтром. Проверьте папку спама и логи почтового сервера ящика сбора.

5. Получатель не шлет отчеты. Не все почтовые сервисы отправляют DMARC-отчеты. Крупные (Gmail, Mail.ru, Microsoft, Yahoo) присылают, но полную картину по мелким доменам через отчеты не собрать.

7. Как проверить результат и автоматизировать разбор

Минимальная проверка: после публикации записи с rua отправьте тестовые письма на адреса Gmail, Mail.ru и Outlook и в течение нескольких суток убедитесь, что отчеты пришли и в них видны ваши IP с корректными результатами DKIM и SPF. Стандарт не нормирует сроки доставки отчета: у одних получателей он приходит в тот же день, у других - на вторые-третьи сутки. Если в policy_evaluated у вашего основного потока pass по обоим или хотя бы по DKIM с выравниванием, настройка работает.

Ручной разбор XML быстро упирается в объем: один домен с рассылками на крупные сервисы дает десятки отчетов в день от разных операторов. Практичный вариант: направить rua на приемник, который сам парсит XML и показывает сводку по источникам и результатам проверок.

PostmastersTool принимает DMARC-отчеты и одновременно проверяет DNS домена (SPF, DKIM, DMARC, MX, черные списки), так что изменения записи и данные отчетов видны в одном месте. Связку с репутацией у получателей дают <a href="/google-postmaster-monitoring">мониторинг Google Postmaster Tools</a> и <a href="/mailru-postmaster-monitoring">мониторинг Mail.ru Postmaster</a>: там видно долю писем, прошедших DMARC, и долю жалоб.