термин · проверка DMARC

Как проверить DMARC для писем приложения?

Проверка DMARC должна подтвердить четыре отдельных факта: в DNS обнаруживается корректная политика, её обязательные теги правильно разбираются, хотя бы один аутентифицированный идентификатор SPF или DKIM в реальном письме выровнен с видимым доменом From, и все легитимные отправители приложения учтены до перехода к режиму применения. Запросите имя _dmarc, изучите запись, а затем проанализируйте результаты аутентификации контрольных писем. Прохождение DMARC подтверждает авторизованное использование домена; оно не доказывает доставку или попадание во «Входящие».

Проверка DMARC — это четыре теста, а не один запрос

Полезная проверка состоит из четырёх уровней. Первый — найти политику, которая применяется к домену автора письма. Второй — проверить TXT-запись именно как политику DMARC, а не принимать любой текст, возвращённый DNS. Третий — протестировать выравнивание идентификаторов на реальном письме: домен MAIL FROM, прошедший SPF, или домен проверенной подписи DKIM должен быть выровнен с доменом в видимом заголовке From. Четвёртый — подтвердить операционный охват, отправив письма через каждое легитимное приложение, провайдера, регион и класс писем, использующие домен. Зелёный результат DNS-запроса покрывает лишь часть первых двух уровней. Он не показывает, что провайдер подписывает письма нужным доменом, что собственный return path активен, что пересылка изменила поведение SPF или что забытая система переживёт политику с режимом применения.

Запрашивайте правильное DNS-имя и следуйте правилам обнаружения политики

Начните с точного домена из заголовка From по RFC5322 — его часто называют доменом автора. Запросите TXT-запись по имени _dmarc, за которым следует этот домен. Для письма от alerts@notify.example.test начинайте с _dmarc.notify.example.test, а не с имени веб-сайта, MX-сервера или домена return path. RFC 9989 описывает обнаружение политики шире, чем один запрос: если у домена автора нет корректной записи, получатель может пройти по дереву DNS и найти применимую политику организационного домена или публичного суффикса. Обработка поддоменов может определяться тегом sp, np или p — в зависимости от того, что задано и где найдена политика. Поэтому инструмент проверки должен сообщать и запрошенное имя, и фактически выбранный домен политики. Результат, в котором сказано лишь «запись найдена», может скрывать ошибки наследования или явную политику поддомена, меняющую ожидаемую обработку.

Проверяйте структуру записи, прежде чем интерпретировать политику

Запись политики DMARC использует синтаксис тег—значение. Согласно RFC 9989, v=DMARC1 обязателен, чувствителен к регистру и должен стоять первым; действительный тег p задаёт запрошенную политику оценки. Распространённые значения политики: none, quarantine и reject. Необязательные теги описывают адреса для отчётов, поведение поддоменов и строгое или мягкое выравнивание SPF и DKIM. Не исправляйте молча теги с опечатками, отсутствующее значение p, дублирующиеся или конфликтующие записи, неверные разделители или значение с артефактами кавычек DNS-провайдера. Считайте постоянную ошибку оценки результатом, требующим исправления, а не успешным или неуспешным DMARC. Также отличайте временную ошибку DNS-запроса от некорректной записи. Повторите временный сбой резолвера по контролируемому пути, но не утверждайте, что у домена нет политики, пока невозможно надёжно запросить авторитетный DNS.

Проверьте выравнивание SPF и DKIM на реальном письме

DMARC оценивается по аутентификации письма, а не по настройкам DNS в отрыве от него. Для SPF сравните аутентифицированный домен MAIL FROM с видимым доменом From. Для DKIM сравните домен d= каждой успешно проверенной подписи с видимым доменом From. Мягкое выравнивание допускает домены с одним и тем же организационным доменом; строгое требует полного совпадения доменов. Письмо проходит, если хотя бы один аутентифицированный идентификатор проходит проверку своего механизма и выровнен. Например, return path провайдера может обеспечить прохождение SPF для домена провайдера, но остаться невыровненным с billing.example.test. Если DKIM проходит проверку с d=example.test при мягком выравнивании, письмо всё равно может пройти DMARC. Сохраняйте исходный заголовок Authentication-Results из контрольных ящиков получателей, но интерпретируйте его в контексте: он отражает результат конкретного проверяющего получателя и может содержать несколько переходов или подписей.

Точно интерпретируйте результаты pass, fail, none и error

Успешный DMARC означает, что применяется запись политики и аутентифицированный идентификатор SPF или DKIM выравнивается с доменом автора. Неуспешный означает, что политика применяется, но нет выровненного аутентифицированного идентификатора. None означает, что применимая политика не найдена. Permerror и temperror указывают на ошибки при вычислении DMARC; письмо с ошибкой DNS нельзя считать успешно или неуспешно прошедшим DMARC. Эти результаты не говорят, в какую папку почтовый провайдер поместил письмо. RFC 9989 прямо ограничивает успешный результат подтверждением того, что использование было разрешено владельцем домена; он не утверждает, что письмо безопасно, ожидаемо, имеет хорошую репутацию или достойно «Входящих». В диагностике и на панелях управления ведите отдельные поля для принятия провайдером, принятия сервером получателя, результата DMARC, сигналов жалоб и наблюдаемого размещения.

Составьте карту всех легитимных отправителей до перехода к режиму применения

