RFC 7208 — SPF

Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

Status
Proposed Standard
Published
2014
Obsoletes
RFC 4408

RFC 7208 defines SPF, the record listing which servers may send mail using your domain. It obsoletes RFC 4408, the original 2006 experimental version.

SPF is one of the two mechanisms DMARC can be satisfied by — the other being DKIM.

What the document actually governs

  • The record syntax — every mechanism (all, ip4, ip6, a, mx, ptr, exists, include), the four qualifiers, and the redirect= and exp= modifiers. Our SPF record syntax guide is a field reference for all of it.
  • The ten-lookup limit (§4.6.4), the single most common cause of an SPF record failing in a way nobody notices.
  • The deprecation of ptr (§5.5), which the RFC describes as slow and unreliable, and which some receivers skip entirely.
  • Which identity is checked — the envelope sender (MAIL FROM), not the From: header your recipient sees. That gap is exactly what DMARC’s alignment requirement closes.

The part people get wrong

SPF authenticates the envelope, so a message can pass SPF perfectly while displaying a completely different From: domain. On its own, SPF proves almost nothing about what the recipient sees. It only becomes meaningful under DMARC, which additionally requires the SPF domain to align with the visible From:.

Chasing an SPF pass without checking alignment is the most common wasted afternoon in a DMARC rollout.

The ten-lookup limit, and why it is the usual culprit

Six terms cost a DNS lookup — include, a, mx, ptr, exists and redirect — and the total across a record must stay at or below ten. Eleven is a permerror, which under DMARC is a fail.

The count is recursive, and that is what catches people. include: fetches another record whose own include:s count too, so three includes can easily be nine lookups. A record that looks small can be over the limit without anything in it looking wrong.

mx and ptr carry a second, separate cap of ten address lookups each, which is how a record with a single mx term still fails.

What the RFC does not do

SPF has no opinion about the message. It does not sign anything, does not survive forwarding, and says nothing about content. A forwarded message fails SPF essentially by definition, because the forwarding server is not on your list — which is why DKIM is the sturdier half of DMARC and why ARC exists at all.

Read it: rfc-editor.org/rfc/rfc7208