SPF softfail vs hardfail: what ~all and -all actually do
SPF softfail and hardfail get treated as a security setting when they are really a suggestion. Here is what SPF actually checks, what the qualifiers mean, and why the honest modern answer depends on DMARC.
What SPF actually checks (and what it does not)
SPF (Sender Policy Framework) publishes a list of servers allowed to send mail claiming your domain in the envelope-from (the Return-Path address used for bounces), and lets receiving servers check the sending IP against that list. Crucially, SPF validates the envelope-from, not the visible From header a person reads in their inbox - a message can fail SPF on its technical sender and still show your name and address up top. This gap is exactly why SPF alone never stopped display-name spoofing, and why DMARC exists to close it.
The qualifiers: ~all, -all and ?all
The all mechanism sits at the end of an SPF record and sets the default outcome for any sending server not explicitly listed. -all is a hardfail: explicitly says non-matching servers should be rejected. ~all is a softfail: says non-matching servers are suspicious but should still typically be accepted, usually marked or scored rather than bounced. ?all is neutral - it makes no assertion either way and is rarely useful outside testing. +all passes everything regardless of sender and should never appear in a real record.
The honest answer: with DMARC enforced, this matters less than people think
SPF cannot see the visible From header, so SPF alone deciding to hardfail does not stop spoofed-looking mail landing in a real inbox. What actually determines disposition is DMARC, which checks SPF and DKIM alignment against the visible From domain and then applies its own policy - none, quarantine or reject. Once DMARC is enforced at quarantine or reject, an SPF softfail on a genuinely failing message gets caught by DMARC regardless of whether the SPF record itself said ~all or -all. This is why a growing number of deliverability engineers now recommend ~all paired with an enforced DMARC policy, rather than -all: it avoids SPF false-positives breaking legitimate forwarded mail while DMARC still catches the spoofing.
How to read your own SPF record
Run dig TXT yourdomain.com +short (or nslookup -type=TXT yourdomain.com on Windows) and look for the line starting v=spf1. Read it left to right: each include: pulls in another provider’s allowed servers (your email host, your marketing platform, your helpdesk), ip4:/ip6: mechanisms list specific addresses, and the final qualifier before all sets the default. If you see more than one line starting v=spf1, that is a broken record - DNS permits only one SPF TXT record per domain and a second one invalidates SPF checking entirely.
The 10-lookup limit and flattening
SPF evaluation is capped at 10 DNS lookups per check (each include, a, mx, ptr, and exists mechanism counts). Domains that have accumulated includes from every marketing tool and helpdesk added over the years frequently exceed this limit, which causes receivers to treat the record as a permanent SPF failure - a silent deliverability problem that shows up nowhere except mail landing in spam. SPF flattening tools resolve includes down to static ip4 ranges to stay under the limit, at the cost of needing re-flattening whenever a provider changes its sending ranges.
Check yours alongside DKIM and DMARC together
SPF is one leg of a three-part system - it means little without DKIM (which signs the message content) and DMARC (which enforces alignment and disposition). AuditHQ’s security suite checks all three via live DNS lookups, flags multiple SPF records, near-limit lookup counts and weak qualifiers, and explains what each finding means in plain English rather than raw DNS output. The free scan checks a sample of these in about 60 seconds.
Frequently asked questions
Should I use ~all or -all?
It depends on your DMARC state. With DMARC enforced at quarantine or reject, ~all is the safer default because it avoids SPF false-positives on legitimately forwarded mail while DMARC still catches genuine spoofing. If you have no DMARC record at all, -all gives you slightly more protection from SPF alone, but the real fix in that case is publishing DMARC, not tightening the SPF qualifier.
Does SPF softfail mean the email still gets delivered?
Usually, yes. A softfail typically results in the message being accepted but scored as more likely spam, or flagged, depending on the receiving server’s own policy - SPF results are an input to spam filtering, not an automatic reject. Only a hardfail combined with a receiver that strictly enforces -all tends to cause an outright rejection.
Why does my legitimate email fail SPF?
The most common causes are forwarding (the forwarding server is not in your SPF record and rewrites the envelope-from), sending through a third-party platform you have not added as an include, or exceeding the 10-lookup limit so the whole check is treated as a permanent error. Check the specific failure reason in your mail server logs or a DMARC aggregate report rather than guessing.
Is SPF enough on its own?
No. SPF alone does not protect the visible From header a recipient actually reads, so it cannot stop display-name spoofing by itself. SPF plus DKIM plus an enforced DMARC policy together are what actually make your domain hard to spoof convincingly.