Письмо может получить spf=pass и одновременно dmarc=fail: SPF подтвердил право сервера отправлять почту для одного домена, а в видимом поле From указан другой. Для DMARC нужен успешный SPF или DKIM с согласованным доменом — это называется alignment.
Начните с заголовков конкретного письма у получателя: сравните домен From с smtp.mailfrom и доменом успешной DKIM-подписи. По RFC 9989 достаточно одной согласованной успешной проверки; добавлять новые include в SPF наугад не нужно.
1. Возьмите результат у получателя
Отправьте тестовое письмо из проблемного канала — формы сайта, CRM или сервиса рассылок — в свой контрольный ящик. Откройте исходник сообщения и найдите Authentication-Results, добавленный почтовой системой получателя: строка от промежуточного сервера может описывать другой этап доставки.
Выпишите:
- домен адреса в
From, а не имя отправителя; spfиsmtp.mailfrom;dkimиheader.d;dmarcиheader.from;- время отправки и канал, из которого ушло письмо.
Если сообщение отклонено до доставки, сохраните ответ SMTP и попросите почтового администратора проверить журнал приёма. Онлайн-проверка DNS не заменяет результат обработки самого письма.
2. Сравните три домена
SPF проверяет отправителя конверта
У письма есть видимый From и технический отправитель SMTP-конверта — MAIL FROM. Для обычного доставленного письма последний отражается в Return-Path; в результатах проверки ищите именно smtp.mailfrom.
SPF проверяет разрешение для IP отправляющего сервера использовать этот домен. Поэтому исправная SPF-запись домена сайта может вообще не участвовать в проверке, если сервис отправляет с собственным MAIL FROM. Это различие описано в RFC 7208.
DKIM проверяет домен подписи
В DKIM-Signature параметр d= задаёт домен подписи, а s= — selector, по которому ищут ключ. Наличие подписи ещё не означает успех: нужен результат dkim=pass у получателя. Эти поля определены в RFC 6376.
Если подписей несколько, сопоставляйте результат каждой с её доменом: успешная подпись чужого сервиса сама по себе не подтверждает домен From.
3. Проверьте режим согласования
В применяемой DMARC-записи параметр aspf задаёт режим для SPF, adkim — для DKIM. Значение s требует точного совпадения доменов; r допускает общий организационный домен. Если параметры не заданы, используется relaxed-режим.
Например, example.com и bounce.example.com могут согласовываться в relaxed-режиме, но не в strict. example.com и example.net не согласуются; похожее написание ничего не меняет. Организационный домен не всегда равен двум последним частям имени: для сложных зон проверяйте вывод валидатора. Правила сравнения приведены в RFC 9989.
Для From вида notice@example.com начните проверку с TXT-записи _dmarc.example.com. При отправке с поддомена учитывайте поиск применяемой политики выше по иерархии: отсутствие TXT на первом имени не всегда означает отсутствие DMARC.
4. Найдите конкретное расхождение
Условный пример: письмо с From домена example.com получает SPF pass для bounce.example.net и DKIM pass для example.net. Обе проверки успешны, но ни один домен не согласован с From — DMARC fail ожидаем.
Если сервис начнёт корректно подписывать письмо с d=example.com и получатель подтвердит DKIM pass, эта ветка сможет обеспечить DMARC pass даже при несогласованном SPF. Аналогичный разбор заголовков есть в документации Microsoft.
5. Исправьте настройки канала отправки
Выберите изменение по найденной причине:
- MAIL FROM принадлежит сервису. Проверьте поддержку собственного return-path или bounce-домена. Настраивайте его в сервисе и DNS по инструкции провайдера; ручная подмена заголовка Return-Path не меняет SMTP-конверт.
- DKIM подписан доменом сервиса. Включите подпись своим доменом, добавьте выданные DNS-записи и дождитесь успешной проверки у получателя. Один опубликованный ключ без настройки отправителя не решает задачу.
- Разошлись только поддомены при strict. Настройте точное совпадение либо осознанно пересмотрите режим после проверки всех отправителей. Смена
aspfне исправит несовпадение DKIM. - Форма ставит email посетителя в From. Отправляйте от разрешённого адреса своего домена, а адрес посетителя помещайте в Reply-To.
Эти действия меняют разные части цепочки. Сначала сохраните текущую конфигурацию, затем меняйте один канал и проверяйте новое письмо, чтобы видеть результат.
Если ошибка возникает только при пересылке
Сравните прямую доставку и доставку через посредника. Пересылка меняет отправляющий IP, а переписывание конверта может дать SPF pass уже для домена посредника; согласования с исходным From при этом нет.
Сохранившаяся согласованная DKIM-подпись может помочь, но изменение подписанного содержимого способно её нарушить. Такие ограничения разобраны в RFC 7960; по одному письму нельзя объявлять неверной всю SPF-конфигурацию.
Как подтвердить исправление
Повторите отправку из каждого используемого канала. Для каждого нового письма проверьте DMARC pass и определите, какая успешная ветка обеспечила согласование. Старые письма не изменятся после правки DNS.
Переключение политики на p=none меняет запрашиваемую обработку неуспешных сообщений, но не устраняет расхождение доменов. Даже DMARC pass не гарантирует попадания во входящие: фильтрация и репутация остаются отдельными факторами.
Если письмо вообще не отправлено или результата DMARC нет, начните с общего руководства «Письма с сайта не приходят».
При нескольких сервисах отправки и непонятных заголовках можно отправить заявку на профессиональную поддержку через Web-Puls. Укажите домены, канал, время теста и обезличенные результаты SPF/DKIM/DMARC без паролей и тела письма; специалист оценит задачу и предложит формат работ.