Отчёты DMARC показывают наблюдаемые источники отправки вашим доменом, результаты SPF и DKIM с выравниванием и действия получателей. Они помогают находить возможные подделки и ошибки провайдеров. Но данные поступают только от участников отчётности и не доказывают ни полноту списка отправителей, ни отсутствие риска при ужесточении политики.
Многие команды публикуют DMARC и направляют rua= в ящик, но не анализируют XML. Тогда ошибки остаются незамеченными. Для основ полезны почта для малого бизнеса и создание почты на своём домене. Затем используйте отчёты как дополнение к учёту отправляющих систем, а не как полную опись всего трафика.
Соберите отчёты, определите законные источники, исправьте аутентификацию и выравнивание. Даже при успешном DKIM проверьте путь пересылки, прежде чем считать его безвредным. Ужесточайте политику на основании данных и тестов.
Что такое отчёты DMARC
Отчёты DMARC отправляют участвующие получатели после проверки писем с вашим доменом отправителя. Они содержат результаты аутентификации, сведения о выравнивании, IP источника и применённой обработке. Это полезно для диагностики доставки и безопасности, но охват не полный.
Есть два основных типа отчётов.
Агрегированные отчёты запрашиваются тегом rua и обычно приходят как сводки XML. Они группируют трафик по получателю, IP, результатам и обработке. Так можно изучить отправку через Google Workspace, Microsoft 365, SendGrid, Mailchimp, сервер приложения и неизвестные источники.
Отчёты об ошибках запрашиваются через ruf и могут содержать данные отдельных сообщений при неудачной аутентификации. Условия отправки зависят от настроек и не ограничены окончательным провалом DMARC. Поддержка непостоянна, в том числе из-за приватности. Рассматривайте их как дополнительный сигнал, а не основу всего процесса.
Для эксплуатации отчёты помогают ответить на вопросы:
- Какие источники замечены с моим доменом отправителя?
- Проходит ли их почта SPF или DKIM с выравниванием?
- Какие письма получатели помещают в карантин или отклоняют?
- Какие законные процессы могут пострадать при
p=quarantineилиp=reject?
Как запрашиваются отчёты DMARC
Запись TXT под _dmarc.yourdomain.com задаёт политику и адреса для агрегированных отчётов или отчётов об ошибках. Участвующие получатели могут отправлять туда данные. Для адреса на внешнем домене отчётности иногда требуется дополнительная авторизация через DNS.
Следующий пример задаёт наблюдение с необязательным строгим выравниванием:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"Запись запрашивает наблюдение без ограничений по DMARC и агрегированные отчёты на dmarc@example.com. adkim=s и aspf=s требуют точного совпадения доменов для соответствующего выравнивания. Строгие режимы необязательны; без них используется мягкое выравнивание по организационному домену. Выбирайте режим с учётом отправляющих систем.
Основные теги:
v=DMARC1: обязательная версия.p=: запрашиваемая обработка писем, не прошедших DMARC.rua=: адрес агрегированных отчётов.ruf=: адрес поддерживаемых отчётов об ошибках.pct=: доля не прошедших DMARC писем для запрашиваемых ограничений; получатели могут применять иначе.adkimиaspf: режимы выравнивания DKIM и SPF.
Формат и логика политики описаны в RFC 7489. Исходные отчёты часто приходят сжатыми XML-вложениями, которые нужно подготовить для удобного анализа.
Что находится внутри агрегированного отчёта DMARC
В отчёте указаны организация, IP, число сообщений, результаты и обработка. Различайте исходные результаты аутентификации и оценку DMARC: auth_results содержит проверки SPF и DKIM, а policy_evaluated отражает их оценку с выравниванием для DMARC.
Обычно отчёт содержит:
- Получателя, создавшего отчёт, например Google или Microsoft.
- Период наблюдения.
- IP отправляющего источника.
- Число замеченных сообщений от него.
- Результат SPF.
- Результат DKIM.
- Оценку SPF с выравниванием относительно видимого From.
- Оценку DKIM с выравниванием относительно видимого From.
- Обработку DMARC: none, quarantine или reject.
Не всякая ошибка SPF означает неверную базовую настройку. Пересылка меняет IP и может нарушить SPF. Если DKIM проходит с выравниванием, DMARC проходит.
Получатель: gmail.com
IP источника: 198.51.100.24
Количество: 842
From в заголовке: example.com
SPF: fail
DKIM: pass
DMARC: pass
Обработка: none
Такой результат может соответствовать рабочей пересылке. Всё равно подтвердите источник и путь. Успешная аутентификация не доказывает безопасность содержания или законность намерений отправителя.
Получатель: outlook.com
IP источника: 203.0.113.77
Количество: 314
From в заголовке: example.com
SPF: fail
DKIM: fail
DMARC: fail
Обработка: quarantine
Здесь нужна диагностика. Возможны неверная настройка источника, новый сервис без завершённой аутентификации, изменение письма при пересылке или подделка. Одни результаты не определяют причину однозначно.
Агрегированные отчёты и отчёты об ошибках
Агрегированные отчёты дают более широкий обзор трафика, замеченного участвующими получателями. Отчёты об ошибках иногда содержат детали отдельных сообщений. Первые обычно служат основной базой, но сами по себе не доказывают безопасность смены политики.
| Тип отчёта | Запрос | Содержимое | Применение | Практика 2025-2026 |
|---|---|---|---|---|
| Агрегированный | rua=mailto:... | Часто ежедневные XML-сводки по источникам, проверкам и обработке | Учёт отправителей, выравнивание, ввод политики | Важная, но неполная база данных |
| Об ошибке / криминалистический | ruf=mailto:... | Детали отдельных ошибок, иногда сокращённые или очищенные | Разбор конкретных сбоев или злоупотреблений | Ограниченная поддержка, нередко мало отчётов или их нет |
Выбирайте инструмент анализа, который понятно объясняет различия. Ценность отчёта в конкретных проверках и изменениях, которые можно выполнить на его основе.
Как эффективно читать отчёты DMARC
Начните с крупных источников и сопоставьте их бизнес-системам. Исправляйте их ошибки в первую очередь, но не забывайте редкие критичные операции перед ужесточением.
Возможный процесс:
- Выберите самые объёмные источники в агрегированных отчётах.
- Сопоставьте каждый системе: Google Workspace, Microsoft 365, маркетинговому сервису, приложению, поддержке или пока неизвестному источнику.
- Проверьте успешный SPF или DKIM с выравниванием к видимому From.
- Исправьте ошибки законных отправителей до смены политики.
- Исследуйте неизвестные источники как невыясненные: общий ретранслятор или пересылка не являются доказательством злоупотребления.
Работа с основными отправителями упрощает начало. Но низкий объём не означает низкую важность: добавьте отдельные тесты редких сообщений.
| Наблюдение | Возможная причина | Следующий шаг |
|---|---|---|
| SPF pass, DKIM pass, DMARC pass | Успешная аутентификация и выравнивание | Запишите источник и отдельно подтвердите его законность |
| SPF fail, DKIM pass, DMARC pass | Пересылка или проблема пути SPF | Проверяйте выравнивание DKIM и сохранение подписи |
| SPF pass, DKIM fail, DMARC pass | Ошибка DKIM при выровненном SPF | Исправьте DKIM, особенно для пересылки |
| SPF fail, DKIM fail, DMARC fail | Подделка, ошибка сервиса или изменение письма | Исследуйте источник и маршрут |
| Неизвестный IP с заметным объёмом | Неучтённый сервис, общий ретранслятор, пересылка или злоупотребление | Определите источник до решения о блокировке |
Типичные исправления:
- Добавить нужный SPF include законного отправителя.
- Включить DKIM у фактического провайдера исходящей почты.
- Настроить собственный Return-Path для выравнивания SPF.
- При необходимости перенести сервис на отдельный поддомен.
- Исследовать и исправить пересылку вместо опоры только на SPF.
Запросы DNS дополняют диагностику, но не заменяют реальные письма:
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +shortПо вопросам DNS полезны обязательные записи DNS и диагностика попадания в спам в документации TrekMail.
Какие проблемы выявляют отчёты DMARC
Отчёты могут показать незавершённую аутентификацию сервиса, неверное выравнивание, изменения при пересылке и настройки без анализа. Это помогает находить эксплуатационные пробелы.
Команда добавляет новый инструмент и начинает отправлять вашим доменом, не завершив SPF или DKIM. Незнакомый IP может указывать на это, но сначала нужно подтвердить его связь с реальным сервисом.
SPF может проходить для домена конверта, а DMARC не проходить из-за отсутствия выравнивания и успешного выровненного DKIM. Такое бывает с маркетинговыми и тикет-системами без собственного подходящего домена возвратов.
Зависимость только от SPF уязвима к пересылке. Если нет успешного выровненного DKIM, DMARC может не пройти. Изучите настройку и исправление пересылки почты и тестируйте фактический путь.
Запись p=none мало помогает эксплуатации, если никто не читает отчёты. Сбор данных сам по себе не устраняет ошибки.
Слишком ранний p=reject может нарушить законные процессы. Определите отправителей, проверьте критичные и редкие пути и подготовьте план действий при сбое.
Где помогает TrekMail
Отчёт полезен, когда вы можете выполнить конкретное исправление. TrekMail может упростить общую работу с доменами, DNS и отправкой, но проверка внешних источников и выравнивания остаётся необходимой.
Разрозненные хостинги, SMTP-сервисы и общий ящик XML-отчётов требуют дополнительной координации, особенно при добавлении новых отправителей.
Единая панель TrekMail может объединить размещение почты нескольких доменов, проверки DNS, собственный или управляемый SMTP, работу с ящиками, пересылку и миграцию. Возможности зависят от тарифа и настройки. Для клиентских доменов модель раскрывает почтовый хостинг нескольких доменов.
TrekMail предлагает собственные домены, ящики IMAP, catch-all, пересылку из ящиков, серверную миграцию IMAP, API и проверки DNS в зависимости от тарифа. На Nano можно настроить собственный SMTP по инструкции «Собственный SMTP». Соответствующие платные тарифы предлагают управляемый SMTP. Ценовой ориентир для Starter составляет от $3.50 в месяц. Nano предлагается бесплатно без карты; платные тарифы могут предоставлять 14-дневный пробный период с обязательной кредитной картой. Уточните актуальные условия.
Отчёты не исправляют настройки автоматически. Общая панель может упростить часть операций, но не отменяет диагностику причин.
Когда переходить с p=none на quarantine или reject
Отчёты дают основания для оценки, а не полный вывод о безопасности. Подтвердите законные источники учётом систем и реальными тестами. Не считайте неизвестные ошибки вредоносными или незначимыми без исследования.
Следующие записи являются альтернативами последовательных этапов, а не набором для одновременной публикации:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"Проверьте несколько циклов отчётности и отдельно редкие критичные письма. Подтвердите успешную аутентификацию с выравниванием и сохранение подписанных данных при пересылке. Процентные значения применяются получателями по-разному; обработка также зависит от локальных правил.
Для обычной прямой отправки в личные ящики Gmail Google требует SPF или DKIM. Массовым отправителям нужны SPF и DKIM, а также DMARC с выравниванием через хотя бы один успешный путь. Подробности есть в ответах на вопросы о требованиях к отправителям Gmail.
Итог: включите отчёты DMARC в рабочий процесс
Отчёты показывают наблюдаемые источники, успешные проверки и ошибки. Регулярно анализируйте их вместе со списком отправляющих систем и реальными тестами. Это инструмент конкретных улучшений, а не вложение, оставленное ради формального контроля.
Если доменов и провайдеров много, согласованное управление может помочь. TrekMail предлагает почту нескольких доменов с фиксированной тарифной моделью, общим хранилищем, миграцией IMAP, собственным или управляемым SMTP и инструментами аутентификации в зависимости от тарифа. Условия начала работы, цены и функции смотрите в тарифах TrekMail.
