Как включить DMARC reject и не потерять письма

Не включайте DMARC p=reject, пока не проверили все исходящие каналы и не убедились, что хотя бы один результат — SPF или DKIM — проходит с выравниванием домена From. Сам по себе reject не чинит аутентификацию и не гарантирует одинаковое решение у всех получателей. Ниже — порядок проверки источников, субдоменов и отчётов.

Что на самом деле делает DMARC p=reject

DMARC проверяет домен в видимом поле From и сопоставляет его с результатами SPF и DKIM. Для pass достаточно одного успешного результата, если его домен выровнен с From по правилам политики. Значит, фраза «SPF сломался — письмо точно отклонят» неверна: выровненная DKIM-подпись всё ещё может дать DMARC pass. Работает и обратное. Не прошла DKIM-подпись, но SPF прошёл и выровнен — письмо может пройти DMARC. Проверять надо результат и alignment, а не галочки «SPF включён» и «DKIM настроен».

Политика p=reject просит принимающую сторону отклонять сообщения, которые не прошли DMARC. Это не команда, гарантирующая одинаковое действие каждого сервера: получатель учитывает свою локальную политику. Если письмо действительно отклонено на SMTP-этапе, отправляющая система обычно получает отказ, но конкретный код и текст задаёт принимающая сторона. Поэтому один код 550 5.7.1 нельзя объявить универсальным признаком DMARC. Читайте полный ответ сервера и журналы обеих сторон. (Значение в DNS — просьба с протокольным весом, но не пульт управления чужой почтой.)

Я начинаю с инвентаризации: кто формирует письма, какой домен стоит в From, какой домен использует envelope-from для SPF и какой указан в подписи DKIM. В условной компании из этой статьи — ООО «Дельта-Профиль-Мед» — это три разных поля проверки для каждого потока, а не список из двух «включённых технологий». В реальном аудите фиксирую отдельно пользовательскую почту, CRM, бухгалтерские уведомления, сайт, сканеры и внешние рассылки. Если нужна помощь с настройкой, я занимаюсь корпоративной почтой. Важно не число систем, а их фактические заголовки и результаты проверки у получателя.

После этого сравниваю записи с заголовками реально доставленных тестовых писем и агрегированными отчётами. Проверяю, что у каждого нужного потока хотя бы один способ аутентификации проходит и выровнен с доменом From. Если сервис подписывает письма своим доменом, его SPF тоже может пройти, но DMARC alignment при этом не состоится. Исправление обычно находится в настройке пользовательского домена у сервиса, в корректной подписи или в маршруте отправки. «Добавить IP в SPF» подходит не всегда и не заменяет проверку DKIM.

• DMARC pass: SPF или DKIM прошёл и выровнен с From.
• Проверяйте заголовки и результаты, а не только DNS-записи.
• p=reject задаёт предпочтение владельца; обработку выполняет получатель.

Ошибка №1: включить reject до аудита отправителей

Первый сбой — включить строгую политику, не зная всех источников писем. Основной сервер обычно заметен. Тихо забываются сайт с формой обратной связи, CRM, бухгалтерские уведомления, принтер-сканер и внешний сервис рассылок. Они могут отправлять с нужным From, но проходить через другой SMTP-сервер, подписываться чужим DKIM-доменом или вообще не иметь согласованной настройки. Если DMARC не проходит, p=reject может привести к отклонению сообщения теми получателями, которые применяют политику.

В условном примере с ООО «Дельта-Профиль-Мед» я бы начал с журнала потоков за полный рабочий цикл: обычные письма, рассылка, регулярные счета, уведомления и редкие автоматические задачи. Для каждого источника записываю владельца, назначение, From, механизм отправки и контакт того, кто способен поменять конфигурацию. Если сервис не использовался весь период наблюдения, это ещё не доказательство, что он мёртв: квартальный отчёт и годовое уведомление живут по собственному календарю. Я прошу ответственного подтвердить назначение потока, прежде чем отключать его или менять DNS.

Дальше делаю небольшой тест для каждого легитимного источника и проверяю Authentication-Results у контрольного получателя. Цель — увидеть dmarc=pass и понять, за счёт чего он получен: выровненного SPF или DKIM. Если оба результата нужны как резерв, настраиваю оба, но протокол не требует, чтобы оба одновременно прошли для DMARC pass. Это практический запас на случай пересылки или особенностей маршрута, а не условие, которое можно приписать самому DMARC.

