SPF -all vs ~all: Hard Fail vs Soft Fail, and Which to Use
By VigilDog Team · August 23, 2026 · 7 min read
The last mechanism in your SPF record is a single character that decides how receivers treat mail that fails the check. Get it wrong and you either leak spoofable domains or silently drop legitimate mail. The choice between spf -all vs ~all is smaller than most guides make it sound once you understand what actually enforces the outcome.
What the 'all' qualifier actually does
An SPF record lists the servers allowed to send mail for your domain, then ends with an `all` mechanism that catches everything not matched by the earlier rules. That final mechanism carries a qualifier: `+` (pass), `-` (fail), `~` (softfail), or `?` (neutral). A typical record looks like `v=spf1 include:_spf.google.com ~all`.
The qualifier does not block anything by itself. SPF only produces a result — pass, fail, softfail, neutral — and hands it to the receiving mail server. What the receiver does with that result is entirely up to the receiver's own policy. This is the single most misunderstood thing about SPF, and it's why the -all versus ~all debate is less dramatic than it looks.
So the real question is not 'which one blocks spoofing' but 'what signal do I want to send to receivers about unlisted sources'.
-all (hard fail) vs ~all (soft fail): the real difference
`-all` is a hard fail. It tells receivers: any server not listed here is not authorized, treat the message as forged. `~all` is a soft fail: these sources are probably not authorized, but accept the mail and mark it as suspicious rather than reject it outright.
In practice most large receivers treat both similarly for filtering, but hard fail is a firmer instruction. Gmail, Outlook, and Yahoo will more readily send a hard-fail message straight to spam — and some smaller or stricter servers will reject it at SMTP time, meaning the mail bounces and never arrives. Softfail almost never triggers an outright rejection on its own.
That difference matters most for the sources you forgot about: a helpdesk tool, a billing provider, a marketing platform someone connected last year. Under `-all`, a legitimate but unlisted sender can get bounced. Under `~all`, the same mail still gets through, just flagged.
- -all — strongest anti-spoofing signal; risks bouncing legit mail from sources you missed
- ~all — accepts unlisted mail but marks it suspicious; forgiving during rollout and forwarding
- ?all (neutral) and +all — avoid; neutral asserts nothing and +all authorizes the entire internet
Why ~all is safer than it looks
Here is the part most 'switch to -all for security' advice skips: SPF alone does not stop spoofing, because it authenticates the hidden envelope (return-path) domain, not the visible From: address your recipient sees. An attacker can pass SPF on their own domain while forging your brand in the header. The header From: is what DMARC checks — and DMARC is what actually enforces rejection.
With DMARC set to `p=reject`, a message that fails alignment gets rejected regardless of whether your SPF ends in `~all` or `-all`. The soft-fail record plus a strict DMARC policy gives you full anti-spoofing enforcement without the SMTP-level bounce risk of `-all`. That is why many mature senders keep `~all` and let DMARC do the hard blocking.
If you are auditing this, our free DMARC checker shows your SPF, DKIM, and DMARC records together so you can see how the three interact rather than tuning one in isolation.
When -all is the right call
Use `-all` when you are confident your SPF record is complete — every legitimate sending source is included — and you want the strongest possible statement to receivers and to any server that does not evaluate DMARC. Transactional-only domains, parked domains that should never send mail, and tightly controlled infrastructure are ideal candidates.
A dedicated no-send domain deserves `v=spf1 -all` with nothing else: it declares that no server is ever authorized, which shuts down a common spoofing vector for domains that only host a website.
The trap is switching a busy business domain to `-all` while a forgotten sender still routes mail through an unlisted IP. Forwarding also breaks SPF — a forwarded message arrives from the forwarder's server, fails SPF, and under `-all` can be rejected. That is another reason to lean on DMARC alignment (which DKIM survives forwarding to satisfy) rather than a blunt hard fail.
How to roll out and monitor the change
Treat the qualifier as the last thing you tighten, not the first. Start with `~all`, publish a DMARC record at `p=none` with an `rua=` aggregate reporting address, and read the reports for a couple of weeks. Those reports name every source sending as your domain, so you can add the legitimate ones to SPF before anything gets blocked. Our guide to fixing SPF, DKIM and DMARC walks through that sequence end to end.
Once the reports are clean, you have two safe paths to enforcement: keep `~all` and move DMARC to `p=quarantine` then `p=reject`, or — if the domain's sending is stable and fully inventoried — move SPF to `-all` as well. Both give you real protection; the DMARC route is simply more forgiving of forwarding and stray sources.
Whichever you pick, records drift. A new tool gets added, someone edits DNS, an include: chain changes upstream. VigilDog's deliverability and DNS monitoring watches your SPF, DKIM, and DMARC records continuously and alerts you when they change or break — so a tightened qualifier keeps protecting you instead of quietly bouncing next quarter's invoices.
