Строгий DMARC: как разобрать домены в письмах сайта

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

Соберите данные одного конкретного письма

Выберите сообщение, которое действительно прошло через нужную отправку сайта: регистрацию, восстановление доступа или уведомление о заказе. Разные сценарии могут использовать разные почтовые подключения. Проверка обычного письма сотрудника не подтверждает настройки уведомлений приложения. Сохраните технический источник сообщения и отметьте время проверки, чтобы не смешать данные до и после изменения конфигурации.

Нужны домен видимого From, результат SPF и проверенный для него домен, а также результаты подписей DKIM с их доменами d=. Не переносите в строку SPF домен из случайного результата HELO вместо относящегося к этой проверке MAIL FROM. Если не уверены, какие результаты считать достоверными, передайте источник письма администратору принимающей системы: сам отправитель тоже способен добавить похожий по виду заголовок.

По первым двум проверкам из примера нет успешного результата, согласованного с From в строгом режиме. Если появляется дополнительная действительная подпись с d=shop.example, возникает подходящий путь через DKIM. Не нужно делать все результаты одинаковыми только ради красивого списка: важно понять, есть ли хотя бы один успешный и согласованный механизм.

Совпадение доменов и успешность — разные условия

При строгом согласовании нужны одинаковые доменные имена; регистр букв не учитывается. Поддомен bounce.shop.example не равен shop.example. Но одинаковое имя само по себе тоже недостаточно: подпись, которая не прошла проверку, не становится успешной из-за подходящего d=. Эти две проверки инструмент показывает раздельно.

pass

Вы передаёте установленный успешный результат соответствующего механизма.

notpass

По вашим сведениям этот результат не даёт успешной аутентификации. Это обозначение модели, а не буквальная строка заголовка.

unknown

Не хватает данных, либо результат нельзя уверенно отнести к успешному или неуспешному.

Домен «-»

Проверенный домен неизвестен. Это не подстановка домена From.

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

Как пользоваться моделью

1. Укажите только домен From, без имени сотрудника и без символа @.
2. Подтвердите, что оба режима из применимой политики равны s. Инструмент не ищет эту политику в DNS.
3. Добавьте одну строку SPF и строки DKIM в формате ID;SPF или DKIM;pass/notpass/unknown;домен или -.
4. Не пропускайте подпись только потому, что она выглядит неудачной. Если часть DKIM-данных неизвестна, обозначьте это отдельной строкой unknown с доменом «-».
5. Посмотрите вклад каждой строки и общий ответ по переданным условиям.

Ввод ограничен двадцатью строками. Для доменов поддерживается ASCII-запись, в том числе уже подготовленная форма xn-- для международных имён. Полные адреса, заголовки, IP-адреса и домены с завершающей точкой здесь не разбираются. Это ограничение интерфейса для ручной проверки, а не полный синтаксический анализатор почты.

Что означает общий ответ

Если есть хотя бы один подтверждённый успешный результат с точным доменным совпадением, модель показывает наличие подходящего пути. Если такого пути нет, но остаётся неизвестная возможность, ответ остаётся неопределённым. Если все введённые возможности исключены, подходящий путь не найден. Отдельная успешная строка не становится неуспешной из-за неизвестной дополнительной подписи.

Ответ описывает только введённые условия строгого согласования. Это не реальный вердикт сервера получателя и не решение, куда попадёт письмо.

Что передать специалисту по сопровождению

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

На сайте студии уже есть общий материал о SPF, DKIM и DMARC и генератор DNS-записей. Они помогают с общей настройкой, а этот разбор относится к условиям одного строгого случая. Не переносите результат в изменение DNS автоматически. Поддержка сайта должна отдельно проверить отправку приложения, действующую политику и результаты у получателя; причины недоставки могут выходить за пределы DMARC.