An SPF record is a list of mechanisms evaluated left to right, and almost every record ends with the universal match: all. Whatever qualifier sits in front of that all is the domain's answer to the only question that matters — what should happen to mail from a server I did not list? Our daily email infrastructure report parses 623,370 SPF records across the Tranco top-1M as of the 2026-07-05 snapshot, and the qualifier landscape it finds ranges from disciplined to genuinely self-destructive.
Four characters, four postures
| Ending | Verdict for unlisted senders | What it communicates |
|---|---|---|
-all | Fail | Hard assertion: this list is complete; reject or junk everything else |
~all | SoftFail | Confident but forwarding-aware: treat unlisted senders with suspicion |
?all | Neutral | No opinion — evaluates as if the record barely exists |
+all | Pass | Explicit approval of every IP on the internet as a legitimate sender |
The first two are legitimate policy choices. The third is a placeholder pretending to be a policy. The fourth is the hall of shame.
What +all actually does
The plus qualifier means pass. Applied to all, it makes the terminal mechanism match every address on the internet with an explicit pass verdict:
; The suicide note, verbatim:
example.com. TXT "v=spf1 +all"
; Its more common disguise — real mechanisms first,
; then a trapdoor at the end:
example.com. TXT "v=spf1 include:_spf.google.com ip4:203.0.113.0/24 +all"The second form is the insidious one. The record looks configured — someone listed real infrastructure — but because every evaluation that reaches the end hits +all, the listed mechanisms are decorative. A spammer's server in any country passes SPF for this domain exactly as convincingly as the company's own mail does.
A domain with no SPF record gets a none result, which many receivers treat with suspicion. A domain with +all hands every forger an authentic SPF pass. And because DMARC accepts an aligned SPF pass, a +all record can carry a forged message all the way through a p=none or weakly-monitored DMARC deployment with green checkmarks. You are not failing to protect the domain — you are actively vouching for the attacker.
How does this happen to real domains? The recurring origin stories: a delivery problem "fixed" by loosening the record until the complaint stopped; a test value that shipped; a copy-paste from a forum answer written by someone equally lost; or a misreading of the syntax — assuming + means "enable" rather than "approve everyone".
?all — the policy that is not one
Neutral deserves its own dishonourable mention because it feels safer than it is. ?all tells receivers to treat unlisted senders exactly as if no SPF assertion had been made. It cannot produce a fail, so it protects nothing; forged mail evaluates as neutral and sails on to the next filter. Its one defensible use is a brief monitoring window during a migration — but records outlive intentions, and a permanent ?all is just +all with better manners. If you find one in your zone, it is a to-do item someone forgot to close.
~all vs -all: the only real debate
Once the permissive endings are off the table, the genuine engineering question is softfail versus fail:
-allis the cleanest assertion, and right for domains with a fully-known sender inventory — especially no-mail domains, wherev=spf1 -allis the canonical two-token record.~allsurvives the real world better for active senders: plain forwarding breaks SPF by design, and a softfail leaves the final verdict to DMARC, which is where the decision belongs anyway. Under DMARC, softfail still fails SPF alignment, so you concede nothing in enforcement.
Either is defensible. What is not defensible is anchoring a strict qualifier to a record that no longer evaluates — a -all behind a lookup-exhausted record fails everything with a PermError first, a failure mode we dissect in our 10-lookup limit analysis. Qualifier strictness and record hygiene are one system.
Auditing your own ending
This is a thirty-second check: dig txt yourdomain.com, find the string starting v=spf1, read the last mechanism. If it ends in +all or ?all, change it before doing anything else in your authentication program — no DMARC policy built on a permissive SPF foundation means what it says. Prevalence data for qualifier usage across the top million lives in section 6 of the live report, updated nightly; and remember when reading any SPF statistics that flattened records evade DNS-based classification — the visible data is the floor, not the whole story.