Выравнивание DMARC: проверка SPF, DKIM и From

Выравнивание DMARC часто остаётся без проверки. SPF, DKIM и DMARC опубликованы, но письма всё равно фильтруются или отклоняются. Помимо общей настройки, описанной в руководстве по деловой почте, нужно проверять реальные системы отправки.

Успеха аутентификации недостаточно. Хотя бы один домен, успешно проверенный SPF или DKIM, должен быть выровнен с видимым From. Без такого механизма DMARC не проходит, но это само по себе не доказывает подделку. Несовпадения встречаются у рассылочных платформ, CRM, поддержки, пересылки и неполных настроек DNS.

Ниже рассмотрены принцип выравнивания, ограничения SPF и проверка важных заголовков. Для пересылки особенно полезна протестированная подпись DKIM с выравниванием, но её сохранение на любом дополнительном сервере не гарантировано.

Что такое выравнивание DMARC

DMARC проверяет соответствие домена, аутентифицированного с помощью SPF или DKIM, видимому From. Достаточно одного успешного механизма с выравниванием. Если такого результата нет, DMARC не проходит.

Это описано в RFC 7489. DMARC использует SPF и DKIM, а не выполняет отдельную независимую аутентификацию. Он проверяет связь успешного результата с доменом, который видит человек в From.

Основные проверки:

Одного SPF pass или DKIM pass недостаточно. Успешный механизм должен обеспечить выравнивание с From. Это не подтверждает безопасность содержания или попадание во входящие.

DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)

Почему SPF проходит без выравнивания DMARC

Если Return-Path принадлежит провайдеру, SPF может пройти для его домена, а не для вашего From. IP отправки разрешён, но выравнивания нет. Успешная подпись DKIM с выравниванием всё ещё может обеспечить DMARC pass.

Платформам нужны обработка возвратов и событий отправки. Поэтому в некоторых конфигурациях они используют собственный домен Return-Path.

Видимый From: billing@example.com
Return-Path: bounces+123@sendgrid.net

SPF может пройти, потому что SendGrid разрешил IP для sendgrid.net. Этот механизм не выровнен: sendgrid.net не соответствует example.com. Другой успешный механизм с выравниванием всё равно может позволить пройти DMARC.

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

bounces.example.com.   CNAME   u1234.wl.sendgrid.net.

После настройки и активации у провайдера отправитель может использовать bounces.example.com в конверте. В мягком режиме он выровнен с example.com. Сам CNAME не включает такой режим отправки автоматически; проверяйте реальные письма.

Пересылка создаёт другое ограничение: получатель видит IP сервера пересылки, а не исходного сервера. SPF может не пройти. Это объясняют пересылка доменной почты в Gmail и пересылка через почтовые псевдонимы. SPF полезен, но не покрывает любые пути пересылки.

Почему подпись DKIM с выравниванием особенно полезна

DKIM может пройти после пересылки, если подпись остаётся корректной и выровненной, а подписанные данные сохраняются с учётом каноникализации. Изменение содержания или подписанных заголовков может нарушить проверку.

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

Видимый From: newsletter@example.com
Подпись DKIM: d=mailchimpapp.net

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

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

s1._domainkey.example.com.   CNAME   s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u1234.vendor.net.

После корректной активации платформа может подписывать с d=example.com или мягко выровненным поддоменом, например d=mail.example.com. Корректная подпись с выравниванием может обеспечить DMARC pass даже после неудачи SPF при пересылке.

Описанные требования Google к массовым отправителям включают выравнивание From через успешный SPF или DKIM. Проверяйте применимые условия. Ошибки могут приводить к ограничениям, но это не единственная причина фильтрации или отказов.

Мягкое и строгое выравнивание DMARC

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

За режим отвечают aspf для SPF и adkim для DKIM.

Пример:

_dmarc.example.com. TXT "v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

Строгий режим следует вводить осознанно. Если приложение подписывает с mail.example.com, а From использует example.com, этот DKIM не удовлетворяет строгому выравниванию.

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

Как исследовать ошибки выравнивания

Проверяйте результаты своего доверенного принимающего сервера: Authentication-Results, DKIM d=, SPF smtp.mailfrom и dmarc с header.from. Заголовки, добавленные отправителем могут быть подделаны и не служат надёжным доказательством.

