DMARC отчёты без боли: сбор, парсинг и метрики доставляемости почты

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

Коротко о SPF/DKIM/DMARC и зачем нам отчёты

DMARC опирается на SPF и/или DKIM, требуя, чтобы хотя бы один из механизмов прошёл и при этом выровнялся по домену отправителя (alignment). Иначе получатель может применить карантин или отклонение. Но главная ценность для админа — телеметрия: агрегированные отчёты (rua) показывают, кто и с каких IP/организаций отправляет письма от вашего домена, где проходят SPF/DKIM и где срезается доставляемость. Форензик-отчёты (ruf) дают образцы проблемных сообщений для точечного разбора.

DMARC-отчёты — это ваш прозрачный «трассировщик» отправки: видно не только собственные сервера, но и сторонних отправителей (CRM, сервисы рассылок, биллинг), ошибочные ретрансляции и попытки спуфинга.

Если вы только строите почтовую инфраструктуру на отдельном сервере, пригодится материал о базовой связке и антиспаме — смотрите руководство по развёртыванию почтового стека на VDS: Postfix+Dovecot+Rspamd на VDS.

Типы DMARC-отчётов: rua и ruf

Существует два формата:

• rua (aggregate) — суммарные отчёты за период (обычно сутки). Прилетают в виде ZIP/GZIP с XML. Содержат отправителя отчёта, период, IP-источники, результаты SPF/DKIM и выравнивание, примерный объём писем.
• ruf (forensic/failure) — событийные отчёты по отдельным сообщениям, генерируются при сбоях в аутентификации в зависимости от политики fo. Могут включать фрагменты заголовков (редко тело) и несут риски с точки зрения чувствительных данных. Используйте аккуратно.

Публикуем DMARC-запись в DNS

DMARC — TXT-запись на поддомене _dmarc целевого домена. Базовая запись для наблюдения (без карантина):

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; fo=1; aspf=r; adkim=r; pct=100; ri=86400"

Ключевые теги:

• v — версия (обязательно DMARC1).
• p — политика для основного домена: none, quarantine, reject.
• sp — политика для поддоменов (если хотите отличать их от p).
• aspf, adkim — выравнивание SPF/DKIM: r (relaxed) или s (strict).
• rua — куда слать агрегированные отчёты (список mailto: адресов через запятую).
• ruf — куда слать форензик-отчёты (если нужны).
• fo — условия генерации ruf: 0, 1, d, s.
• pct — доля сообщений, к которым применяется политика.
• ri — желаемый интервал агрегирования в секундах (часто 86400).

Если домен только что зарегистрирован, сразу добавьте SPF/DKIM/DMARC после регистрации доменов, чтобы не терять время на прогрев репутации.

Безопасный старт: p=none + полная телеметрия

Начинайте с p=none и включённых rua/ruf. Это позволит собрать картину отправителей за 2–4 недели. Для ключевых брендов и чувствительных доменов лучше ставить aspf=s, adkim=s сразу — так вы заранее видите реальные риски с выравниванием в строгом режиме.

Переход к карантину и отклонению

Планируйте постепенное повышение: p=quarantine с pct=25 → 50 → 100, потом p=reject. На каждом шаге проверяйте метрики: долю PASS по DMARC, долю невыравненных источников, объёмы из «неизвестных» систем.

Для справки по корректной публикации SPF/DKIM/DMARC посмотрите «Записи DNS для аутентификации почты»: DNS-записи SPF, DKIM, DMARC.

Разрешение внешних адресов для отчётов

Если вы используете внешний адрес для rua/ruf (например, аналитический ящик на другом домене), по стандарту DMARC требуется авторизация. На стороне адресата публикуется TXT-запись вида:

example.com._report._dmarc.report-collector.tld. IN TXT "v=DMARC1"

Где example.com — ваш отправляющий домен, а report-collector.tld — домен получателя отчётов. Без этой записи часть провайдеров не будет отправлять им ваши отчёты.

Куда складывать отчёты и как их забирать

Практика: создайте отдельный ящик(и) для rua и ruf. Включите автоматическую очистку (например, хранить сырые вложения 90 дней). Для забора удобно использовать IMAP из скрипта по крону, складывая вложения в директорию по дате.

# Пример: скачивание вложений из IMAP в директорию /var/dmarc/inbox/YYYY-MM-DD
python3 dmarc_fetch.py --imap-host imap.example.com --user dmarc-rua@example.com --password '***' --out /var/dmarc/inbox
python3 dmarc_fetch.py --imap-host imap.example.com --user dmarc-ruf@example.com --password '***' --out /var/dmarc/inbox

