Почему приходят письма от noreply-dmarc-support@google.com, что означают DMARC-отчёты для email-аутрича и что с ними делать.
После настройки домена для email-аутрича на почту могут начать регулярно приходить сообщения от noreply-dmarc-support@google.com, noreply@dmarc.yahoo.com и других похожих адресов. В теме обычно указаны Report Domain, Submitter и Report-ID, текста внутри почти нет, а к письму прикреплён небольшой файл с расширением .xml или .xml.gz.
dmarc письма
Такие сообщения выглядят необычно, особенно когда появляются вскоре после запуска первой кампании. Письмо приходит от крупного почтового провайдера, содержит название вашего домена и техническое вложение, поэтому его легко связать с жалобами получателей, блокировкой почтовых ящиков или ухудшением доставляемости.
Это стандартный агрегированный отчёт DMARC. Google, Yahoo и другие почтовые системы формируют его после обработки сообщений, в которых ваш домен использовался в поле отправителя, а затем направляют собранную статистику на адрес, указанный в настройках самого домена.
Само получение такого письма не указывает на жалобу на рассылку, блокировку домена, попадание писем в спам или взлом почтового ящика.
В двух словах
Письма от noreply-dmarc-support@google.com содержат агрегированные отчёты DMARC. Они приходят потому, что в DNS-записи вашего домена указан адрес для получения такой статистики. Google сообщает, какие почтовые серверы отправляли письма с вашим доменом в поле From и как эти сообщения прошли проверки SPF, DKIM и DMARC. Срочной реакции на каждое такое письмо обычно не требуется.
При подготовке домена к аутричу обычно настраивают SPF, DKIM и DMARC.
Последний механизм задаётся публичной TXT-записью в DNS, которая размещается по адресу _dmarc.ваш-домен.
Запись может выглядеть следующим образом:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Параметр rua содержит адрес, на который почтовые провайдеры могут присылать агрегированные DMARC-отчёты. В приведённом примере отчёты будут поступать на dmarc@example.com. Если во время настройки туда внесли ваш основной рабочий адрес, письма от Google, Yahoo и других провайдеров начнут появляться непосредственно во входящих.
Адрес мог быть добавлен владельцем домена, сотрудником, подрядчиком или автоматически сформирован по инструкции сервиса, через который настраивалась почтовая инфраструктура. Сам параметр rua не запускает дополнительные проверки и не влияет на объём отправки. Он сообщает принимающим почтовым системам, куда следует передавать результаты уже выполненных проверок. Наличие rua служит непосредственной причиной доставки агрегированных отчётов на указанный адрес.
Google отправляет такой файл после того, как его серверы получили письма, в видимом поле From которых использовался ваш домен. Например, если вы отправили холодное письмо с адреса anna@example.com человеку с ящиком Gmail, принимающая инфраструктура Google проверит сообщение и сможет включить результат в очередной отчёт по домену example.com.
По такому же принципу Yahoo формирует отчёт, когда письма получают пользователи Yahoo Mail. Другие почтовые системы создают собственные отчёты по той части трафика, которую обработали их серверы. В результате один домен может получать несколько файлов за один отчётный период, поскольку адресаты рассылки пользуются разными почтовыми провайдерами.
Значение Submitter: google.com в теме означает, что отчёт подготовила инфраструктура Google. Оно не указывает сервис, через который выполнялась отправка, и не сообщает о том, что Google участвовал в вашей рассылке в качестве исходящего провайдера.
Стандарт DMARC рекомендует принимающим почтовым системам формировать агрегированные отчёты как минимум раз в 24 часа, хотя конкретный провайдер вправе выбрать другую периодичность или вовсе не отправлять отчёты. Поэтому при активной отправке новые файлы часто появляются ежедневно.
DMARC-отчёт показывает, какие почтовые серверы передавали сообщения с вашим доменом в поле отправителя, сколько таких сообщений увидел конкретный провайдер и как они прошли проверки почтовой аутентификации.
Тема письма обычно выглядит следующим образом:
Report Domain: example.com
Submitter: google.com
Report-ID: 16221106251442986354
Report Domain указывает домен, по которому собрана статистика. Submitter называет почтовую организацию, подготовившую файл. Report-ID является уникальным идентификатором отчёта и помогает системам обработки распознавать дубликаты. Такой формат темы закреплён в стандарте агрегированных DMARC-отчётов.
Во вложении находится XML-файл, который часто сжимается с помощью GZIP, поэтому почтовый интерфейс показывает его как небольшой архив. Внутри содержатся отчётный период, опубликованная политика DMARC, IP-адреса серверов, количество обработанных сообщений, домены из технических заголовков и результаты SPF, DKIM и DMARC. Стандартными форматами вложения являются .xml и .xml.gz.
Для понимания результатов полезно различать задачи трёх механизмов. SPF проверяет, разрешено ли конкретному серверу отправлять почту для технического домена возвратного адреса. DKIM проверяет цифровую подпись сообщения. DMARC сопоставляет успешно проверенный SPF- или DKIM-домен с доменом в видимом поле From, которое видит получатель.
Письмо проходит DMARC, когда хотя бы один механизм, SPF или DKIM, одновременно проходит аутентификацию и использует домен, согласованный с доменом отправителя. Поэтому отдельное значение spf=pass или dkim=pass ещё не всегда означает общий DMARC pass: сторонний сервис может корректно подтвердить собственный технический домен, который не связан с доменом в поле From. Такое сопоставление называется alignment.
Для человека, который запускает аутрич, практический смысл отчёта состоит в возможности увидеть инфраструктуру, фактически использующую домен. В данных могут появляться Google Workspace, Microsoft 365, серверы аутрич-платформы, CRM, форма на сайте, сервис календарных приглашений, helpdesk, система уведомлений и другие подключённые инструменты.
Успешный DMARC показывает, что использование домена в поле отправителя было подтверждено через согласованный SPF или DKIM. Этот результат не описывает содержание письма, качество базы, реакцию получателя или репутацию отправителя. Стандарт DMARC прямо указывает, что успешная проверка подтверждает авторизованное использование домена и сама по себе не гарантирует попадание сообщения во входящие.
По агрегированному отчёту нельзя определить:
DMARC-отчёт описывает аутентификацию домена. Для полноценного анализа доставляемости нужны дополнительные данные, включая ответы почтовых серверов, bounce-коды, статистику жалоб, репутационные показатели и фактические результаты кампаний.
В агрегированном файле также отсутствуют адреса конкретных получателей и тексты отправленных писем. Данные группируются по серверным IP-адресам и результатам проверок. Согласно действующему стандарту, такие отчёты не должны содержать личные почтовые адреса, IP-адреса отдельных пользователей или содержимое сообщений.
Отвечать на каждое письмо, скачивать каждый архив и вручную читать XML не требуется. Эти файлы предназначены прежде всего для автоматической обработки, а их практическая ценность появляется после объединения данных за несколько дней и от нескольких принимающих провайдеров.
Для работы с отчётами достаточно выстроить простой порядок.
Если домен только настроен, а в отчётах видны ожидаемые почтовые провайдеры и успешный DMARC, дополнительных действий обычно не требуется. Письма можно хранить в отдельной папке или передавать в анализатор.
Само появление письма от noreply-dmarc-support@google.com не создаёт срочную задачу. Внимания требуют результаты внутри отчётов, особенно когда одна и та же ситуация повторяется несколько дней или возникает после изменения почтовой инфраструктуры.
Знакомая система регулярно получает DMARC fail. Если вы узнаёте Google Workspace, Microsoft 365, свою аутрич-платформу или CRM, а сообщения от этого источника постоянно не проходят DMARC, конфигурацию следует проверить. Причиной может быть отсутствующая DKIM-подпись вашего домена, несогласованный возвратный адрес, ошибка в SPF, неверный DKIM-селектор или неполная настройка стороннего сервиса.
В отчётах появился неизвестный источник с заметным объёмом. Такой источник может принадлежать старой интеграции, форме на сайте, веб-серверу, подрядчику или сервису, о котором не знает текущая команда. Возможна и попытка подделки домена. Одного значения fail недостаточно для вывода о взломе, поэтому сначала нужно определить владельца IP-адреса и сопоставить период отправки с реальной активностью компании.
Неизвестный источник получает DMARC pass. Эта ситуация заслуживает более внимательной проверки, поскольку успешный результат означает, что источник располагает согласованной SPF-авторизацией или DKIM-подписью. Иногда так обнаруживается забытый легитимный сервис, слишком широкая SPF-запись или доступ сторонней системы к действующей отправляющей инфраструктуре.
После изменения DNS резко выросло количество неуспешных проверок. Если проблема появилась после замены почтового провайдера, подключения аутрич-платформы, изменения SPF или выпуска нового DKIM-ключа, сначала следует проверить именно последнее изменение.
Известные рабочие письма перестали проходить DMARC. Такая картина может отразиться на обработке сообщений, особенно при строгой политике домена. Для каждого легитимного источника нужно определить, какой механизм обеспечивает прохождение DMARC: согласованный SPF, согласованный DKIM или оба сразу.
DMARC fail не подтверждает компрометацию домена или почтового ящика. В агрегированных отчётах смешиваются легитимные потоки с ошибками конфигурации, пересланные сообщения и попытки неавторизованного использования домена. Стандарт DMARC прямо предусматривает, что отчёты помогают находить как злоупотребления, так и собственные почтовые системы с отсутствующей или несогласованной аутентификацией.
Если в записи установлено p=none, владелец домена использует DMARC в режиме мониторинга и не запрашивает специальную обработку сообщений, не прошедших проверку. Почтовый провайдер при этом продолжает применять собственные антиспамовые и репутационные фильтры. Значение p=none не гарантирует доставку во входящие, однако снижает риск того, что легитимное письмо будет помещено в карантин или отклонено именно из-за заявленной DMARC-политики.
Агрегированные отчёты направляются на адрес, указанный в параметре rua. Если удалить этот параметр из DNS-записи, у принимающих почтовых систем не останется адреса для доставки новой статистики.
До изменения запись может выглядеть так:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
После удаления адреса для отчётов:
v=DMARC1; p=none
Политика DMARC продолжит действовать, поскольку её определяют остальные параметры записи. Удаляется только запрос на отправку агрегированных отчётов.
Для прекращения отчётов не нужно удалять всю запись _dmarc или отключать SPF и DKIM. Такие действия затронут аутентификацию домена и способны создать отдельные проблемы с почтовой инфраструктурой.
После изменения DNS отдельные файлы могут продолжать приходить некоторое время, поскольку часть провайдеров уже сформировала отчёты или использует кэшированную версию записи. Стандарт допускает смешанные отчёты во время распространения изменений политики между принимающими системами.
При работающем аутриче чаще имеет смысл изменить адрес в rua, направив отчёты в отдельный ящик или сервис анализа. Полное отключение избавляет от входящих файлов, одновременно убирая источник данных об ошибках аутентификации и неизвестных отправителях.
Нет. Письмо от noreply-dmarc-support@google.com содержит техническую статистику о проверке сообщений, в которых использовался ваш домен. В агрегированном отчёте нет информации о нажатии кнопки «Спам» конкретным получателем.
Нет. DMARC-отчёт не показывает размещение сообщений во входящих или спаме. Даже успешный DMARC подтверждает только авторизованное использование домена и не гарантирует попадание во входящие.
Отдельный DMARC fail такого вывода не подтверждает. Его причиной может быть ошибка настройки легитимного сервиса, пересылка письма, несогласованный технический домен или попытка подделки адреса. Источник нужно идентифицировать по IP-адресу, объёму и времени появления.
Стандартное вложение агрегированного отчёта имеет формат XML или XML, сжатого с помощью GZIP. Файлы с расширениями .xml и .xml.gz соответствуют нормальному формату DMARC. Вручную открывать их необязательно, особенно если отчёты автоматически попадают в анализатор. Исполняемый файл, офисный документ с макросами или вложение другого неожиданного типа не является стандартным DMARC-отчётом.
Отображаемый адрес отправителя теоретически можно подделать, поэтому при необычном формате письма имеет смысл посмотреть результаты SPF, DKIM и DMARC самого сообщения в почтовом интерфейсе. Стандарт требует, чтобы письма, доставляющие агрегированные отчёты, сами проходили согласованную DMARC-проверку.
Нет. Агрегированный отчёт содержит сгруппированные технические данные и не включает личные почтовые адреса, пользовательские IP-адреса или содержимое сообщений.
Нет. Такие сообщения формируются автоматически, а адрес отправителя обычно не предназначен для переписки. Если отчёт показывает проблему, её исправляют в DNS, настройках почтового провайдера или аутрич-платформы.
Report Domain указывает домен, использование которого анализировалось. Submitter называет почтовую систему, сформировавшую отчёт. Report-ID является уникальным идентификатором файла и помогает обнаруживать повторно отправленные отчёты.
Для владельца аутрич-домена письма от noreply-dmarc-support@google.com служат регулярной технической сводкой. Они появляются из-за адреса в параметре rua, не сообщают о жалобе или блокировке и позволяют увидеть, какие системы используют домен и насколько корректно настроена их почтовая аутентификация.
При небольшом количестве отчётов их достаточно складывать в отдельную папку. Для нескольких доменов и активных кампаний удобнее выделить отдельный адрес или подключить DMARC-анализатор, чтобы ежедневные XML-файлы превращались в общую картину отправляющих сервисов и результатов проверок.
DMARC-отчёты помогают контролировать техническую сторону отправки. В Coldy можно собрать базу компаний, найти контакты нужных сотрудников, прогреть почтовые ящики, настроить цепочки писем и отслеживать результаты кампаний в одном месте.
Регистрируйтесь в Coldy и запустите первую кампанию.
