Настройка SPF: синтаксис, ошибки, контроль

SPF — самый простой из трёх основных стандартов аутентификации, но и самый часто настраиваемый неправильно. Запись состоит из одной строки TXT в DNS. Концепции за ней — целый выходной боль для разбора edge-кейсов. Этот гайд покрывает оба: как стандарт работает на самом деле, как выглядит правильная запись под каждый тип инфраструктуры и какие ошибки тихо отправляют вас в спам.

Что такое SPF на самом деле

SPF (Sender Policy Framework) — это стандарт, который позволяет владельцу домена опубликовать список IP-адресов, авторизованных отправлять письма от этого домена. Когда почтовый сервер получает письмо, он читает адрес отправителя в конверте (Return-Path, он же MAIL FROM), ищет SPF-запись этого домена и проверяет, авторизован ли IP-адрес, с которого пришло письмо.

Это вся механика. SPF не подписывает письма, не защищает тело или заголовки от подделки и смотрит только на адрес в конверте — не на видимый From, который видит получатель. Вот почему над SPF существуют DKIM и DMARC. SPF — это необходимый фундамент, но не полная история аутентификации.

Структура SPF-записи

Каждая SPF-запись хранится в TXT-записи на корневом домене и начинается с тега версии v=spf1. Дальше идёт список разделённых пробелами механизмов, каждый с префиксом квалификатора, завершая с механизмом all.

Механизмы, которые вы будете использовать:

• ip4:203.0.113.10 — авторизовать один IPv4-адрес.
• ip4:203.0.113.0/24 — авторизовать весь блок CIDR.
• ip6:2001:db8::/32 — то же самое, для IPv6.
• a или a:mail.example.com — A-запись домена (или именованного хоста) авторизована.
• mx — все IP из MX-записей авторизованы. Полезно для собственного почтовика, опасно в остальных случаях.
• include:_spf.google.com — импортировать SPF-запись другого домена. Так ESP-сервисы дают вам готовый список.

Квалификаторы стоят перед механизмом и определяют результат совпадения:

• + (по умолчанию) — pass (разрешить).
• - — fail (запретить или отложить).
• ~ — softfail (мягкий отказ, принять, но пометить).
• ? — neutral (нейтрально, никакой политики).

Запись завершается механизмом all с квалификатором. Этот финальный механизм определяет, что случится со всеми письмами, не попавшими под предыдущие правила. -all означает "остальное — fail". ~all означает "остальное подозрительно, но принять с меткой".

Типовые SPF-записи для реальных настроек

Только Google Workspace — самая частая стартовая запись:

v=spf1 include:_spf.google.com ~all

Только Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

Google Workspace плюс Sendgrid (для трансакционной почты):

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Более сложный гибрид — Google Workspace для людей, Amazon SES для трансакционной почты, Mailgun для маркетинга и один статический IP для billing-сервера:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

Порядок механизмов не влияет на корректность, но влияет на читаемость — держите самые частые отправители в начале, так как проверка останавливается на первом совпадении.

Лимит в 10 DNS-лукапов

SPF-проверка ограничена 10 DNS-лукапами максимум. Превышение этого лимита возвращает permerror, который большинство фильтров трактуют как отсутствие SPF вообще. Каждый include:, a, mx, exists: и redirect= считается за один лукап — вложенные include тоже считаются.

Типовый отказ: сначала Google Workspace (1 лукап), добавляете SendGrid (1 лукап), потом Mailchimp (1), потом Klaviyo (1), потом Salesforce Marketing Cloud (5 вложенных лукапов) и новую платформу для help-desk. Вы уже на 11 — и вся запись тихо сломана.

Утилиты вроде dig +short TXT плюс ручной обход каждогоinclude: покажут счёт. Онлайн-чекеры типа MXToolbox, Dmarcian и Easydmarc выводят это прямо.

Flattening vs разделение по поддоменам

Два способа остаться под лимитом, если у вас много вендоров.

Flattening (развёртывание) — это когда вы раскрываете каждый include: в список raw ip4: и ip6: адресов и публикуете их напрямую. Лукапы падают до нуля, но создаёт проблему с обслуживанием: ESP-сервисы регулярно меняют IP-блоки, и устаревшая развёрнутая запись молча блокирует реальных отправителей. Сервисы вроде Dmarcian SPF Surveyor и EasyDMARC предлагают управляемое развёртывание с динамическими обновлениями — это единственный безопасный способ.

Разделение по поддоменам чище: отправляйте трансакционную почту с tx.example.com, маркетинговую с mkt.example.com, поддержку с help.example.com, каждый с собственной SPF-записью, в которой только тот вендор. Минусы: нужно настраивать DKIM и Return-Path для каждого поддомена, видимый From-адрес обычно меняется. Плюсы: каждый поддомен остаётся далеко под лимитом в 10 лукапов, репутация одного вендора не затягивает другого вниз.

Типовые ошибки

Ошибки, которые мы видим каждую неделю при тестировании размещения:

1. Две SPF-записи. RFC 7208 явно говорит: ровно одна v=spf1-запись на домен. Две записи = permerror, который большинство фильтров трактуют как отсутствие SPF. Бывает, когда люди добавляют вторую запись вместо редактирования первой.
2. Забыли большой ESP. Команда подключила Postmark для трансакционной почты, никто не обновил DNS. Вся трансакционная почта softfails.
3. Неправильный финальный механизм. +all — катастрофа, авторизует весь интернет. Никогда не публикуйте это, даже временно.
4. Опечатки в ip4:. ip4:203.0.113 (нет последнего октета) или ipv4: (неправильное имя механизма) падают молча.
5. Забыли выравнивание DMARC. SPF может пройти с Return-Path от bounces.sendgrid.net а видимый From от you@brand.com. DMARC всё ещё упадёт, если не настроить кастомный Return-Path с выравниванием.

Тестирование SPF

Начните с dig прямо в терминале:

dig +short TXT example.com | grep spf1

Если видите вашу запись и ничего больше — хорошо. Если видите две SPF-записи — чините это сейчас. Дальше отправьте тестовое письмо на Gmail-адрес под вашим контролем и посмотрите "Show original" — заголовок Authentication-Results выплевывает spf=pass, spf=softfail или spf=fail напрямую.

Для постоянного мониторинга DMARC-отчёты (rua=) дают вам на каждый источник SPF pass/fail-счёты от реальных получателей, что бьёт любой статический чекер.

Мягкий отказ vs жёсткий

~all (softfail, мягкий отказ) говорит получателям: "неавторизованные IP подозрительны, но письмо всё равно принять". -all (hardfail, жёсткий) говорит: "отклонить сразу". Поведение на приёме различается — Gmail обычно трактует softfail как слабый сигнал и hardfail как повод в спам, не в отказ. Но некоторые строгие корпоративные фильтры отклоняют на -all.

Порядок внедрения: начните с ~all пока проверяете отправителей через DMARC-отчёты. Когда две недели отчётов показывают только известные, ожидаемые источники с pass — переключайтесь на -all. Это поймёт случайные пропуски перед тем как они начнут отклонять реальную почту.

Часто задаваемые вопросы