Агрегированные отчёты часто приходят в .zip или .gz. Храните «сырые» архивы отдельно от распарсенных данных; это поможет при перепарсинге или проверке регрессий.

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

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Парсинг: из XML в таблицы

Варианты:

• Готовые парсеры, которые читают почтовый ящик/директорию, распаковывают и пишут в БД (часто SQLite/PostgreSQL), экспортируют в JSON/CSV.
• Своя минималистичная «труба»: распаковка архивов, валидация XML, вытаскивание полей, запись в таблицы.

Структура XML в агрегированных отчётах предсказуемая: блоки с метаданными провайдера и набор записей о источниках. Пример фрагмента (экранировано):

<feedback>
  <report_metadata>
    <org_name>Mailbox Provider Inc.</org_name>
    <email>dmarc-reports@provider.example</email>
    <report_id>123456789</report_id>
    <date_range><begin>1736380800</begin><end>1736467200</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>s</adkim><aspf>s</aspf><p>none</p><sp>none</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>1245</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>...</auth_results>
  </record>
</feedback>

Минимальный набор таблиц для аналитики:

• reports (источник отчёта, период, домен, политика, строгость выравнивания);
• records (IP, организация, количество, итог DMARC/SPF/DKIM, диспозиция);
• details (DKIM домены/селекторы, SPF домены, признаки выравнивания).

-- Пример схемы для PostgreSQL (упрощённо)
CREATE TABLE dmarc_report (
  id BIGSERIAL PRIMARY KEY,
  org_name TEXT,
  report_id TEXT,
  from_domain TEXT,
  begin_ts TIMESTAMP,
  end_ts TIMESTAMP,
  adkim CHAR(1),
  aspf CHAR(1),
  policy TEXT,
  pct INT
);

CREATE TABLE dmarc_record (
  id BIGSERIAL PRIMARY KEY,
  report_id BIGINT REFERENCES dmarc_report(id),
  source_ip INET,
  count INT,
  disposition TEXT,
  dkim_result TEXT,
  spf_result TEXT,
  header_from TEXT,
  auth_dkim_domains TEXT[],
  auth_spf_domains TEXT[]
);

Метрики доставляемости: что считать в первую очередь

Выжимка метрик, которые реально помогают принимать решения:

• DMARC pass rate: доля сообщений с итоговым прохождением DMARC (учитывая выравнивание). Это «здоровье» домена.
• DKIM alignment rate: доля сообщений, где DKIM прошёл и выравнился по домену заголовка From. Критично при пересылках, где SPF часто ломается.
• SPF alignment rate: аналогично для SPF. Хорош для контроля собственных исходящих шлюзов и сервисов с белыми IP.
• Unknown senders share: доля источников, которых вы не ожидали (IP/AS, организации, домены DKIM). Это потенциальный риск и мишень для исправлений.
• Disposition impact: сколько писем попадает под quarantine/reject при действующей политике и pct. Важный индикатор перед ужесточением.
• Top sources by failures: ранжирование IP/организаций по объёму FAIL/NOALIGN. Подсветит конкретные интеграции.

-- Пример запроса: итоговый DMARC pass rate за последние 7 дней
SELECT ROUND(100.0 * SUM(CASE WHEN dkim_result = 'pass' OR spf_result = 'pass' THEN count ELSE 0 END) / SUM(count), 2) AS dmarc_pass_pct
FROM dmarc_record r
JOIN dmarc_report rp ON r.report_id = rp.id
WHERE rp.begin_ts >= NOW() - INTERVAL '7 days';

Почему мы считаем «прошло DKIM ИЛИ SPF»? Потому что по стандарту DMARC достаточно одного прошедшего и выровненного механизма. В детальных дашбордах держите оба показателя отдельно — это помогает локализовать, где именно ломается аутентификация.

Нормы и целевые значения

• При p=none целитесь в DMARC pass 98–99% в течение 2–4 недель на производственном трафике.
• Перед p=quarantine держите Unknown senders ниже 1–2% и отсутствие бизнес-критичных рассылок среди Fail.
• Перед p=reject убедитесь, что DKIM alignment держится >= 99% (особенно если у вас много форвардинга).

Диагностика частых проблем