Составьте список всех систем, которые указывают домен в From: продакшен-приложения, письма аутентификации, уведомления об оплате, инструменты поддержки, маркетинговые платформы, оповещения мониторинга, CRM-сценарии, региональные аккаунты и аварийные системы. Для каждого потока зафиксируйте видимый домен From, домен MAIL FROM, домен d= и селектор DKIM, аккаунт провайдера, владельца, класс писем и ожидаемый объём. Отправьте контрольные письма обычным продакшен-путём и проверьте и аутентификацию, и выравнивание. Агрегированные отчёты DMARC могут показать источники, использующие домен, но их нужно интерпретировать, и в них может попадать пересылка или неавторизованный трафик. Пока список неполный, начинайте с мониторинга, затем исправьте легитимные невыровненные потоки и только после этого запрашивайте более строгую обработку у получателей. Не меняйте общую политику организации только ради того, чтобы одно приложение стало «зелёным», и не переходите к режиму применения по результатам одного тестового письма.

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

Если политика не найдена, проверьте DNS-зону и имя записи, прежде чем менять значение. Если запись вызывает постоянную ошибку, оставьте одну корректную политику и проверьте порядок и синтаксис тегов. Если DKIM не проходит, проверьте, существует ли ожидаемый селектор, действительно ли провайдер подписал тестовое письмо, не изменились ли тело или подписанные заголовки в пути и выровнен ли проверенный домен d=. Если SPF проходит, а DMARC — нет, сравните домен MAIL FROM с видимым доменом From, а не считайте любое прохождение SPF достаточным. Если не проходят только пересланные письма, помните: пересылка часто меняет путь конверта и может ломать SPF, тогда как корректная выровненная подпись DKIM может сохраниться. Если развёртывание приводит к отклонению писем, сохраните заголовки неудачных писем и ответ получателя, остановите дальнейшее ужесточение политики и исправьте проблемный поток, а не ослабляйте несвязанные механизмы аутентификации.

Осознанно применяйте правила выравнивания конкретного провайдера

Сторонним отправителям нужна настройка, привязывающая их аутентифицированные идентификаторы к домену, которым управляет организация. Amazon SES документирует два пути: выровненный собственный домен MAIL FROM для SPF и выровненный домен подписи DKIM. Его return path по умолчанию, принадлежащий провайдеру, может проходить SPF, не будучи выровненным с видимым доменом From, поэтому на практике выровненным механизмом часто оказывается DKIM, если не настроен собственный домен MAIL FROM. Другие провайдеры по-разному называют return path, домены для отказов, аутентификацию домена и идентификаторы подписи. Проверяйте фактически отправленное письмо, а не считайте, что значок «подтверждено» в панели управления обеспечивает DMARC. Актуальные рекомендации Gmail для отправителей также требуют аутентификации и выравнивания для соответствующего трафика и рекомендуют отчёты DMARC. Требования получателей и возможности провайдеров могут меняться, поэтому перепроверяйте их официальную документацию при запуске и при разборе инцидентов.

Используйте данные провайдера, не считая их вердиктом DMARC

SendHQ поддерживает отправку с подтверждённого домена, события доставки, стоп-листы и веб-панель управления. Используйте сведения о домене отправки и доставке для расследования потока писем, затем проверяйте DMARC по заголовку Authentication-Results получателя и разделяйте данные SPF, DKIM и выравнивания. Принятие провайдером и события доставки не доказывают попадание во «Входящие».

Фиксируйте результат проверки DMARC так, чтобы его можно было проверить

Надёжный результат должен содержать домен автора, время запроса, резолвер, запрошенное имя _dmarc, выбранный домен политики, точную нормализованную запись, политику и режимы выравнивания, статус DNS, а также то, дал ли разбор допустимый синтаксис, permerror или temperror. Добавьте по одной строке на каждое контрольное письмо: нечувствительный идентификатор письма, отправляющая система, видимый домен From, аутентифицированный домен SPF и результат, проверенные домены и селекторы DKIM, решения по выравниванию, итоговый результат DMARC и получатель. Храните исходные заголовки в хранилище с ограниченным доступом: они могут раскрывать адреса, детали маршрутизации и внутренние идентификаторы. Свяжите каждую находку с ответственным и датой исправления. Повторяйте проверку после истечения TTL DNS, изменения настроек провайдера, ротации ключей, появления новых потоков писем или ужесточения политики. Такие данные делают проверку воспроизводимой и не дают скриншоту или значку инструмента стать вечным доказательством после того, как базовая конфигурация изменилась.

Частые вопросы

Где проверять DMARC-запись?

Начните с TXT-записи по имени _dmarc плюс точный домен из видимого адреса From. Также определите домен политики, выбранный по текущим правилам обнаружения DMARC: если у первого запрошенного имени нет корректной записи, может применяться политика организационного домена или поддомена.

Если найден v=DMARC1, значит ли это, что DMARC проходит?

Нет. Это лишь часть корректной записи политики. Письмо проходит DMARC, когда SPF или DKIM успешно аутентифицируют домен, выровненный с видимым доменом From. Протестируйте реальное письмо и изучите результаты аутентификации на стороне получателя.

Может ли DMARC пройти, если SPF не выровнен?

Да. Успешно проверенная подпись DKIM может дать выровненный аутентифицированный идентификатор, необходимый для DMARC. Возможно и обратное: выровненный SPF может обеспечить прохождение, когда DKIM не проходит, хотя опора только на один механизм снижает устойчивость.

Доказывает ли прохождение DMARC попадание во «Входящие»?

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

Стоит ли приложению сразу переходить на p=reject?

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

Что перепроверить после смены почтового провайдера?

Прежде чем увеличивать продакшен-трафик, заново проверьте политику, обнаруженную для каждого домена From, домены MAIL FROM и DKIM у провайдера, DNS-записи селекторов, результаты SPF и DKIM, мягкое или строгое выравнивание, агрегированные отчёты и каждый класс контрольных писем приложения.

Источники