Сервис рассылок показывает зелёные отметки SPF и DKIM, но в заголовках полученного письма стоит dmarc=fail. Кажется, что результаты противоречат друг другу. Обычно противоречия нет: отдельные проверки подтвердили одни домены, а получатель видит отправителя с другим доменом.

SPF проверяет, разрешено ли отправляющему серверу использовать домен технического отправителя. DKIM проверяет криптографическую подпись письма от домена, указанного в параметре d=. DMARC связывает успешную аутентификацию с доменом видимого поля From. Эта связь называется alignment — согласование доменов.[1][2][3]

Начните с реально полученного письма

Настройки аккаунта ESP, платформы отправки рассылок, показывают намерение отправителя, а исходные заголовки письма — результат конкретной доставки. Попросите исходник проблемного сообщения с контрольного адреса и найдите Authentication-Results, добавленный принимающей системой. Не доверяйте одноимённому заголовку, который мог быть включён отправителем.

Для разбора выпишите видимый From, домен smtp.mailfrom из результата SPF и домен header.d каждой DKIM-подписи. Если смотрите Return-Path, учитывайте фактический путь доставки и пересылку; это не поле, которое маркетолог может исправить обычной заменой имени отправителя.

Проверьте согласование, а не только слово pass

DMARC может пройти через SPF или DKIM: достаточно одного успешного и согласованного пути. Успех обоих механизмов с чужими доменами не решает задачу. При relaxed-согласовании допускаются домены одной организационной области; strict требует точного совпадения.[3]

Условный пример использует вымышленные домены .example. Видимый отправитель — [email protected]. SPF проходит для bounce.vendor.example, DKIM — для d=vendor.example. Обе проверки подтверждают инфраструктуру поставщика, но не домен магазина. DMARC закономерно не проходит.

Что видимЧто проверять дальшеВозможное исправление
SPF pass, но чужой доменMAIL FROM и режим согласованияНастройку собственного bounce-домена
DKIM pass, но чужой d=Домен подписи фактического письмаПодпись доменом магазина
DKIM fail при нужном d=Ключ, selector и изменение письмаПричину нарушения подписи
Поддомены похожи, DMARC failStrict или relaxed, точные именаСогласование с выбранной политикой

Разберите типичный случай после подключения ESP

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

Предлагаемая последовательность: определить проект и отправителя, получить исходник именно из него, проверить применённую подпись, затем сопоставить настройку с DNS. После исправления отправить новое письмо и сравнить заголовки. Скриншот «домен подтверждён» не заменяет этот повторный тест.

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

Почему p=none не исправляет ошибку

Политика DMARC описывает, как владелец домена просит обращаться с сообщениями, не прошедшими проверку. Переход к p=none не превращает fail в pass; он меняет политику обработки. Убирать защиту ради зелёного индикатора в другом отчёте бессмысленно.[3]

Не меняйте политику сразу на reject без инвентаризации легитимных отправителей и проверки маршрутов. В этой статье задача — найти несогласованный домен. Решение об усилении политики требует отдельного плана внедрения с владельцами всех источников почты.

Что меняется при пересылке

При пересылке меняется сервер, передающий письмо дальше, и SPF может перестать проходить. DKIM способен сохраниться, если подписанные части не изменены. Поэтому полезно сравнить прямую доставку с конкретным маршрутом пересылки, не обобщая результат одного теста на всю аудиторию.[1][2]

Отдельно проверьте изменения тела и заголовков промежуточными системами. Добавление подписи, баннера или преобразование содержимого способно повлиять на DKIM. Но обнаруженный fail не доказывает, что именно эта правка стала причиной: нужен исходник до и после участка, где возникло различие.

Как оформить задачу и принять результат

Передайте инженеру Message-ID, время, адрес контрольного получателя, проект отправки и исходные заголовки без лишних персональных данных. В задаче укажите ожидаемый домен From и конкретный путь, через который должна проходить DMARC-проверка.

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

Техническая основа этого разбора — RFC 9989, опубликованный в мае 2026 года и заменивший RFC 7489 и RFC 9091. При сопоставлении с документацией старой платформы учитывайте версию стандарта; проверка реальных заголовков важнее предположения, что все участники доставки обновились одновременно.[3]

Источники

[1] S. Kitterman. Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. RFC 7208, апрель 2014. Проверено 22.09.2026.

[2] D. Crocker, T. Hansen, M. Kucherawy (ред.). DomainKeys Identified Mail (DKIM) Signatures. RFC 6376, сентябрь 2011. Проверено 22.09.2026.

[3] T. Herr, J. Levine (ред.). Domain-Based Message Authentication, Reporting, and Conformance (DMARC). RFC 9989, май 2026. Заменяет RFC 7489 и RFC 9091. Проверено 22.09.2026.