Наконец, проверяю SPF отдельно. У SPF есть предел в 10 DNS-запросов механизмов, которые учитываются при оценке записи; превышение может дать permerror. Несколько TXT-записей SPF для одного имени тоже не решение. Убираю лишние включения и сверяю опубликованную запись с актуальными требованиями каждого отправителя. Не копирую в DNS все IP из отчёта на автомате: сначала устанавливаю, кому они принадлежат и зачем отправляют. Чужой поток в отчёте не становится вашим легитимным сервисом от одного факта, что он использовал ваш домен.

• Составьте перечень систем и владельцев исходящей почты.
• Проверьте From, SPF, DKIM и alignment тестовым письмом.
• Сверьте SPF с лимитом DNS-проверок и документацией отправителей.

Ошибка №2: считать, что субдомены настраиваются сами

Политика для основного домена может применяться и к субдоменам. В DMARC для отдельной политики субдоменов предусмотрен тег sp; когда он не задан, используется p родительской записи. Поэтому утверждение «политика корня автоматически не касается субдоменов» неверно. Но и противоположная привычка опасна: наличие общей политики не подтверждает, что отправка с каждого субдомена настроена правильно. У news.example.com и example.com могут быть разные источники, DKIM-подписи и владельцы.

Я составляю перечень всех доменов и субдоменов, которые встречаются в поле From, а потом отдельно сверяю их с DNS и отчётами. Для действующего субдомена решаю, нужна ли ему собственная DMARC-запись и отдельная политика, или достаточно наследования. Тег sp задаёт политику для поддоменов на родительском уровне; запись на самом субдомене может содержать его собственную политику. Настраивать отдельные SPF и DKIM-записи «для галочки» на каждом имени не нужно: записи зависят от реального способа отправки и используемых доменов.

Старые сервисы проверяю по назначению и расписанию. Если отчётный сервер отправляет письмо раз в месяц, его легко пропустить при коротком наблюдении. Если поток подтверждён как ненужный, его отключают через владельца системы и проверку последствий. Если он нужен, восстанавливают согласованную аутентификацию у сервиса. Смена DKIM-ключа не лечит автоматически неправильный домен подписи: сначала проверьте d= в заголовке и alignment с From, затем уже ротацию и DNS-селектор.

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

• Проверьте поле From у писем с каждого используемого субдомена.
• Сверьте родительскую p и специальную sp-политику.
• Не отключайте старый поток без подтверждения его владельца.

Ошибка №3: ждать от rua готового списка приложений

Тег rua указывает, куда отправлять агрегированные отчёты DMARC. Они помогают увидеть домены отправителей, IP-адреса, результаты SPF и DKIM, alignment и применённое решение в объёме, который даёт конкретный получатель. Это полезная телеметрия, а не каталог приложений. В отчёте может быть виден IP или домен сервиса, но отчёт не обязан назвать вашу CRM, сайт или ответственного сотрудника. По этой причине я сопоставляю данные с договорами, настройками сервисов, журналами и владельцами систем.

Перед публикацией rua проверяю, что адрес принимает отчёты, его обслуживают, а доступ к ним ограничен нужными сотрудниками. Для крупного объёма XML обычно нужен разборщик или специализированная система; обычный почтовый ящик быстро превращается в склад архивов. Учитываю, что получатели и периодичность формирования отчётов различаются. Отсутствие отчёта за один день не доказывает отсутствие отправок или проблем. Отдельные failure-отчёты — другой механизм, они не появляются автоматически от одного лишь rua и могут содержать чувствительные данные.

Затем группирую строки по источнику и результату: легитимный поток, неизвестный поток, SPF pass без alignment, DKIM pass без alignment, оба не прошли. Для неизвестного IP сначала выясняю происхождение. Не заношу его в SPF только потому, что в отчёте есть трафик с нашим From: это может быть подделка. Если поток свой, связываюсь с владельцем сервиса и настраиваю домен отправителя так, чтобы SPF или DKIM выравнивался с From. После изменения делаю контрольную отправку и проверяю новый результат.

Отчёты нужны не только на этапе включения политики. Новый сайт, смена почтового провайдера или переезд приложения могут изменить исходящий маршрут через месяцы после аудита. Я сохраняю историю результатов и отмечаю, когда менялись DNS-записи и настройки отправителей. Так можно отличить новую ошибку от старой строки, которая просто попала в другой период. Но не обещаю увидеть в агрегированном XML каждый отдельный отказ и причину, которую знает только принимающий сервер: формат и детализация зависят от отправителя отчёта.

