Отчёты DMARC: как читать объёмы и разбирать ошибки

В почтовом ящике появились вложения с отчётами DMARC. В одном три записи, в другом несколько десятков, а панель показывает процент ошибок. Владельцу нужно понять, сломалась ли отправка сайта и можно ли менять политику домена. Для этого недостаточно посчитать красные строки. Сначала выясняют, что именно наблюдал составитель отчёта, сколько сообщений относится к каждой записи и каким известным отправкам соответствует источник.

Ниже — порядок работы со сводными отчётами, а не инструкция автоматического ужесточения политики. Формат агрегированной отчётности описан в RFC 9990, опубликованном в мае 2026 года; основной протокол — в RFC 9989. Оба документа заменяют соответствующие положения прежнего RFC 7489. При чтении старых выгрузок учитывайте их формат, не объявляя неизвестное поле ошибкой только из-за отличия от нового примера.

Что выписать перед подсчётом процентов

Начните с составителя, идентификатора отчёта, периода и домена политики. Рядом сохраните исходный файл и отметку об импорте. Это помогает понять, что вы сравниваете: повтор того же отчёта, наблюдение другой принимающей системы или следующий временной интервал. Числа без такого контекста легко складываются в красивую, но необъяснимую сумму.

В рабочей таблице полезно хранить отдельные столбцы для времени наблюдения и времени получения файла. Отчёт, пришедший утром, может относиться к предыдущему периоду. Если команда в этот момент исправила отправку, нельзя автоматически отнести всё содержимое нового вложения к конфигурации после изменения. Сначала сопоставьте границы интервала с журналом работ.

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

Одна запись не означает одно письмо

Внутри row поле count сообщает количество сообщений для указанного сочетания результатов. Поэтому три записи могут описывать тысячу наблюдений, а не три письма. Это важно для любого процента: нужно взвешивать строки их количеством. Простое деление числа неуспешных записей на число всех записей отвечает на другой вопрос.

Возьмём вымышленный отчёт с тремя группами. Первая содержит 900 сообщений с успешным согласованным DKIM. Вторая — 90 сообщений без успешного согласования по двум проверкам. Третья — 10 сообщений с успешным согласованным SPF. В примере классификация уже выполнена по соответствующим результатам DMARC, а не по случайным словам pass в исходных проверках.

Доля неуспешных наблюдений равна 90 / 1000 = 9%. Доля неуспешных строк — одна из трёх, примерно 33,3%. Второе число не описывает долю сообщений. В интерфейсе подпишите числитель и знаменатель, чтобы пользователь мог проверить, из чего получен показатель. Крупная круговая диаграмма не должна скрывать различие этих двух способов подсчёта.

Результат проверки и действие получателя — разные поля

В policy_evaluated находятся результаты согласования DKIM и SPF и disposition — результат применения политики. В auth_results представлены результаты механизмов без интерпретации относительно DMARC. Нельзя переносить любую успешную исходную проверку в колонку успешного согласования. Для понимания доменов отдельного сообщения есть разбор строгого DMARC.

Действие получателя также не следует переименовывать в «письмо прочитано» или «попало во входящие». Сохраните исходное значение и его понятное пояснение в рамках формата. Если в отчёте приведена причина отличающейся обработки, рассматривайте её вместе с результатами. Не стирайте такое пояснение ради единой красной или зелёной отметки.

В рабочем отчёте владельцу полезно отдельно показать состояние аутентификации, наблюдаемую обработку и степень установленности источника. Тогда 90 неуспешных сообщений из примера не превращаются автоматически в 90 потерянных заявок. Чтобы проверить отправку конкретной регистрации, нужны также сведения приложения и контролируемая проверка соответствующего сценария, а не только агрегированная строка.

Свяжите источники с реестром собственных отправок

Создайте небольшой перечень: письма сотрудников, регистрация сайта, восстановление доступа, уведомления о заказах и другие реально используемые потоки. Для каждого укажите ответственного и подтверждённое подключение. Не считайте, что один успешно настроенный почтовый ящик доказывает правильность всех приложений компании. Реестр нужен именно для поиска расхождений между известными процессами и наблюдением.

Сопоставление делайте по совокупности подтверждённых сведений. Один IP-адрес сам по себе не устанавливает, какому бизнес-процессу принадлежало письмо. В журнале исследования оставьте состояния «известный источник», «проверяется» и «не установлен». Последнее не равно автоматически доказанной подделке. Оно означает, что команда пока не получила достаточного объяснения.

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

Смотрите отдельно на собственные сообщения

В общем учебном наборе группа Б содержит 90 неуспешных наблюдений. Допустим, после проверки команда установила, что 30 относятся к её уведомлениям, а происхождение остальных 60 пока не подтверждено. Теперь есть две разные рабочие задачи. Для 30 требуется исправить собственный поток, для 60 — продолжить разбор. Итог 9% остаётся арифметически верным для первоначального набора, но уже недостаточно описывает приоритеты.

Если известными подтверждены все 900 сообщений группы А, все 10 группы В и только 30 группы Б, доля неуспешных среди известных составит 30 / 940, примерно 3,19%. Это другой показатель с другим знаменателем. Его нельзя сравнивать с общими 9% как доказательство улучшения: изменился состав рассматриваемой совокупности, а не обязательно качество отправки.

Сохраняйте обе классификации и дату уточнения. В противном случае повторное открытие старого отчёта покажет другое число без объяснения. Для руководителя полезнее видеть, что источник удалось установить, чем получить искусственное падение процента ошибок. Обновление знания об источнике и исправление конфигурации являются разными событиями.

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

После изменения настройки выберите сопоставимые интервалы и отметьте составителей отчётов. Сравнение десяти сообщений одного потока с тысячей сообщений другого не доказывает эффект исправления. Рядом с процентом показывайте абсолютные количества и состав известных источников. Если наблюдений мало или их набор изменился, прямо обозначьте ограничение сравнения.

Не переносите результат одного отчёта на всю корпоративную почту. У вас есть определённый набор полученных наблюдений. Для утверждения о конкретном сервисе нужна связь с его отправками; для вывода о доставке — другие подходящие данные. Отсутствие новой ошибки в выбранной выгрузке само по себе не доказывает, что каждое письмо сайта дошло до нужного человека.

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

Что передать специалисту по сопровождению

Подготовьте исходный отчёт, период, выбранные группы, их count и реестр известных отправок. Отдельно укажите утверждения, которые пока являются гипотезами. В задаче полезно написать «30 наблюдений нашего сценария без успешного согласования», а не «вся почта не работает». Такая формулировка задаёт проверяемый объём и не мешает обнаружить другие причины недоставки.

Сам отчёт тоже является внешним входным материалом: RFC 9990 отдельно рассматривает возможность ложных данных. Поэтому не запускайте автоматическое изменение DNS по содержимому вложения. При ручном разборе достаточно отделить наблюдение, подтверждённый источник и решение администратора. Принятое изменение проверяют своим контролируемым сценарием и последующей сопоставимой отчётностью.

Результат первого разбора — перечень объяснённых потоков, открытых вопросов и конкретных задач. В нём остаются исходные количества, знаменатели процентов и границы наблюдения. С таким журналом сводная отчётность помогает сопровождать почту, вместо того чтобы служить поводом случайно менять доменную политику после каждой красной строки.