Как читать сводные отчёты DMARC

Что это вообще за отчёты

Когда вы публикуете DMARC-запись с адресом rua=, принимающие серверы — Google, Microsoft, Yahoo и тысячи других — ежедневно присылают XML-сводку по всем письмам, которые пришли к ним якобы от вашего домена. Один отчёт покрывает один отчётный период у одного получателя и отвечает на три вопроса:

1. Кто отправляет от вашего имени? (IP-адрес источника и объём)
2. Прошли ли письма SPF и DKIM?
3. Согласуются ли эти результаты с доменом в поле From:?

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

Анатомия отчёта

Каждый отчёт начинается с метаданных и политики, которую применил получатель:

<report_metadata>
  <org_name>google.com</org_name>
  <date_range><begin>...</begin><end>...</end></date_range>
</report_metadata>
<policy_published>
  <domain>yourdomain.com</domain>
  <p>reject</p>
  <sp>reject</sp>
  <pct>100</pct>
</policy_published>

Дальше идёт самое важное — по одному блоку <record> на каждый источник отправки:

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
    <spf><domain>yourdomain.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Читается это так: 42 письма пришли с адреса 203.0.113.10, представились доменом yourdomain.com и прошли DKIM и SPF с согласованием. Нормальный легитимный источник.

Поля, которые действительно важны

• source_ip — кто на самом деле отправил письмо. Проверьте адрес по обратной записи: либо вы его узнаёте (ваш ESP, ваш почтовый сервер), либо нет.
• count — сколько было писем. Большой объём с незнакомого IP — первый признак подделки.
• policy_evaluated — согласованный результат. Именно по нему DMARC и выносит вердикт.
• auth_results — сырой результат SPF и DKIM до проверки согласования. Разрыв между ним и policy_evaluated почти всегда означает проблему с согласованием.
• disposition — что получатель сделал с письмом: none, quarantine или reject.

Ключевое различие: в auth_results может стоять SPF pass, а в policy_evaluated — SPF fail. Это значит, что письмо аутентифицировалось по какому-то домену, просто не по вашему. Классическое рассогласование — и ровно то, чем пользуются злоумышленники.

Четыре типичные картины

Прошло и согласовано. Обе проверки пройдены и согласованы. Легитимная авторизованная почта, делать ничего не нужно.

Сырой pass, согласование fail. SPF или DKIM проходит, но по чужому домену. Обычно это сторонняя платформа, которая подписывает письма своим доменом. Согласование нужно чинить, а не игнорировать.

Fail из-за пересылки. SPF проваливается, DKIM проходит. Как правило, это рассылочный список или пересылка, где переписали путь доставки. DKIM переживает пересылку — поэтому опираются именно на согласование по DKIM.

Fail с неизвестного источника. Обе проверки провалены, IP незнакомый, часто с заметным объёмом. Вот это и нужно расследовать: пока не доказано обратное, считайте, что это подделка.

Как увидеть подделку

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

• незнакомые IP-адреса, которые шлют объём, и обе проверки при этом падают;
• географические аномалии — всплески из сетей, где у вас нет никакой инфраструктуры;
• рост неудачных проверок одновременно с фишинговой кампанией против вашего бренда или ваших клиентов.

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

От XML к пониманию

Читать сырой XML в объёме бессмысленно: несколько получателей в день по нескольким доменам — это тысячи строк. Работа тут в агрегации: сгруппировать по источникам, сопоставить IP-адреса с организациями, отделить согласованные успешные проверки от всего остального и вывести наверх неизвестное. Именно это делает DDMARC — превращает ежедневный поток отчётов в понятную картину того, кто отправляет от вашего имени и что именно не проходит проверку.

Если хотите просто посмотреть, что внутри ваших отчётов, загрузите XML в анализатор отчётов DMARC — он разберёт файл и покажет источники в читаемом виде.