• Добавьте рабочий адрес в rua и организуйте разбор XML.
• Сверяйте IP и домены с владельцами систем.
• Не разрешайте неизвестный поток до подтверждения его происхождения.

Как перейти к p=reject без догадок

Я начинаю с p=none и сбора наблюдений, но не назначаю универсальный срок: он зависит от периодичности писем и полноты отчётов. Владелец домена проверяет, что обычная почта, редкие уведомления и внешние отправители учтены. Затем исправляет найденные источники, повторяет тесты и подтверждает alignment. Только после этого разумно переходить к enforcement. Такой порядок снижает вероятность потерять нужный поток, хотя не может обещать ноль ошибок: сервисы и маршруты меняются.

Промежуточный p=quarantine возможен, если команда понимает его эффект у своих получателей и готова отслеживать доставку. Это не обязательная ступень протокола и не всегда означает одинаковое помещение в папку спама. У каждой стороны своя реализация обработки. Если тесты показывают стабильный DMARC pass для легитимных источников, можно публиковать p=reject, заранее сохранив старые DNS-значения и способ быстро откатить изменение. План отката — обычная инженерная мера, а не признание, что настройка сделана неправильно.

После переключения слежу за агрегированными отчётами, отказами в журналах и обращениями пользователей. При жалобе фиксирую адрес получателя, время, Message-ID и полный SMTP-ответ, затем сверяю заголовки сообщения и DMARC-результат. Не предлагаю всем подряд немедленно возвращать p=none: сначала выясняю, затронут ли один поток, один получатель или сама политика. Если проблема подтверждена, ослабляю политику настолько, насколько нужно для восстановления доставки, и параллельно исправляю конкретный источник.

Требования крупных почтовых провайдеров тоже надо цитировать точно. Для массовых отправителей Gmail и Yahoo требуют аутентификацию и DMARC-запись, но минимально допустимая DMARC-политика включает p=none; blanket-требования непременно включить p=reject у них нет. У массовых отправителей есть и другие требования к доставке, включая выравнивание домена для прямых писем и управление жалобами. Проверьте актуальную документацию провайдера для своего типа потока. Фраза «не поставил reject — Gmail запретит почту» звучит энергично, но фактически вводит администратора в заблуждение.

• Начните с наблюдения и проверьте разные циклы отправки.
• Переходите к enforcement после исправления источников и повторных тестов.
• При отказе сохраняйте полный SMTP-ответ и заголовки письма.

Что исправлять, если письмо уже отклонено

Сначала запросите у отправителя полный текст отказа и журнал доставки, а не только скриншот почтового клиента. Уточните получателя, время, Message-ID, сервер, который вернул ответ, и код SMTP. На стороне получателя точная формулировка может различаться; код 550 5.7.1 сам по себе не доказывает DMARC-ошибку. Затем найдите Authentication-Results в копии письма, если она есть, и проверьте результаты SPF, DKIM и DMARC вместе с доменами. После этого сопоставьте проблемный From с нужной политикой DMARC в DNS.

Если DMARC действительно fail, определите причину: SPF не прошёл, DKIM не прошёл, или успешный результат не выровнен с From. Исправьте источник отправки, домен конверта, подпись или маршрут — в зависимости от результата. Изменение DNS не мгновенно обновляет каждый кэш, поэтому повторный тест делайте после того, как запись стала видна используемым DNS-резолверам. Не меняйте сразу SPF, DKIM и политику в одном пакете: иначе трудно понять, какое изменение вернуло поток.

При пересылке исходный SPF часто теряет смысл, а изменение тела сообщения может повредить DKIM-подпись; это не означает автоматический отказ DMARC, если остаётся другой выровненный механизм. Проверяйте реальный маршрут. Для критичных уведомлений полезны контролируемая повторная отправка и отдельный мониторинг, но не добавление случайных исключений получателя или IP. Если сервер приёма применил свою локальную фильтрацию, один лишь pass DMARC тоже не гарантирует попадания во входящие: протокол проверяет доменную аутентификацию, не качество текста и не репутацию отправителя.

• Соберите полный SMTP-ответ, время и Message-ID.
• Установите, какой из SPF или DKIM дал pass и alignment.
• Меняйте по одной причине и проверяйте результат повторным письмом.

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