Отчёты DMARC: что делать с этими XML

MAATRIX

Вы настроили DMARC на домене, указали в записи адрес для отчётов — и через день-два на почту начинают падать письма с вложениями вида google.com!example.com!1756800000!1756886400.xml.gz. Открываете вложение, видите нечитаемую простыню тегов, закрываете и забываете. Знакомая ситуация: сама настройка DMARC — это только полдела, а реальная польза начинается тогда, когда вы начинаете смотреть, что в этих отчётах написано.

Зачем вообще открывать эти отчёты

DMARC-отчёт (aggregate report, RUA) — это не абстрактная диагностика, а фактическая картина того, кто и как отправляет почту от имени вашего домена за последние сутки. Без этих данных вы настраиваете SPF и DKIM практически вслепую: записали политику, включили DMARC — и просто верите, что всё работает правильно для всех реальных отправителей. Отчёты снимают эту неопределённость и отвечают на два конкретных вопроса.

Первый — какие источники ДЕЙСТВИТЕЛЬНО отправляют почту с вашим доменом в поле From. Не «какие вы вписали в SPF», а какие реально видит принимающая сторона. Сюда попадает всё: ваш почтовый сервер, транзакционный сервис уведомлений, CRM, сервис рассылок, а иногда — и чужой сервер, который пытается подделать письма от вашего имени (спуфинг). Если такой источник существует, отчёт покажет его IP и то, что он не прошёл SPF/DKIM — это и есть сигнал попытки подделки, которую вы иначе просто не увидите.

Второй — как реально проходят проверки SPF и DKIM для легитимного трафика. Практика показывает, что при первоначальной настройке SPF почти всегда забывают один-два второстепенных сервиса: систему уведомлений на сайте, платёжный шлюз, сервис для форм обратной связи. Без отчётов вы узнаете об этом только тогда, когда клиент напишет «ваше письмо не дошло» — и то не всегда, потому что чаще такие письма просто тихо улетают в спам или отклоняются.

Почему сырой XML читать вручную — плохая идея

Структура aggregate-отчёта задокументирована в RFC 7489: корневой узел feedback, внутри — метаданные организации-отправителя (report_metadata), опубликованная политика (policy_published) и набор записей record — по одной на каждую уникальную комбинацию IP-адреса источника и результата проверки. Для маленького домена с одним почтовым сервером отчёт может уместиться на экран. Но у домена с несколькими сервисами рассылки, транзакционными письмами и парой поддоменов записей быстро становится по 30-50 в одном отчёте, а отчётов — по одному-два в день от каждого крупного провайдера (Google, Microsoft, Яндекс, Mail.ru), которые их вам присылают.

Вот фрагмент одной записи, чтобы было понятно, о каком объёме текста речь на каждый источник:

<record>
  <row>
    <source_ip>203.0.113.45</source_ip>
    <count>184</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>notification-service.net</domain>
      <result>fail</result>
    </spf>
  </auth_results>
</record>

Прочитать одну такую запись глазами — не проблема. Прочитать пятьдесят таких записей за неделю, ежедневно, из отчётов пяти разных провайдеров, в формате .xml.gz — это уже механическая работа, которую вручную никто в здравом уме не делает больше пары дней. Дальше это либо забрасывают (и теряют весь смысл DMARC), либо подключают инструмент, который парсит XML и строит сводную таблицу.

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

Какими инструментами парсить отчёты

Вариантов достаточно, разница — в том, сколько данных вы готовы отдавать третьей стороне и сколько готовы платить.

Бесплатные self-hosted варианты. Есть открытые проекты, которые принимают почту с отчётами напрямую на ваш сервер (через отдельный почтовый ящик или прямую доставку) и парсят XML в базу данных с веб-интерфейсом. Из плюсов — все данные остаются на вашей инфраструктуре, ничего никуда не уходит. Из минусов — это дополнительный сервис, который надо разворачивать, обновлять и следить за его работоспособностью, плюс нужен парсер .gz-вложений и почтовый ящик, принимающий вложения нужного размера. Разворачивать такой сервис на отдельном VPS обычно проще, чем встраивать в существующий почтовый сервер — так вы не рискуете основной инфраструктурой отправки почты, если сервис парсинга упадёт или начнёт есть много ресурсов.

Облачные бесплатные сервисы. Ряд провайдеров DMARC-мониторинга предлагает бесплатный тариф с ограничением по объёму писем в месяц — этого обычно достаточно для небольшого домена с несколькими источниками отправки. Вы указываете в DMARC-записи их адрес для отчётов (rua=mailto:...), они парсят входящие XML и показывают дашборд: список источников, IP, процент прохождения SPF/DKIM, тренд по дням.

Платные сервисы с расширенной аналитикой. Для доменов с большим объёмом почты или несколькими поддоменами платные тарифы дают более глубокую детализацию: разбивку по поддоменам, историю за длительный период, алерты на новые источники, которые раньше не встречались. Если у вас несколько доменов и десятки источников отправки — это оправданная трата, потому что экономит часы ручного анализа каждую неделю.

Практический момент, который стоит проверить перед выбором: DMARC-запись поддерживает несколько адресов в rua через запятую, так что можно одновременно отправлять копию отчётов и в свой ящик (для архива), и в сервис парсинга:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com,mailto:reports@dmarc-service.example; fo=1"

Тег fo=1 дополнительно включает forensic-отчёты (RUF) при любом несовпадении хотя бы одной из проверок — но на практике RUF-отчёты поддерживает меньше провайдеров и в них попадают фрагменты реальных писем, что поднимает вопросы приватности. Для большинства задач agregate-отчётов (RUA) достаточно, и с них стоит начинать.