• SPF проходит, но DMARC Fail: нет выравнивания — домен в SPF не совпадает с доменом в From (relaxed допускает поддомены; strict — нет).
• DKIM Fail на пересылках: или отсутствует подпись у исходного отправителя, или меняется сообщение в пути. Решение — обеспечить DKIM-подпись на источнике и опираться на DKIM для DMARC.
• Сервис рассылок шлёт с чужого домена DKIM: выравнивания нет. Настройте кастомный DKIM на свой домен и подпись с ним.
• Поддомены: забыли про sp, а трафик идёт от mail.sub.example.com. Настройте отдельные DMARC/SPF/DKIM при необходимости, либо корректную sp.
• Слишком короткий ri приводит к большому количеству отчётов и нагрузке. Обычно достаточно 86400.

Форензик-отчёты ruf: когда включать и как обезопасить

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

• Использовать отдельный защищённый ящик с ограниченным доступом.
• Включать fo=1 точечно и временно, когда требуется расследование.
• Маскировать и не хранить лишнего (обезличивание адресов при парсинге).

План перехода на строгую политику за 30 дней

1. Неделя 1: включить p=none, rua/ruf, собрать базовую телеметрию. Сверить список «официальных» источников почты и фактический трафик в отчётах.
2. Неделя 2: обеспечить DKIM-подпись от всех источников, настроить выравнивание. Устранить неизвестные IP и сервисы (либо авторизовать, либо выключить).
3. Неделя 3: поднять p=quarantine с pct=25, наблюдать метрики. Дотянуть DMARC pass до ≥ 98.5%. Убрать остаточные FAIL.
4. Неделя 4: pct=100 на quarantine, при стабильности перейти к p=reject. Оставить rua навсегда, чтобы контролировать регрессии.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Практические советы по DNS и конфигам

• DKIM-ключи — 2048 бит, селекторы по источникам (например, news, crm), ротация раз в 6–12 месяцев.
• SPF — избегайте длинных цепочек include и превышения 10 DNS-запросов. Консолидируйте провайдеров.
• DMARC — одна запись TXT. Если длина большая, используйте несколько строк TXT-записи на уровне DNS (это один логический RR).
• TTL для DMARC 1–4 часа на этапах внедрения, затем 24 часа.
• Отдельные домены для критичных и массовых рассылок: это упрощает аналитику и снижает риски.

Минимальный конвейер парсинга и отчётности

1. IMAP-забор писем с фильтром по отправителю/теме DMARC в директорию по датам.
2. Распаковка архивов, валидация XML, пропуск дублей по report_id.
3. Парсинг полей в БД: provider, период, домен, политика, записи IP, результаты SPF/DKIM/DMARC.
4. Ежедневные задачи: пересчёт метрик за сутки, неделя/месяц; формирование CSV и сводки.
5. Алерты: всплеск Unknown senders, падение DKIM alignment, рост Fail на конкретном IP/организации.

Отчётность и парсер удобно держать на отдельном сервере: на VDS вы можете изолировать нагрузку, поставить PostgreSQL и Cron, не мешая боевым сервисам.

Как сопоставлять IP с организациями

Для удобства в отчётах держите привязку IP → ASN/организация. Этого нет в DMARC XML, но можно обогащать данные локальной БД (например, регулярной выгрузкой префиксов/ASN). Это поможет отличать, где трафик идёт от известных почтовых провайдеров, а где — от случайных узлов.

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

Даже при идеальных метриках DMARC часть писем может оказываться в спаме по другим причинам (контент, репутация IP, жалобы). Держите дополнительные показатели: соотношение DKIM vs SPF pass, долю писем, где DMARC pass обеспечен только SPF (риск при форварде), распределение по провайдерам. Это поможет выстроить приоритеты — например, усилить ставку на DKIM и единый домен подписи.

Чеклист перед включением p=reject

• DMARC pass ≥ 99% на боевом трафике за 14 дней.
• Отсутствие бизнес-критичных рассылок в списке Fail.
• Покрытие DKIM у всех источников и документированный список отправителей.
• Наличие алертов на регрессии и автообновление обогащающих справочников (ASN/организации).
• Включённый и проверенный rua для постоянного мониторинга.

Частые ошибки и как их избежать

• Оставили p=none навсегда. Без движения к карантину/отклонению защитной ценности нет.
• Забыли про поддомены: реальный трафик идёт с mail.sub.example.com, а sp не задан и политика не применена.
• Смешали разные домены в From и DKIM, при этом adkim=s. Уточните доменную стратегию: единый домен подписи или relaxed-режим, если допустимо.
• Слишком широкий ruf, постоянное fo=1. Достаточно включать форензику как инструмент расследований, а не мониторинга.
• Игнорирование дублей отчётов: у некоторых провайдеров встречаются повторные отправки за тот же период. Идентифицируйте по report_id и диапазону дат.

Итоги

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