SPF, DKIM и DMARC: аутентификация отправителя писем

Прямой ответ

Три механизма подтверждают право отправлять письма от имени домена. SPF проверяет адрес отправителя соединения, DKIM — подпись содержимого, DMARC — соответствие двух первых политике домена.

SPF — текстовая запись DNS со списком источников, которым разрешено отправлять почту домена:

v=spf1 ip4:203.0.113.10 include:mailprovider.example ~all

Механизм ~all означает мягкий отказ для неперечисленных источников, -all — жёсткий отказ. Число обращений к DNS в рамках проверки ограничено десятью, поэтому цепочка include должна быть короткой.

DKIM — подпись сообщения закрытым ключом с публичным ключом в DNS:

selector._domainkey.example.com. IN TXT
  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

Получатель проверяет подпись публичным ключом из DNS. Подпись покрывает заголовки и тело, поэтому изменение письма в пути делает подпись недействительной.

DMARC — политика домена и адрес для отчётов:

_dmarc.example.com. IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Параметры adkim и aspf задают режим выравнивания: строгий требует точного совпадения домена, расслабленный допускает поддомен.

Выравнивание доменов и причина отказов

DMARC требует, чтобы домен в адресе отправителя совпадал с доменом, прошедшим проверку SPF либо DKIM. Совпадение называется выравниванием, и его отсутствие — частая причина отказа.

Три ситуации нарушают выравнивание.

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

Пересылка письма. Промежуточный сервер пересылает письмо от своего адреса, поэтому SPF проверяется для него, а DKIM может не пройти из-за изменения заголовков.

Рассылка с нескольких поддоменов при строгом выравнивании. Строгий режим требует точного совпадения, поэтому отправка с поддомена не проходит проверку для основного домена.

Практическое следствие: каждый источник отправки настраивается отдельно — запись SPF включает сервис отправки, а ключ DKIM публикуется для домена отправителя. О настройке отправки — в статье про SMTP в разработке.

Отдельный аспект — порядок внедрения политики. Переход к reject без предварительной отчётности приводит к отклонению легитимных писем, поскольку не все источники отправки оказываются настроены.

Рекомендуемая последовательность:

1. Настроить SPF и DKIM для всех источников отправки.
2. Опубликовать DMARC с политикой none и собирать отчёты.
3. Проанализировать отчёты и найти неучтённые источники.
4. Перейти к quarantine с постепенным увеличением доли применения.
5. Перейти к reject после отсутствия неучтённых источников в отчётах.

О влиянии аутентификации на доставку транзакционных писем — в статье про транзакционные письма.

Практика: настройка аутентификации отправителя

1. Перечислите все источники отправки. Сервисы рассылки, почтовый сервер и сторонние платформы требуют включения в SPF и собственных ключей DKIM.

2. Соблюдайте ограничение числа обращений к DNS. Цепочка include длиннее допустимой приводит к ошибке проверки SPF.

3. Публикуйте отдельный ключ DKIM на сервис отправки. Замена ключа одного сервиса не затрагивает остальные.

4. Начинайте с политики none. Отчёты показывают неучтённые источники до того, как письма начнут отклоняться.

5. Анализируйте отчёты DMARC регулярно. Отчёт содержит перечень источников и результат проверки, поэтому выявляет незапланированную отправку.

6. Переходите к reject постепенно. Доля применения политики увеличивается, чтобы отказ не затронул всю исходящую почту сразу.

7. Разделяйте домены для разных типов писем. Транзакционные и маркетинговые письма отправляются с разных поддоменов; о разделении — в статье про транзакционные письма.

Рекомендации:

1. Не публикуйте политику reject до анализа отчётов. Неучтённый источник отправки приводит к отклонению легитимных писем.
2. Учитывайте пересылку писем. Промежуточная пересылка нарушает SPF, поэтому DKIM становится основным механизмом подтверждения.
3. Проверяйте срок действия ключа DKIM. Ротация ключа требует публикации нового до истечения срока старого.
4. Мониторьте долю писем, не прошедших проверку. Рост доли указывает на появление неучтённого источника отправки.
5. Документируйте источники отправки. Перечень сервисов с соответствующими записями DNS фиксируется, поскольку добавление источника без настройки ломает доставку.

Практический сценарий: письма отклоняются после перехода к политике reject

Контекст: после включения политики reject часть писем перестала доходить до получателей.

1. Диагностика. Отчёты DMARC показали источник отправки, не проходивший проверку SPF и DKIM. Источник — платформа автоматических уведомлений, подключённая отделом поддержки отдельно от основной интеграции.
2. Причина. Переход к политике reject выполнен без предварительного сбора отчётов, поэтому неучтённый источник не был выявлен. Письма с этого источника отклонялись принимающей стороной.
3. Действия. (а) Временно вернули политику quarantine, чтобы письма доставлялись с пометкой; (б) добавили платформу в запись SPF и опубликовали для неё отдельный ключ DKIM; (в) собрали отчёты за две недели и проверили отсутствие других неучтённых источников; (г) вернули политику reject после подтверждения, что все источники проходят проверку; (д) внесли перечень источников отправки в документацию с требованием настройки записей при подключении нового сервиса.
4. Результат. Все источники отправки проходят аутентификацию, а политика reject не приводит к отклонению легитимных писем.

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

FAQ

Что проверяет SPF? Соответствие адреса отправителя соединения списку разрешённых источников в DNS-записи домена.

Зачем нужен DKIM, если есть SPF? DKIM подтверждает неизменность содержимого и работает при пересылке, когда SPF проверяется для промежуточного сервера.

Можно ли сразу установить политику reject? Не рекомендуется. Без предварительных отчётов неучтённые источники отправки приводят к отклонению легитимных писем.

Что означает ошибка проверки SPF из-за числа обращений к DNS? Превышено ограничение числа обращений при раскрытии механизмов include. Цепочку включений требуется сократить.

Источники: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC) — ссылки в шапке.