Как искать легитимные источники, которые вы забыли

Главная практическая ценность отчётов — не в подтверждении того, что всё и так работало, а в обнаружении того, о чём вы не подумали при первоначальной настройке SPF. Процесс такой:

1. Соберите за 1-2 недели все уникальные source_ip из записей с header_from, равным вашему домену.
2. Для каждого IP определите, какой сервис за ним стоит — обратный DNS (dig -x <ip>) часто сразу называет провайдера (o1.mail.ru, mail-sor-*.google.com, *.sendgrid.net и подобное).
3. Сопоставьте список с тем, что у вас реально прописано в SPF. Если инструмент парсинга уже показывает результат SPF/DKIM по каждому IP — это делается автоматически, вручную через dig разбираться нужно только по спорным случаям.
4. Для каждого источника, который (а) реально ваш легитимный сервис и (б) не проходит SPF — добавьте его в запись.

Типичные забытые источники — это как раз то, что редко вспоминают на старте: сервис транзакционных писем для чеков и уведомлений о заказе (см. отдельный разбор настройки почтового сервера Postfix, если у вас свой сервер, а не внешний сервис), система обратной связи на сайте, платёжный агрегатор, отправляющий чеки от вашего домена, CRM с автоматическими письмами клиентам. Каждый такой сервис добавляется в SPF отдельной записью include::

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all

Важный нюанс, который стоит проверить сразу: SPF имеет лимит в 10 DNS-lookup на одну проверку (RFC 7208). Если вы бездумно добавляете include: на каждый найденный сервис, легко упереться в этот лимит — тогда SPF начнёт возвращать permerror, и все проверки будут проваливаться, включая легитимные. Если у вас много источников, используйте плоские записи (ip4:/ip6:) там, где провайдер даёт статичные IP, вместо вложенных include:, и периодически проверяйте количество lookup онлайн-валидатором SPF.

Как отличить подделку от забытого сервиса

Не каждый непройденный источник — это атака, но каждый непройденный источник заслуживает проверки. Разница обычно видна по нескольким признакам.

Похоже на легитимный сервис: IP принадлежит известному облачному или email-провайдеру (AWS SES, SendGrid, Mailgun, Яндекс.Почта для бизнеса), объём писем стабилен день ото дня, DKIM либо проходит с доменом самого сервиса, либо отсутствует, но паттерн отправки предсказуем (например, всегда один и тот же IP, отправляющий 20-30 писем в день в рабочие часы).

Похоже на подделку: IP не принадлежит ни одному известному вам сервису и не резолвится в узнаваемое имя, объём писем скачкообразный или разовый (всплеск на несколько сотен писем за день и тишина до и после), и SPF, и DKIM проваливаются одновременно, disposition в отчёте показывает none (то есть письма ПРОШЛИ до получателя, потому что у вас пока политика только-наблюдения) — это значит, что если бы у вас уже была строгая политика, эти письма были бы отклонены, а сейчас они долетают.

При обнаружении явно подозрительного источника имеет смысл: (а) не паниковать и не переходить резко на p=reject для всего домена — сначала убедиться, что это не редкий легитимный кейс; (б) проверить IP через сервисы репутации и WHOIS — часто это известные спам-хостинги; (в) держать в уме, что сам факт появления такого источника в отчёте — это уже хороший знак: DMARC работает, вы видите попытку, и после перехода на строгую политику она будет реально блокироваться, а не просто фиксироваться в логе.

Таблица: на что смотреть в отчёте в первую очередь

Как постепенно ужесточать политику на основе данных

Базовый принцип разбирается в статье про настройку SPF, DKIM и DMARC на VPS — здесь важно то, КАК именно опираться на отчёты при переходе между этапами, а не просто «подождать и переключить».

Этап 1 — p=none. Вы только собираете данные, ничего не блокируется. Держите этот этап не меньше двух-трёх недель — этого обычно хватает, чтобы через отчёты увидеть все регулярные источники (ежедневные сервисы) и хотя бы часть нерегулярных (недельные или ежемесячные рассылки, которые могут не попасть в короткое окно). Если у вас есть сервисы с редкой отправкой — например, ежемесячная рассылка счетов — стоит подождать полный цикл их работы, иначе рискуете не заметить источник до перехода на строгую политику.

Этап 2 — p=quarantine; pct= с постепенным увеличением процента. Начните с pct=10 — то есть строгая обработка применяется только к 10% писем, не прошедших проверку, остальные проходят как раньше. Смотрите отчёты каждые несколько дней: если легитимные источники по-прежнему показывают fail, значит SPF/DKIM ещё не донастроены до конца — увеличивать процент рано. Если все легитимные источники стабильно проходят, а fail остаётся только у подозрительных IP — увеличивайте pct до 25, 50, 100.

Этап 3 — p=reject. Переходите сюда только когда отчёты за разумный период (несколько недель на quarantine с pct=100) стабильно показывают pass для всех известных легитимных источников и fail — только для внешних/подозрительных. На этом этапе письма, не прошедшие проверку, будут отклоняться принимающей стороной до попадания в почтовый ящик получателя.

Частая ошибка — сокращать этот путь и переходить на p=reject через неделю после включения DMARC, потому что «вроде всё настроено». Расплата обычно приходит не сразу: полгода спустя добавляется новый сервис уведомлений, никто не вспоминает про DMARC, и его письма начинают массово отклоняться без предупреждения — потому что никто не смотрит отчёты на регулярной основе. Возьмите за практику хотя бы раз в месяц открывать дашборд парсера и смотреть, не появился ли новый источник — это 5 минут, которые экономят часы разбора «почему не долетело» в будущем.

Частые вопросы