DMARC fail: проверка выравнивания, заголовков и SPF

DMARC fail означает отсутствие успешной аутентификации с выравниванием относительно видимого From. При p=reject запрашивается отказ, при p=quarantine обработка как подозрительного письма. Конкретное решение принимает получатель. Проверяйте конфигурацию, не исключая других причин проблем доставки. Общая инфраструктура описана в почте для малого бизнеса.

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

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

Что именно означает DMARC fail

Письмо не дало ни одного результата, одновременно успешного и выровненного с видимым From. SPF или DKIM мог пройти для другого домена, не обеспечивая DMARC pass.

Согласно спецификации, SPF или DKIM должен пройти и обеспечить выравнивание с доменом RFC5322 From. Достаточно одного такого механизма. См. RFC 7489.

Шаг 1: сначала проверьте выравнивание

При легитимной отправке сервис нередко аутентифицирует свой домен, а не домен, выровненный с вашим From. Важен не только успех, но и домен проверки.

Пример:

Header From: support@yourdomain.com
Return-Path: bounces.vendor.net
DKIM: d=vendor.net

Здесь возможны spf=pass и dkim=pass без DMARC pass: vendor.net не выровнен с yourdomain.com.

Для маркетинга, CRM, поддержки и запасного SMTP проверьте доменную аутентификацию, собственный Return-Path или домен возвратов, а также DKIM с выравниванием. Брендирование ссылок и домен отслеживания сами по себе не меняют отправителя конверта.

Примеры структуры DNS, точные значения и активацию которой задаёт провайдер:

Type: CNAME
Host: bounces
Value: yourvendor.example.net

Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net

Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.net

TrekMail может показывать общие требования DNS при подключении. Помогут добавление домена и обязательные записи DNS. Для фактического домена MAILFROM нужна одна корректная SPF-запись. Публикация DNS не активирует стороннюю платформу сама: затем проверяйте реальную отправку.

Шаг 2: изучите заголовки получателя

Откройте полные заголовки проблемного письма и найдите Authentication-Results, Return-Path и домены DKIM d=. Используйте результаты доверенного принимающего сервера, а не произвольные заголовки, добавленные отправителем.

Список проверок:

1. Определите видимый домен From.
2. Проверьте результат SPF.
3. Установите фактический домен проверки SPF.
4. Проверьте результат DKIM.
5. Установите домен корректной подписи DKIM.
6. Сопоставьте успешные механизмы с From.

Пример отсутствия выравнивания:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces.sendgrid.net;
  dmarc=fail (p=reject) header.from=yourdomain.com

Обратите внимание:

SPF проверял поддомен sendgrid.net, указанный в конверте. Значение sendgrid.net в header.i само по себе не определяет домен DKIM для DMARC: нужен d= корректной подписи. В показанном результате нет успешного механизма, выровненного с From yourdomain.com.

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

Шаг 3: исследуйте пересылку отдельно

Пересылка может нарушить SPF, поскольку новый сервер не разрешён для исходного домена конверта. Однако сохранённая корректная подпись DKIM с выравниванием позволяет пройти DMARC.

Такое возможно в Google Groups, пересылке Outlook, университетских адресах и адресах выпускников. Один SPF fail не определяет DMARC: успешного DKIM с выравниванием достаточно.

RFC 7960 объясняет сложности: при сохранении конверта SPF может не пройти на новом сервере. Перезапись, например SRS, может обеспечить SPF нового адреса, но не гарантирует выравнивание с исходным From. См. RFC 7960.

Добавление новых разрешений SPF наугад не является универсальным решением. Вместо этого:

1. Подписывайте поддерживаемые пути отправки DKIM и проверяйте их.
2. Рассмотрите мягкое выравнивание, если нет проверенной необходимости строгого режима.
3. У почтовых списков исследуйте изменения подписи и конкретные решения получателей.

Для важных пересылок полезны настройка пересылки почты и пересылка доменной почты в Gmail. TrekMail может предоставлять пересылку и управляемый SMTP в зависимости от тарифа. Подписанные данные должны сохраняться с учётом каноникализации; универсальной гарантии для всех путей нет.

