Отчёты DMARC на внешний домен не приходят: что проверить

Если отчёты DMARC не приходят на внешний домен, проверьте не только rua в политике отправителя, но и разрешение принимающей отчёты стороны. Затем исследуйте доставку и обработку полученных файлов. Отсутствие отчёта не означает, что писем не было или что вся исходящая почта проходит проверку.

Три участника, а не один почтовый ящик

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

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

На какую спецификацию опираться

В мае 2026 года опубликованы RFC 9989 о DMARC и RFC 9990 об агрегированных отчётах. Здесь проверка внешнего назначения рассматривается по разделу 4 RFC 9990. Старую инструкцию по RFC 7489 нельзя автоматически считать описанием всей действующей спецификации.

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

Внешняя сторона должна разрешить получение

RFC 9990 предусматривает проверку назначения за пределами соответствующего организационного домена. Разрешение подтверждается DNS-записью принимающей отчёты стороны. Одного адреса в rua владельца отправляющего домена для этого недостаточно. Смысл проверки — не позволять произвольно направлять поток отчётов несогласованному получателю.

При диагностике не упрощайте понятие внешнего назначения до любого отличающегося поддомена. Проверка спецификации опирается на организационные домены. Если отношения имён сложнее обычного example.com и example.net, специалисту нужно пройти соответствующий порядок, а не сравнить две текстовые строки на неравенство.

Учебный пример имени разрешения

Пусть политика находится для example.com и запрашивает агрегированные отчёты на reports@collector.example.net. Это вымышленные демонстрационные адреса. Для такой схемы имя подтверждения будет example.com._report._dmarc.collector.example.net, а значение подтверждающего TXT начинается с v=DMARC1.

Публикует это разрешение сторона collector.example.net в своей зоне, а не владелец example.com у себя «для удобства». В реальном сервисе используйте предоставленную им инструкцию: в ней могут быть дополнительные условия. Не копируйте учебное имя на рабочий домен и не добавляйте второй конкурирующий вариант наугад.

Кто за какую границу отвечает

Таблица — собственная карта ответственности. В рабочем журнале не заменяйте неизвестный результат предыдущим успешным шагом. Например, наличие разрешения не закрывает вопрос доставки, а найденное письмо не закрывает вопрос импорта вложения.

Разделите почтовую доставку и аналитический экран

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

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

Что проверять, если DNS выглядит правильно

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

Если отчёт уже получен, но не виден на панели, проверьте выбранный домен, интервал и состояние разбора. Не меняйте DNS сразу: причина может находиться позже в цепочке. А если известно только отсутствие данных на экране, сначала установите, не лежит ли файл среди необработанных поступлений.

Диагностика без ужесточения политики

1. Сохраните действующую политику, rua и точный домен, к которому относится ожидание.
2. Установите, требуется ли разрешение внешнего назначения, и проверьте его по актуальной схеме.
3. Разделите подтверждения DNS, приёма сообщения и разбора файла.
4. Сопоставьте доступные поступления с доменом, периодом и источником отчёта.
5. Исправьте найденный участок и оставьте контроль дальнейшего поступления с указанием неизвестных границ.

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

Что сохранить для следующей проверки

Запишите владельца каждой зоны, место приёма и ответственного за импорт. Если компания использует собственный почтовый сервер, его состояние описывайте отдельно от сервиса анализа. Смена подрядчика по отчётам требует проверки нового внешнего отношения, а не только нового адреса в панели.

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