SPF ~all vs -all: softfail, fail, and which one to actually use
Every SPF record ends with an all — and the single character in front of it looks like a security dial: ~ for lenient, - for strict. The catch is that receivers stopped treating it as a dial years ago. Here's what the qualifiers really do, and why the "strict" one can hurt you.
The four endings, on paper
The all mechanism matches any server your record didn't already list, and its qualifier tells receivers what you'd like done with that mail:
| Ending | Name | What it requests |
|---|---|---|
-all | fail ("hardfail") | Reject mail from unlisted servers. |
~all | softfail | Accept it, but treat it with suspicion. |
?all | neutral | No opinion — says nothing at all. |
+all | pass | Every server on the internet may send as you. Never publish this. |
Two of these have easy verdicts. +all authorizes the entire internet and is treated by many filters as a spam signal in itself. ?all is legal but pointless — it makes your whole record decorative. The real question is ~all vs -all.
What receivers actually do with them
On paper, -all means "reject". In practice, Gmail and Microsoft mostly don't reject on an SPF fail alone. They record the result — pass, softfail, fail — and feed it into two things: spam scoring, and the DMARC evaluation of the message. Big receivers learned long ago that a hard SPF reject destroys legitimate forwarded mail, so they defer the decision to DMARC, which was designed to make it properly.
But "mostly" is doing work in that sentence. Plenty of smaller mail servers — corporate gateways, some hosting providers, default Postfix policy setups — do reject at SMTP time when a record says -all. You don't control which of your recipients run one of those.
The forwarding problem, and why it points at -all
When someone auto-forwards their mail (a university alumni address, a role account, an old provider forwarding to Gmail), the forwarding server re-sends your message from its IP — which is not in your SPF record. SPF breaks on forwarding by design; nothing you list will fix it. The question is what happens next:
- With
~all: the forwarded copy softfails SPF, your DKIM signature (which survives forwarding) still passes, DMARC passes, mail delivered. - With
-all: a strict receiver may reject the message during the SMTP conversation — before DKIM or DMARC are ever evaluated. Your legitimately-sent, correctly-signed mail bounces, and the bounce goes to the forwarder, not you, so you may never find out.
That is the asymmetry: -all buys you essentially nothing against spoofers that ~all + DMARC doesn't already provide, and it costs you an edge case that silently eats real mail.
"But isn't -all more secure?"
It was — in 2010, when SPF was the only game in town. DMARC changed the calculus completely, because DMARC doesn't care how SPF failed. It asks one question: did SPF produce a pass for a domain aligned with the visible From address? Softfail and fail are both simply "no". The enforcement — quarantine it, reject it — comes from your DMARC policy, where it applies to the spoofer's mail specifically rather than to anything with an unlucky delivery path.
So the protection ranking is not what the qualifiers suggest:
~allwithp=reject: spoofed mail fails DMARC and is rejected. Forwarded real mail survives on DKIM. This is the strong setup.-allwith no DMARC: spoofed mail is rejected by some receivers, scored by others — and your own forwarded mail takes the same damage. Weaker, despite looking stricter.
What to publish
For a domain that sends mail: ~all, and put your enforcement in DMARC.
v=spf1 include:_spf.google.com include:mailgun.org ~all
If you already run -all and mail flows fine, there's no urgency to change it — the failure mode is narrow. But if you're deciding today, or you're diagnosing missing mail that only some recipients report, ~all is the answer. (While you're editing the record, check you're under the 10-lookup limit — that mistake breaks SPF far more often than the qualifier ever will.)
For a domain that sends no mail — a parked domain, a brochure site: this is the one place -all is unambiguously right, because there is no legitimate mail to lose:
yourdomain.com TXT "v=spf1 -all"
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject"
You can check what your domain publishes right now with our free SPF checker, and the DMARC side with the DMARC checker.
Not sure if forwarding is eating your mail? Your DMARC aggregate reports show every delivery path — including forwarders where SPF broke and DKIM saved the message, or didn't. PlainDMARC turns those reports into a plain-English weekly verdict per domain, so you can see the edge cases before you tighten anything.
Get a plain-English weekly DMARC verdict — create a free account