Шаг 4: проверьте SPF на PermError

SPF PermError возможен при превышении лимита в десять механизмов и модификаторов, требующих DNS, включая вложенную проверку, либо при некорректной конфигурации. Это не лимит всех DNS-пакетов. Успешный DKIM с выравниванием всё равно может обеспечить DMARC pass.

Пример записи с несколькими сервисами:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:sendgrid.net include:servers.mcsv.net ~all

По видимой строке нельзя определить весь бюджет. Нужно учитывать вложенные include и вычисление redirect.

Сначала получите DNS-значения:

dig +short txt yourdomain.com
nslookup -type=txt yourdomain.com

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

marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.com

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

Документация TrekMail описывает предотвращение дубликатов SPF и объединение подходящих значений. См. проверку состояния DNS.

Шаг 5: отличите возможное злоупотребление от ошибки

Не каждый DMARC fail требует разрешения. Часть писем действительно отправлена без разрешения, другие исходят из легитимной, но ошибочно настроенной или изменившей письмо пересылки.

Неизвестный IP и неудача обоих механизмов недостаточны для вывода. Сопоставьте системы, журналы и пересылку, не разрешая и не блокируя источник вслепую. p=quarantine и p=reject задают запросы обработки, а не гарантированные действия.

Рабочий порядок:

1. Установите неизвестный источник по перечню систем, журналам и маршрутам пересылки.
2. Для легитимного отправителя подтвердите фактическую платформу и активацию домена.
3. При отсутствии подписи настройте поддерживаемый DKIM и протестируйте отправку.
4. Если успешный выровненный механизм невозможен, спланируйте активированный подходящий домен отправки или контролируемую замену сервиса.

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

Типичные причины по видам отправителей

Тип системы даёт подсказку, но не заменяет проверку проблемного письма.

Работа с ошибками DMARC на множестве доменов

В клиентском портфеле могут одновременно использоваться Google Workspace, cPanel, SendGrid и пересылка Gmail. Без актуальной документации причины ошибок определять сложнее.

Помогает единый порядок настройки DNS, миграции, проверки состояния домена, пересылки и SMTP. При этом каждый реальный путь отправки проверяется отдельно.

Ориентир платных тарифов TrekMail составляет от $3.50 в месяц, также предлагается 14-дневный пробный период. Доступен бесплатный вариант с собственным SMTP. В зависимости от тарифа можно объединять домены, IMAP-ящики, catch-all, пересылку, импорт IMAP и API. Уточняйте текущие функции и лимиты. IMAP копирует почту, но не заменяет смену MX и приложений.

Для клиентских доменов материал о многодоменном почтовом хостинге рассматривает процессы, которые можно сравнить с текущим обслуживанием DNS.

Краткий список проверки DMARC fail

Начните с проблемного письма, определите успешно аутентифицированные домены и сопоставьте их с From. Затем исследуйте конкретный отсутствующий механизм, а не только статус панели.

1. Изучите доверенные Authentication-Results принимающего сервера.
2. Проверьте SPF pass и фактический домен конверта.
3. Проверьте DKIM pass и домен d=.
4. Сопоставьте успешные механизмы с Header From.
5. Без успешного выровненного механизма исправьте соответствующую доменную настройку.
6. При пересылке протестируйте корректность подписи и сохранение подписанных данных.
7. Проверьте вычисление SPF и актуальных провайдеров; разделяйте домены только с активированной настройкой конверта.
8. Исследуйте неизвестный источник с ошибками SPF и DKIM, не считая его подделкой автоматически.

Основа процесса: подтверждённые результаты и контролируемые изменения.

Итог: исправляйте конкретный неработающий механизм

DMARC fail может возникать из-за выравнивания, изменённой пересылки, SPF PermError или несанкционированной отправки. Сам результат не доказывает ни одну из этих причин.

Проверьте нужный уровень и протестируйте точечные изменения. TrekMail может предоставлять общее хранилище, фиксированные многодоменные тарифы, собственный SMTP в Nano, управляемый SMTP и импорт IMAP в зависимости от тарифа. Подробнее: TrekMail и https://trekmail.net/pricing. Учитывайте текущие условия и ограничения.