SPFSender Policy Framework

SPF answers one question: is this server allowed to send mail for this domain? When a message arrives, the receiver reads the domain from the MAIL FROM command (the envelope sender, also called the Return-Path), looks up that domain’s SPF record in DNS, and checks whether the connecting IP address is on the authorised list. A match means SPF passes; if the record explicitly disavows that IP, SPF fails.

An important catch is that SPF checks the envelope domain, not the From: address your recipient actually sees. Those two can differ, which is exactly why SPF on its own cannot stop someone spoofing your visible From line, and why DMARC adds an alignment test on top. SPF also has a structural weakness: when a message is forwarded, the forwarding server becomes the new sending IP, which is almost never on the original domain’s SPF list, so the check fails. DKIM, which survives forwarding, exists to cover that gap.

An SPF record is a single TXT record made of mechanisms (sources of mail) and an all term that catches everything else:

The common mechanisms are:

• ip4 / ip6: authorise a specific address or CIDR range. These cost no DNS lookup.
• include: pull in another domain’s SPF record (how you authorise an ESP such as Google or SendGrid).
• a / mx: authorise the IPs behind the domain’s A or MX records.
• all: the catch-all at the end, applied to anything not already matched.

Each mechanism carries a qualifier that sets the result when it matches: + pass (the default), - fail, ~ softfail (accept but mark suspicious), and ? neutral. Almost every record ends in ~all or -all. The ptr mechanism still exists but the RFC says not to use it: it is slow and unreliable.

To protect DNS from abuse, RFC 7208 caps an SPF evaluation at 10 DNS-querying mechanisms. Only the terms that trigger a lookup count: include, a, mx, ptr, exists, and the redirect modifier. The ip4, ip6, and all terms are free. Crucially, an include counts every lookup inside the record it pulls in, so a couple of nested ESP includes can blow the budget fast.

Exceed 10 and the receiver returns PermError, which most treat as an authentication failure. The fix is “flattening”: replacing chained include statements with the underlying ip4/ip6 ranges so the lookup count drops, then keeping it maintained as those ranges change.

Since February 2024, Google and Yahoo require bulk senders (5,000 or more messages a day) to authenticate, and a valid SPF record is one of the accepted checks; Microsoft applied the same baseline to large Outlook and Hotmail senders in 2025. A missing, broken, or PermError SPF record is one of the most common reasons otherwise-legitimate mail lands in spam or is rejected outright.

For DMARC to pass, a passing SPF result must also align: the Return-Path domain it checked must share an organizational domain with your visible From:. Because many ESPs put their own domain in the Return-Path, SPF can pass yet fail DMARC alignment, which is why senders configure a custom Return-Path or lean on aligned DKIM. You can confirm what you have published with the SPF checker.