DMARC RUA/RUF: как читать aggregate XML-отчёты и находить spoofing по alignment

Зачем вам вообще разбирать DMARC-отчёты

DMARC — это не только запись в DNS вида v=DMARC1 и политика p=none/quarantine/reject. Реальная ценность появляется, когда вы регулярно смотрите отчёты: кто отправляет письма от вашего домена, что из этого проходит SPF/DKIM, где ломается alignment (выравнивание доменов) и где начинается spoofing (подделка отправителя).

У DMARC два типа отчётности:

• RUA — агрегированные отчёты (aggregate report). Обычно это XML (часто в архиве), с суммарной статистикой по IP/источникам за период.
• RUF — форензик-отчёты (failure/forensic). «Событийные» отчёты по отдельным письмам при фейлах (но в 2025 многие провайдеры их урезают или не отправляют).

Дальше разбираем именно aggregate XML: структуру отчёта, ключевые поля и практический алгоритм анализа. Фокус простой: отличать легитимную отправку от ошибки настройки и от spoofing.

RUA vs RUF: что реально вы получите в 2025

DMARC RUA (aggregate report)

Это основной рабочий инструмент. Каждый отчёт — «срез» за интервал (обычно сутки): какие IP отправляли, сколько писем, прошли ли SPF/DKIM, прошёл ли DMARC и почему.

На практике RUA помогает:

• находить неизвестные источники отправки (старый SMTP, сервис рассылок, CRM, тикет-система);
• видеть перекосы «SPF проходит, DKIM нет» и наоборот;
• ловить ошибки alignment при использовании поддоменов/внешних сервисов;
• подготовиться к ужесточению политики до p=quarantine и p=reject.

DMARC RUF (forensic)

RUF выглядит идеально: не прошло одно письмо — пришёл отчёт по конкретному кейсу. Но из-за приватности и политики провайдеров RUF часто не приходит, приходит без тела письма или включается только для отдельных типов фейлов.

Ставьте RUF как дополнительный инструмент, но процесс мониторинга и принятия решений лучше строить вокруг RUA: он стабильнее и масштабируется.

Как выглядит DMARC aggregate XML: общая «карта»

Обычно вы получаете архив (zip/gz) с XML внутри. Теги и порядок могут немного отличаться, но базовая структура типовая:

• <feedback> — корень;
• <report_metadata> — кто сформировал отчёт, за какой период;
• <policy_published> — какой DMARC был опубликован для домена в этот период;
• <record> (много раз) — агрегированные записи по источнику/результатам.

Минимальный пример структуры (упрощённо)

<feedback>
  <report_metadata>
    <org_name>ExampleMailbox</org_name>
    <email>dmarc-reports@examplemailbox</email>
    <report_id>123456789</report_id>
    <date_range>
      <begin>1735344000</begin>
      <end>1735430400</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>

  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>57</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>
        <selector>s1</selector>
      </dkim>
      <spf>
        <domain>mail.example.net</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Ключевой момент: <policy_evaluated> показывает итог DMARC-оценки, а <auth_results> — «сырые» результаты SPF/DKIM с доменами, по которым их проверяли. Именно расхождение между «прошло» и «прошло и выровнялось» почти всегда объясняет проблемы alignment.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Ключевые поля, которые нужно уметь читать

1) Кто прислал отчёт и за какой период

В <report_metadata> обычно смотрят:

• <org_name> — чей провайдер/получатель сформировал отчёт;
• <report_id> — идентификатор отчёта (удобно для дедупликации);
• <date_range> — период отчёта (часто UNIX timestamp).

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

2) Какая политика DMARC действовала

В <policy_published> обычно лежат:

• <p> — политика домена (none/quarantine/reject);
• <pct> — процент применения политики;
• <adkim> и <aspf> — режим alignment: r (relaxed) или s (strict).

Alignment — центральная идея DMARC: важно не просто «SPF pass» или «DKIM pass», а чтобы домен, который прошёл проверку, соответствовал домену в заголовке From.

3) Сводка по источнику: source_ip, count, итог DMARC

Внутри каждого <record> блок <row> обычно содержит:

• <source_ip> — IP отправителя (или последнего видимого отправляющего узла для получателя);
• <count> — сколько писем в агрегате;
• <policy_evaluated> — итог: <dkim>pass/fail</dkim>, <spf>pass/fail</spf> и <disposition> (что получатель «сделал» по политике).

Это ваш «дашборд»: какие IP дают объём и какой у них итог.

4) Откуда «From» и где проверялся SPF/DKIM

Дальше начинается самое полезное для диагностики:

• <identifiers><header_from> — домен из заголовка From (то, что видит пользователь).
• <auth_results><spf><domain> — домен, по которому фактически проверяли SPF (обычно MAIL FROM/Return-Path, иногда HELO).
• <auth_results><dkim><domain> — домен d= из DKIM-подписи.

Если SPF/DKIM «pass», но DMARC «fail», почти всегда проблема в alignment: проверка прошла «не на том домене» относительно header_from.

Если вы планируете автоматизировать разбор, полезно сразу смотреть в сторону парсинга и нормализации отчётов в единую сводку: парсинг DMARC-отчётов и отчётность по доставляемости.

Alignment: relaxed vs strict на человеческом языке

У DMARC два выравнивания: SPF alignment и DKIM alignment. За них отвечают параметры aspf и adkim.

• Relaxed (r): допускается совпадение организационного домена. Условно, news.example.com может выравниваться с example.com.
• Strict (s): домен должен совпасть полностью. news.example.com уже не совпадает с example.com.

Практика: начинать чаще проще с aspf=r и adkim=r. Строгий режим включают точечно, когда инфраструктура отправки полностью под контролем и дисциплина доменов/поддоменов выстроена.

