SPF: разрешённая инфраструктура отправки
Sender Policy Framework публикует разрешённые источники отправки для домена технического отправителя сообщения. Это не проверка личности человека. До изменения записи учтите почтового провайдера, сайт, CRM и рассылки. Ошибки SPF могут влиять на обработку, но результат оценивают вместе с DKIM, DMARC и правилами получателя.
DKIM: проверка подписи домена
DomainKeys Identified Mail добавляет криптографическую подпись, которую получатель проверяет по открытому ключу домена. Она относится к подписанным частям сообщения и не доказывает правдивость текста. Настройте селектор у отправляющего сервиса и изучите реальное письмо. Наличие ключа в DNS не подтверждает, что сервис действительно подписывает сообщения правильно.
DMARC: связь с видимым полем From
DMARC проходит, когда хотя бы один успешный результат SPF или DKIM согласован с доменом в видимом поле From. Политика задаёт пожелание обработки не прошедших проверку сообщений; получатель применяет собственные правила. Google требует SPF или DKIM для всех отправителей на личные адреса Gmail, а для массовых отправителей выше установленного порога также оба механизма и DMARC.
SPF, DKIM и DMARC: три разные проверки
SPF позволяет проверить, разрешён ли сервер для домена SMTP-отправителя. DKIM связывает подпись сообщения с подписывающим доменом. DMARC проверяет согласование (alignment) с доменом в видимом поле From: достаточно успешной согласованной проверки SPF или DKIM. Простое наличие трёх TXT-записей не подтверждает это для каждого сообщения.
Например, сервис рассылки может проходить SPF для своего технического домена, который не согласован с вашим From. Если при этом есть корректная DKIM-подпись вашего согласованного домена, DMARC может пройти. Это иллюстрация логики, а не результат проверки конкретной рассылки.
Как читать результаты Authentication-Results
Проверяйте заголовки на стороне доверенного принимающего сервиса. Пересланные фрагменты и самостоятельно добавленные заголовки могут вводить в заблуждение.
| Результат | Что он показывает | Чего не доказывает |
|---|---|---|
| spf=pass | Разрешённость отправки для проверенного домена | Совпадение с видимым From |
| dkim=pass | Проверку конкретной подписи | Автоматическое согласование её домена с From |
| dmarc=pass | Успешную согласованную проверку | Полезность содержимого или попадание во входящие |
| Отказ доставки | Решение получателя с указанной причиной | Что проблема обязательно в DNS |
Порядок проверки отправителей и политики
Составьте список потоков: сотрудники, сайт, CRM, счета и рассылки. Получите тестовое сообщение каждого потока и проверьте домены, результаты и уведомления об отказе. Не создавайте несколько самостоятельных SPF-записей для одного имени и не ужесточайте политику, пока не разобраны легитимные отправители.
RFC 9989 опубликован в мае 2026 года и заменил RFC 7489 и RFC 9091. При работе со старыми инструкциями нужно сверять их с актуальным стандартом и реализацией провайдера. Требования Gmail относятся к указанному Google контексту приёма; это не единое правило для всех получателей. Репутация, жалобы и содержание остаются самостоятельными факторами доставки.
Два учебных примера согласования доменов
Пример 1: From: [email protected]; DKIM d=example.com; доверенный получатель сообщает dkim=pass и dmarc=pass. Пример 2: From: [email protected]; DKIM d=mailer.example.net; подпись проходит, но этот домен не согласован с example.com. DMARC всё ещё может пройти по другому успешному согласованному механизму SPF. Это упрощённые искусственные примеры, а не готовые заголовки или доказательство состояния сообщения. Для решения нужны результаты получателя и точные домены конкретного потока.
