The Mechanics of Sender Policy Framework (SPF)
The Sender Policy Framework (SPF), defined by RFC 7208, is an email authentication standard that allows domain owners to publish an authoritative list of IP addresses and mail servers authorized to transmit email on their behalf. When a receiving Mail Transfer Agent (MTA) receives an incoming SMTP connection, it extracts the domain from the envelope return-path (MAIL FROM) and queries the domain's DNS TXT records for a string beginning with v=spf1.
If the sending server's IP address matches one of the authorized mechanisms in the SPF record, the message passes authentication. However, configuring SPF incorrectly—especially by exceeding lookup limits or publishing multiple records—leads to severe deliverability failures.
The Infamous 10-DNS-Lookup Trap (RFC 7208 Section 4.6.4)
To protect recipient mail servers from Denial of Service (DoS) attacks involving infinite recursion and DNS amplification loops, RFC 7208 strictly limits the number of mechanisms that trigger recursive DNS queries to exactly 10 lookups per evaluation.
include:(Queries the target domain's SPF record recursively)aanda:domain(Resolves forward A/AAAA records)mxandmx:domain(Queries MX records, then resolves hosts)ptrandexists:(Deprecated, highly discouraged)redirect=(Transfers evaluation to another domain)
ip4:x.x.x.x/xx(Evaluated locally with zero DNS queries)ip6:x:x::/xx(Evaluated locally with zero DNS queries)all(-all,~all,?all)
Pro Optimization Tip: Replacing nested third-party includes with explicit ip4: CIDR ranges is the standard method used in SPF flattening to stay well under the 10-lookup threshold.
SPF Qualifiers: HardFail vs. SoftFail vs. Neutral
The terminating mechanism of every SPF record defines what action the receiving MTA should take when an IP is not explicitly listed:
| Qualifier | Name | Recipient MTA Behavior | Security Posture |
|---|---|---|---|
| -all | HardFail | Strictly rejects unauthorized messages at SMTP connection time. | Recommended (Strict) |
| ~all | SoftFail | Accepts message but marks headers as suspicious; delivered to Junk. | Standard Transition |
| ?all | Neutral | Treats unauthorized messages as neutral (no penalty applied). | Weak Protection |
| +all | Pass (Critical) | Authorizes ALL servers on Earth to forge email from your domain! | Severe Security Flaw |
Frequently Asked Questions (FAQ)
Publishing two or more TXT records starting with v=spf1 violates RFC 7208 Section 3.2. When receiving servers encounter multiple SPF records, they immediately terminate evaluation and return an SPF PermError (Permanent Error), causing legitimate email to be rejected or flagged as spam. Always consolidate all services into a single record.
RFC 7208 Section 4.6.4 also enforces a Void Lookup Limit of 2. If an SPF record queries two domain names that returnNXDOMAIN (domain does not exist) or return empty answers, evaluation immediately fails with a PermError. Ensure deprecated email vendors are promptly removed from your record.
Standard email forwarding often breaks SPF because the forwarding server transmits the email to the final recipient using its own IP address, which is not authorized in the original sender's SPF record. This is why DKIM (DomainKeys Identified Mail) andARC (Authenticated Received Chain, RFC 8617) are critical companion technologies to preserve authentication across hops.