Быстрый алгоритм анализа RUA: от XML к действиям

Шаг 1. Сгруппируйте по source_ip и объёму

Сначала ищите не «ошибки», а самые массовые источники. Один IP с count=50000 важнее десяти IP по 1 письму: он даст максимум эффекта при исправлении.

Шаг 2. Разделите источники на 3 корзины

• Легитимные и зелёные: DMARC pass (обычно хотя бы один из SPF/DKIM aligned).
• Легитимные, но жёлтые: письма ваши, но DMARC fail из-за alignment/ошибок DKIM/SPF.
• Красные: неизвестные IP, DMARC fail — вероятный spoofing.

Шаг 3. Для «жёлтых» выясните, что именно не выровнялось

Смотрите на связку:

• identifiers/header_from — домен в From (ваш бренд/домен);
• auth_results/spf/domain — домен, по которому проверяли SPF;
• auth_results/dkim/domain — домен DKIM d=.

Типовые ситуации:

• SPF pass, но домен SPF чужой (сервис использует свой bounce-домен): DMARC может fail при строгом alignment или при неверной схеме From.
• DKIM pass, но d= не совпадает с From: сервис подписывает своим доменом, а вы отправляете From вашим — DMARC провалится.
• И SPF, и DKIM fail при «вашем» IP: вероятно, сломали MTA/подпись, перепутали селектор, удалили TXT DKIM, изменили Return-Path.

Для DKIM-части часто всплывают «тихие» проблемы ротации и TTL селектора: ротация DKIM-селекторов и выбор TTL без простоев.

Шаг 4. Для «красных» оцените масштаб spoofing и готовность к p=reject

Если вы видите множество источников, где header_from — ваш домен, а SPF/DKIM не проходят и IP явно не ваш, это классический spoofing. Хорошая новость: DMARC именно для этого и нужен. Плохая: пока p=none, эти письма могут всё равно попадать пользователям (зависит от получателя).

Переход к p=quarantine и затем к p=reject имеет смысл, когда «жёлтых» почти не осталось, а «красные» составляют основную долю фейлов.

Практика: как быстро разобрать XML на сервере

Если отчётов много, смотреть XML вручную неудобно. Минимальный набор утилит: распаковка плюс быстрые выборки по полям. Ниже — команды для экспресс-диагностики. Подставьте свои имена файлов.

Распаковать отчёт

ls -la
file report.zip
unzip -l report.zip
unzip report.zip

Если внутри .gz:

ls -la
file report.xml.gz
gzip -dk report.xml.gz

Быстро посмотреть, какие теги встречаются

grep -oE '<[a-zA-Z0-9_:-]+' report.xml | head -n 50

Вытащить связки IP и количества (грубо, без XML-парсинга)

Для аккуратного парсинга лучше использовать XML-парсер, но иногда нужно быстро оценить картину. Этот подход зависит от форматирования и может сработать не на всех отчётах, зато полезен как «первый взгляд»:

grep -E '<source_ip>|<count>' report.xml | head -n 200

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

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Частые ошибки, которые RUA показывает лучше всего

Ошибка 1. «Мы включили DKIM, но DMARC всё равно fail»

Проверьте в XML: auth_results/dkim/domain и identifiers/header_from. Если DKIM подписан доменом сервиса, а From — вашим доменом, то DKIM alignment не выполнен.

Решение обычно одно из двух: настроить подпись DKIM вашим доменом (если сервис позволяет) или менять схему отправки так, чтобы From соответствовал домену подписи (что редко подходит маркетингу и поддержке).

Ошибка 2. SPF pass есть, но DMARC fail

SPF проверяется по домену envelope sender (Return-Path), а не по From. В отчёте это видно как auth_results/spf/domain не равен header_from. Если у вас aspf=s, это почти гарантированный фейл. Даже при aspf=r могут быть нюансы, если сервис использует другой организационный домен.

Ошибка 3. В отчёте много разных IP с малым count и все fail

Это типичный «фон» spoofing по массовым ботнетам и облачным IP. Если легитимные источники вы вычистили, можно смелее двигаться к p=quarantine и p=reject, параллельно контролируя, что у ваших отправителей DMARC pass стабилен.

Что делать с RUF: если всё-таки приходит

Если вы включили RUF и видите, что отчёты действительно приходят:

• используйте их как «лупу» для конкретных инцидентов (например, подделка писем от имени бухгалтерии);
• не рассчитывайте на полный охват — многие провайдеры игнорируют ruf;
• учтите приватность: содержимое может быть урезано, а хранить такие отчёты стоит аккуратно и ограниченно по срокам.

Мини-чеклист: когда можно ужесточать DMARC

Перед переходом с p=none на более жёсткие режимы убедитесь, что по RUA:

• все основные легитимные источники дают DMARC pass;
• вы понимаете каждую «жёлтую» группу (почему fail и как исправить);
• у вас есть процесс на случай «сломали рассылку» (откат DMARC, мониторинг изменений, ответственность).

DMARC-политика — это не разовая настройка, а управляемое изменение. Лучший индикатор готовности — стабильные RUA-отчёты, где легитимный трафик зелёный, а fail в основном связан со spoofing.

Итоги

DMARC RUA (aggregate report) — ваш главный источник правды: какие отправители реально используют домен, проходят ли SPF/DKIM и соблюдён ли alignment. Понимание структуры DMARC XML-отчёта позволяет быстро отличать «настройку надо поправить» от «это spoofing» и уверенно двигаться к p=reject.

Если захотите, следующий логичный шаг — выстроить поток «ящик для RUA → хранение → парсер → сводка», чтобы анализ занимал минуты, а не часы.