What SPF actually authorizes
SPF (Sender Policy Framework), standardized in RFC 7208, publishes a DNS TXT record at the domain (or HELO name) that describes which IPv4/IPv6 addresses and delegated includes are permitted to appear in the SMTP envelope sender (MAIL FROM) for that domain. Receivers perform a DNS tree walk: mechanisms such as ip4:, ip6:, a, mx, and include: are evaluated left to right until a mechanism matches the connecting client IP, producing a pass, or the list ends.
SPF does not cryptographically sign message bodies and does not directly validate the visible From: header users see—that alignment is handled by DMARC when combined with DKIM or SPF domain alignment. Treating SPF as a complete anti-phishing solution is a common architectural mistake.
Mechanisms, qualifiers, and the all terminator
A typical record: v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all. The v=spf1 sentinel identifies SPF. Each mechanism may carry a qualifier: + pass (default), - fail, ~ softfail, ? neutral. The all mechanism matches any address and should appear last; most receivers stop evaluation at the first match, so order matters for performance and security.
- include: dereferences another domain’s SPF record and inherits its evaluation (counts toward the DNS lookup limit of 10 total queries per RFC 7208).
- redirect= (modifier) changes the domain whose record is evaluated—use sparingly; misconfiguration loops break mail.
- exists:%{i}.example.com and macros exist for advanced policy but increase complexity and lookup cost.
DNS limits and operational pitfalls
Exceeding 10 DNS lookups during SPF evaluation causes a permerror, which many large receivers treat like a fail. Chaining many include: ESPs quickly hits the cap—flatten critical includes to ip4/ip6 blocks via automation if your architecture requires it, and monitor ESP IP changes.
Multiple SPF TXT records for the same name also yield permerror: there must be exactly one SPF TXT per applicable DNS owner name. Merge vendors into a single record.
SPF + mailing lists: forwarding breaks SPF alignment because the envelope sender often becomes the list’s domain while the body still shows the original author—this is why DKIM + DMARC alignment matters for indirect mail paths.
Sample policies
Strict reject for anything not explicitly listed: v=spf1 ip4:198.51.100.10 -all. Soft signal while monitoring: v=spf1 include:_spf.example.net ~all. Prefer tightening to -all once logs show no legitimate stray sources.
Verification workflow
Use dig TXT example.com or your DNS provider UI to confirm a single TXT beginning with v=spf1. Then send a test message through each outbound path (Google Workspace, marketing ESP, ticket tool) and inspect Authentication-Results headers on a mailbox you control. Pair SPF with DKIM and DMARC; follow the combined SPF/DKIM/DMARC setup guide for rollout order.
Confirm the public egress IPs your MTAs use before encoding them in SPF.