Собственные результаты получателя вместе с реальной подписью показывают используемые домены. Одной панели отправителя недостаточно для подтверждения конкретного пути письма.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
  dmarc=fail header.from=example.com

Порядок проверки:

1. Проверьте header.from: это видимый домен для DMARC.
2. Проверьте домен SPF в smtp.mailfrom. Чужой организационный домен не обеспечивает выравнивание SPF.
3. Не считайте header.i определяющим доменом подписи. Для DMARC важен d= корректно проверенной подписи DKIM.
4. Если ни SPF, ни DKIM не обеспечивают успех и выравнивание с From, DMARC не проходит, даже когда оба успешны для других доменов.

Дополнительно проверьте DNS:

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.com

Ошибки SPF только после пересылки могут объясняться новым сервером. Корректная подпись DKIM с выравниванием всё ещё может обеспечить DMARC pass, но проверяйте конкретную подпись. ARC может поддержать локальное исключение получателя, а не превратить неудачу DMARC в успех.

При создании домена помогут настройка домена TrekMail и создание почты со своим доменом. Нужны корректный SPF фактического домена конверта, активный DKIM и правильный DMARC. Меняйте MX только в рамках проверенного переключения.

Повторяющиеся причины ошибок выравнивания

Сторонние отправители, пересылка, отличающиеся поддомены и старые либо повторные DNS-записи часто требуют внимания. Их влияние следует проверять на реальной отправке.

Типичные случаи:

1. Маркетинговая платформа использует собственный домен возвратов. SPF успешен без выравнивания, но DKIM ещё может обеспечить DMARC pass.
2. Провайдер подписывает своим доменом. DKIM не выровнен, но успешного SPF с выравниванием может быть достаточно.
3. Пересылка может нарушить SPF. Корректный DKIM с выравниванием часто становится оставшимся успешным механизмом.
4. Непреднамеренный строгий режим исключает отличающиеся поддомены.
5. Старые записи не соответствуют текущей настройке. Они не меняют автоматически фактическую систему подписи; отправку и маршрутизацию нужно проверять отдельно.

Если 4.7.32 прямо указывает на отсутствие выравнивания From с SPF или DKIM, исследуйте именно эту связь. Условия описаны в ответах Google для отправителей. У других проблем доставки могут быть дополнительные причины.

Проверка выравнивания в TrekMail

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

Возможные процессы:

Разрозненная и общая работа

Управляемый SMTP доступен в соответствующих платных тарифах. Собственный SMTP может подключать SES, SendGrid, Mailgun и другие службы в зависимости от тарифа. Проверяйте текущие условия и реальную отправку: зелёный DNS-статус не подтверждает выравнивание всех источников.

Полезная документация TrekMail:

«Мои письма попадают в спам» рассматривает и пересылку. Настройки IMAP и SMTP описывают клиентские подключения. Вход клиента и доменная аутентификация являются разными проверками.

Ценовой ориентир Starter составляет $3.50 в месяц. Для предлагаемого 14-дневного пробного периода платных тарифов требуется кредитная карта. У Nano есть бесплатный вариант с собственным SMTP, до 10 доменов и 5 GB общего хранилища. Текущие функции, лимиты и условия приведены в тарифах TrekMail. Миграция IMAP копирует почту, но не заменяет полноценную смену MX или приложений.

Итоговая проверка выравнивания DMARC

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

1. Учтите всех отправителей: хостинг, CRM, счета, поддержку, магазин, формы и маркетинг.
2. Подтвердите видимый домен From каждого источника.
3. Проверьте SPF pass и выравнивание фактического домена Return-Path.
4. Настройте DKIM с выравниванием и протестируйте реальные подписи.
5. Используйте aspf=r и adkim=r, если не требуется обоснованная проверенная альтернатива.
6. Отправьте тесты и изучите доверенные Authentication-Results получателя.
7. Для непроверенной отправки сначала используйте p=none. Локальные фильтры сохраняются, отчёты не гарантированы.
8. Рассматривайте ограничения после сверки систем, анализа ошибок, журналов и тестов редких важных операций.

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