SPF-запись (Sender Policy Framework)

SPF (Sender Policy Framework) это способ аутентификации почты через DNS, описанный в RFC 7208. Владелец домена публикует TXT-запись, где перечислены все IP-адреса и хосты, которым разрешено отправлять почту от имени этого домена. Получив входящее письмо, принимающий сервер берёт домен из адреса отправителя в SMTP-конверте (MAIL FROM), запрашивает у DNS SPF-запись и сверяет с ней IP-адрес, с которого пришло соединение. Совпало, результат Pass. Не совпало, будет Fail, SoftFail или Neutral, смотря какой механизм стоит в записи по умолчанию.

SPF-запись: что это и как настроить

SPF-запись — это TXT-запись в DNS вашего домена, которая перечисляет IP-адреса и хосты, имеющие право отправлять email от его имени. Принимающий почтовый сервер извлекает домен из envelope sender (MAIL FROM), запрашивает SPF-запись через DNS и сверяет IP отправителя со списком. Совпадение — Pass. Нет совпадения — Fail или SoftFail в зависимости от механизма по умолчанию.

Синтаксис и механизмы

Запись начинается с v=spf1 и обычно заканчивается механизмом all с квалификатором (или модификатором redirect). Между ними идут механизмы, определяющие разрешённые источники отправки.

Здесь разрешены IP 203.0.113.5 и все адреса, перечисленные в SPF-записи Google Workspace. Всё остальное получает SoftFail. Если заменить ~all на -all, неавторизованные IP получат жёсткий Fail — принимающий сервер с большой вероятностью отклонит письмо.

Механизмы a и mx авторизуют IP из A- и MX-записей домена. Удобно, но каждый из них расходует один DNS-запрос из лимита.

Лимит в 10 DNS-запросов

Стандарт RFC 7208 ограничивает число DNS-запросов при проверке SPF десятью. В этот лимит входят include, a, mx, exists и redirect. Вложенные include тоже считаются. Превышение порога приводит к PermError — письмо может быть отклонено.

Проблема типична для компаний, которые используют несколько сервисов для отправки почты. Каждый сервис требует свой include. Решения: заменять include на статические ip4/ip6 (они не тратят DNS-запросы), удалять неиспользуемые механизмы и применять SPF flattening — автоматическое разворачивание include в IP-адреса.

Распространённые ошибки

• Две SPF-записи на одном домене. Должна быть ровно одна TXT-запись с v=spf1. Две и более — PermError, проверка провалена.
• Механизм +all. Разрешает отправку с любого IP. Фактически аннулирует SPF — защиты нет.
• Отсутствие механизма all. Без -all или ~all в конце запись остаётся валидной, но по RFC 7208 проверка закончится результатом Neutral, как при ?all. Защиты такая запись почти не даёт.
• Забытые сервисы. Подключили новый ESP, не обновили SPF — письма через этот сервис проваливают проверку. При каждой смене инфраструктуры отправки SPF нужно пересматривать.

SPF и DMARC: зачем нужна связка

SPF проверяет домен из envelope sender, а не из заголовка From, который видит получатель. Злоумышленник может пройти SPF со своим доменом в MAIL FROM, а в заголовке From указать ваш. Получатель увидит ваш адрес, хотя письмо отправлено чужим сервером.

DMARC устраняет этот разрыв через alignment: он требует, чтобы домен из MAIL FROM или DKIM-подписи совпадал с доменом в заголовке From. Без DMARC SPF закрывает только часть атак. Именно поэтому SPF, DKIM и DMARC настраивают вместе как единую систему аутентификации.

SPF и валидация email-адресов

При проверке email-адреса валидатор анализирует DNS-инфраструктуру домена. Наличие SPF-записи — косвенный признак того, что домен активно используется для отправки почты и его владелец заботится об аутентификации. Домен без единой TXT-записи, зарегистрированный недавно, вызывает больше подозрений.

Для отправителей рассылок SPF важен в обратном направлении. Если SPF настроен неправильно, письма не пройдут проверку на стороне получателя. Результат — рост bounce rate, попадание в спам, падение репутации домена. Чистая база адресов в сочетании с корректным SPF — два независимых фактора, которые вместе определяют доставляемость.