SPF Record (Sender Policy Framework)

SPF (Sender Policy Framework) is a DNS-based email authentication method defined in RFC 7208. The domain owner publishes a TXT record that lists every IP address and host allowed to send mail on that domain's behalf. When a receiving mail server gets an inbound message, it extracts the domain from the SMTP envelope sender (MAIL FROM), queries DNS for the SPF record, and compares the connecting IP against the authorized list. A match produces a Pass result; a mismatch yields Fail, SoftFail, or Neutral depending on the record's default mechanism.

How SPF evaluation works

The evaluation follows a strict left-to-right order. The record always starts with v=spf1 and ends with a catch-all qualifier, typically ~all or -all. Between them, mechanisms declare authorized sources:

• ip4:203.0.113.0/24 — allow a specific IPv4 address or subnet.
• ip6:2001:db8::/32 — same for IPv6.
• include:_spf.google.com — delegate to another domain's SPF record. Used when mail goes through Google Workspace, Mailchimp, SendGrid, or any third-party ESP.
• a and mx — authorize the IPs resolved from the domain's A or MX records. Convenient but each costs a DNS lookup.

The receiver walks through each mechanism until one matches the sender IP. If none match, the catch-all applies. -all means hard Fail: reject everything not explicitly listed. ~all means SoftFail: mark as suspicious but leave the final decision to the receiver.

The 10-lookup limit

RFC 7208 caps the number of DNS-querying mechanisms at 10 per evaluation. Each include, a, mx, exists, and redirect counts toward this cap. Nested includes add up as well. Exceeding the limit triggers a PermError, and the message may be rejected outright.

Companies that route mail through several services — CRM, transactional ESP, helpdesk, marketing platform — frequently hit this ceiling. Two common fixes: replace include directives with static ip4 entries (which cost zero lookups), or use an SPF-flattening service that resolves includes into IP lists and keeps the record within limits.

SPF alone is not enough

SPF checks the envelope sender, not the visible From header. An attacker can pass SPF using their own domain in MAIL FROM while placing your domain in the From header the recipient sees. This gap is exactly what DMARC closes: it requires alignment between the From header and the domain verified by SPF or DKIM. Without DMARC, SPF provides only partial protection against spoofing.

In practice, all three records — SPF, DKIM, and DMARC — function as a single authentication stack. SPF declares who may send. DKIM proves the message was not altered in transit. DMARC ties them to the visible sender address and defines a policy for failures.

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

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

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

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

Здесь разрешены 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 в конце запись формально некорректна. Провайдеры могут интерпретировать это как ?all (Neutral), что ослабляет защиту.
• Забытые сервисы. Подключили новый 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 — два независимых фактора, которые вместе определяют доставляемость.