Если DMARC-отчёты не приходят на внешний домен, проверьте не только адрес в rua, но и разрешение со стороны получателя отчётов. Оно публикуется в DNS получателя: одной правки записи вашего домена может быть недостаточно.
Диагностируйте цепочку по порядку: действующая DMARC-политика → разрешение внешнего адресата → приём почты → обработка отчёта. Отсутствие отчёта само по себе не доказывает, что исходящие письма не доставляются.
1. Уточните, какие отчёты пропали
Здесь речь об агрегированных отчётах, адрес которых задаёт rua. Это сводка за период, а не уведомление после каждого письма. Параметр ruf относится к другому виду отчётности и не заменяет rua.
Зафиксируйте, когда пришёл последний отчёт, от каких почтовых систем были отчёты раньше и что менялось: DNS-провайдер, почтовый ящик или сервис анализа. Если исчезли отчёты только одного отправителя, начните с этой ветки, а не с полной перенастройки почты.
Объём отчётности зависит от почтового трафика и доменов адресатов; для получения Google рекомендует отдельный ящик или группу. Это описано в инструкции Google по настройке DMARC. Не используйте отсутствие немедленного ответа на одно тестовое письмо как критерий поломки.
2. Прочитайте реальную запись rua
Для условного домена example.com выполните запрос:
dig TXT _dmarc.example.comПроверьте адрес после rua=mailto:: нет ли опечатки, старого сервиса или неверного имени ящика. Сверяйте ответ DNS с текущими реквизитами в кабинете получателя отчётов, а не только с тем, что сохранено в панели регистратора.
Если письма идут с поддомена, сначала выясните, откуда берётся применяемая DMARC-политика. Для следующего шага нужен домен, на котором она найдена; нельзя автоматически подставлять домен сайта, SMTP-сервера или DKIM-подписи.
Не меняйте p=reject на p=none ради доставки отчётов. Политика обработки исходящей почты и разрешение внешнему сборщику получать сводки решают разные задачи. Если проблема именно в результате проверки письма, используйте отдельный разбор SPF pass и DMARC fail.
3. Проверьте разрешение в DNS получателя
Предположим, политика находится у example.com, а в ней указан адрес rua=mailto:reports@example.net. Проверяемое имя будет таким:
dig TXT example.com._report._dmarc.example.netМинимальное разрешение — TXT со значением v=DMARC1;. Его размещает администратор DNS получателя, то есть стороны example.net. Публикация похожей записи в зоне отправителя не подтверждает согласие внешнего адресата. Такой порядок подтверждает документация Microsoft.
Как не перепутать части имени
Слева стоит домен найденной политики, затем _report._dmarc, справа — домен адреса из rua. Не заменяйте правую часть именем MX-сервера: запрос строится по адресу получателя отчётов.
Проверка внешнего назначения требуется при различии организационных доменов. Правило построения имени, обязательное начальное v=DMARC1 и отказ от отправки на неподтверждённый адрес определены в RFC 9990, разделе 4.
Если используется сторонний сервис, передайте ему полное проверяемое DNS-имя. Не создавайте собственное широкое разрешение со звёздочкой вместо точечной настройки, которую предлагает сервис.
4. Разделите отсутствие записи и сбой DNS
Смотрите полный ответ dig, включая статус и секцию ANSWER:
- NXDOMAIN — проверяемого имени нет. Сначала перепроверьте его сборку и зону размещения.
- NOERROR без TXT — имя может существовать, но нужная запись не получена.
- SERVFAIL или тайм-аут — проверка DNS не завершилась нормально; это не доказательство отсутствия разрешения.
- TXT найден — сверяйте значение и переходите к проверке почтового приёма.
После изменения сравните ответ авторитетного NS зоны получателя с ответом обычного резолвера. Если они расходятся, зафиксируйте TTL и время проверки; повторная правка той же записи не ускоряет истечение кэша. Проверьте также, не добавила ли DNS-панель имя зоны второй раз к полному имени записи.
5. Разрешение есть: ищите отчёт после DNS
Дальше разделите два случая: письмо не принято или принято, но не показано в интерфейсе анализа. Для своего ящика проверьте квоту, карантин, фильтры вложений и журнал доставки; для внешнего сервиса — подключён ли нужный домен к нужному аккаунту и нет ли ошибки импорта.
Если журнал показывает отклонение, сохраните время и SMTP-код. Если приём успешен, а график пустой, проверьте обработку вложения и выбранный период отчёта. Не меняйте SPF или DKIM наугад: это не исправит ошибку импорта.
Согласуйте с сервисом ожидаемый срок появления следующей сводки. Агрегированные отчёты обычно охватывают сутки, но DNS-кэш, формирование и доставка — отдельные этапы; наличие разрешения не гарантирует мгновенный отчёт. Формат периода и доставка описаны в RFC 9990.
Как подтвердить результат
Проверка закончена, когда разрешение читается снаружи, следующий отчёт принят и в нём указан ожидаемый домен и период после исправления. Сохраните эти три свидетельства: один успешный TXT-запрос подтверждает только DNS-этап.
Обычный HTTP-мониторинг Web-Puls полезен для доступности сайта, но не подтверждает доставку DMARC-сводок. Если нужна помощь с DNS или почтовой цепочкой, отправьте заявку на диагностику: укажите домен, время последнего отчёта и результаты проверок без паролей и содержимого переписки. Специалист оценит симптомы и предложит формат работ; стоимость согласуется до начала.