Начните с проверки, куда приходят отчёты DMARC для вашего домена. Затем сопоставьте источники отправки с сервисами, которыми пользуется бизнес: корпоративной почтой, платформой рассылок и сайтом. Отчёты помогают заметить письма, которые не проходят проверку подлинности, и понять причину: ошибка настройки, пересылка или посторонний отправитель. Ниже разберём, какие поля читать, как отличить технический сбой от подмены домена и что проверить до усиления политики DMARC.
Как получить отчёты DMARC и подготовить их к проверке?
DMARC помогает почтовому серверу проверить, согласуется ли домен в видимом адресе отправителя с доменом, который подтвердил подлинность письма через SPF или DKIM. В настройке DMARC владелец домена также указывает желаемую обработку писем, которые эту проверку не прошли. Получатель учитывает политику, но окончательное решение принимает по своим правилам.
Для начала найдите TXT-запись DMARC в панели управления DNS. В ней параметр rua задаёт адрес для агрегированных отчётов. Если адреса нет, отчёты на ваш ящик поступать не будут. Если запись уже существует, сохраните её копию перед изменением и уточните, кто отвечает за настройки домена.
Агрегированный отчёт обычно приходит как XML-файл, иногда в архиве. Читать его вручную неудобно: записи описывают группы сообщений с общими признаками. Сервис разбора отчётов помогает увидеть источники отправки и результаты проверок в понятном виде. Сам отчёт не содержит текста писем и не заменяет статистику рассылочной платформы.
- Проверьте, что ящик из rua принимает письма и у ответственного сотрудника есть к нему доступ.
- Если отчёты принимает сторонний сервис, выполните его инструкцию по подтверждению приёма отчётов для вашего домена.
- Составьте список систем, которые отправляют почту от имени бизнеса, включая формы сайта и уведомления о заказах.
- Сопоставляйте отчёты с датами отправок: период отчёта и время его получения могут различаться.
Отсутствие отчётов ещё не означает, что ошибок нет. Проверьте адрес получателя, доставку служебных писем и то, были ли за нужный период отправки на почтовые сервисы, которые предоставляют такие отчёты.
Какие поля отчёта DMARC смотреть в первую очередь?
Откройте сводку по источникам отправки. В исходном XML адрес источника обозначается как source_ip, а количество сообщений в группе — count. Сначала найдите инфраструктуру своей корпоративной почты и платформы рассылок. Незнакомый IP сам по себе не доказывает подмену: сервис отправки может использовать несколько адресов или общий пул.
Следующий ориентир — header_from. Это домен из адреса, который получатель видит в поле «От кого». Именно с ним DMARC сопоставляет домены SPF и DKIM. Имя компании рядом с адресом в этой проверке не участвует.
- policy_evaluated показывает результаты проверки в контексте DMARC и обработку группы писем.
- auth_results содержит результаты отдельных проверок SPF и DKIM, а также домены, к которым они относятся.
- disposition помогает увидеть, какую обработку получатель указал в отчёте: без ограничений со стороны DMARC, карантин или отклонение.
- reason, если присутствует, помогает понять, почему получатель отступил от обычной обработки по политике.
Ключевая деталь: успешная проверка SPF или DKIM сама по себе ещё не означает успех DMARC. Нужна согласованность доменов, которую также называют alignment. Для прохождения DMARC достаточно успешного и согласованного результата хотя бы по одному из этих механизмов.
Например, платформа может подписать письмо своим техническим доменом. DKIM при этом пройдёт, но такая подпись не подтвердит право использовать домен вашего магазина в поле «От кого». Если согласованной проверки SPF тоже нет, письмо не пройдёт DMARC. Поэтому смотрите одновременно на результат проверки и на домен, который её прошёл.
Как отличить ошибку настройки от пересылки или подмены?
Разбирайте проблемные группы по источнику отправки. Для каждой установите владельца системы и назначение писем. У бизнеса рассылка, ответы менеджеров и уведомления сайта нередко идут через разные сервисы. Настройка основной почты не подтверждает автоматически остальные источники.
Если сбой относится к вашей платформе рассылок, сравните DNS-записи с её текущей инструкцией. Проверьте, включена ли подпись DKIM для вашего домена и какой домен платформа использует для SPF. Изменение названия отправителя в редакторе письма эти настройки не исправляет.
При пересылке сообщения меняется сервер, который передаёт его конечному получателю. Из-за этого SPF может завершиться неуспешно. При этом подпись DKIM иногда сохраняется и позволяет письму пройти DMARC. Если посредник изменил содержимое, подпись тоже может перестать проходить проверку. Такой случай требует разбора маршрута письма, а не немедленного удаления источника из рабочих отправок.
Когда источник неизвестен, сверьте его с подрядчиками и подключёнными системами. Не добавляйте незнакомый IP в SPF только ради исчезновения ошибки в отчёте: так можно разрешить отправку посторонней инфраструктуре. Сначала подтвердите, что источник действительно отправляет ваши письма.
Если принадлежность источника установить не удалось, а согласованных проверок нет, рассматривайте его как подозрительный. Сохраните данные группы и продолжайте наблюдение. Отчёт показывает технический результат, но не раскрывает намерения отправителя.
Как исправлять ошибки и проверять результат?
Начните с известных рабочих источников, у которых есть сбои DMARC. Для малого бизнеса это понятная очередь: сначала системы, через которые клиенты получают ответы и подтверждения, затем маркетинговые отправки. У каждой ошибки должен быть ответственный и конкретная проверка после исправления.
- Выберите одну проблемную группу и подтвердите, какой сервис отправил эти письма.
- Сверьте SPF, DKIM и домены отправителя с инструкцией этого сервиса.
- Отправьте тестовое письмо через тот же сценарий, в котором возникла ошибка.
- Проверьте служебные заголовки теста, затем найдите результат в отчёте за соответствующий период.
- Зафиксируйте изменение и переходите к следующему источнику, если проверка прошла успешно.
Проверяйте именно рабочий сценарий. Тест из редактора рассылки не всегда повторяет отправку из автоматической цепочки, а письмо из личного ящика сотрудника ничего не говорит о настройках формы сайта. Для уведомления о заказе нужен тестовый заказ, для автоматического письма — запуск соответствующего события.
Отдельно оценивайте доставляемость. Успешный DMARC подтверждает согласованность доменов, но не гарантирует попадания во входящие: на результат влияют репутация отправителя и другие проверки. Если письма проходят аутентификацию, но возникают проблемы у конкретного получателя, пригодится настройка постмастера Яндекс для анализа рассылок.
Не усиливайте политику только потому, что последняя маркетинговая кампания прошла без ошибок. В отчётный период могли не попасть редкие отправки: счета, письма из формы обращения или восстановление доступа. Сначала проверьте каждый известный канал, включая те, которыми пользуются нерегулярно.
Если домен обслуживают разные подрядчики, соберите для разбора запись DMARC, сводку источников и заголовки проблемного теста. Это конкретная задача для аудита доставляемости: установить принадлежность источников, найти рассогласование доменов и подготовить порядок изменений. Пароли от почтовых ящиков для первичного разбора не нужны.
Типичные ошибки при чтении отчётов DMARC
- Считать любой результат pass подтверждением DMARC. Проверяйте, какой механизм сработал и согласован ли его домен с header_from.
- Принимать disposition без ограничений за доказательство доставки во входящие. Это поле описывает обработку по DMARC, а не папку получателя.
- Объявлять незнакомый IP атакой без проверки. Уточните инфраструктуру платформы и маршрут пересылки.
- Усиливать политику после проверки только массовой рассылки. Проверьте также корпоративную почту и автоматические уведомления.
- Исправлять сразу несколько настроек без записи изменений. Сохраните исходные значения и проверяйте результат каждого изменения отдельно.
Начните сейчас с действия на две минуты: откройте последний отчёт DMARC и выпишите один источник с ошибкой, указав его IP, домен header_from и результат проверки. Этой записи достаточно, чтобы задать предметный вопрос администратору или поддержке платформы рассылок.
