Every SPF record ends with an all mechanism that says what to do with servers not on the list. The choice between ~all and -all is one of the most argued-about details in email authentication. The short answer: on its own it matters, with enforced DMARC it matters much less, and for parked domains it should be -all.
The four endings
| Ending | Name | Meaning (RFC 7208) |
|---|---|---|
-all | Fail (hardfail) | Servers not listed are not authorised. |
~all | Softfail | Servers not listed are probably not authorised; accept but treat with suspicion. |
?all | Neutral | No statement about servers not listed. |
+all | Pass | Every server in the world may send. Never use this. |
A record with no all at all behaves like neutral for unlisted servers. Hookgap flags +all as critical and ?all as worth fixing, because both make SPF close to meaningless.
How receivers treat softfail and fail
RFC 7208 leaves the action to the receiver. In practice, large mailbox providers rarely reject on SPF alone; they feed the result into spam filtering and into DMARC. Some smaller or stricter servers do reject outright on -all failures, at the moment the message arrives.
What DMARC changes
DMARC only asks one question of SPF: did it pass, for an aligned domain? Softfail and fail are both "did not pass". So once a domain has an enforced DMARC policy (p=quarantine or p=reject), the receiver's action on spoofed mail comes from DMARC, and the SPF ending becomes a secondary signal.
That is also why the argument for ~all exists. When email is forwarded, SPF fails (the forwarder is not in your list) but DKIM often survives. If a receiver rejects at SPF fail before DMARC is evaluated, a legitimate message that would have passed DMARC through DKIM is lost. With ~all, the receiver carries on and lets DMARC decide.
A simple rule
- Active domain with enforced DMARC:
~allis a sound default.-allis also fine if forwarding is rare for the client. - Active domain without enforced DMARC: fix DMARC first. Changing the SPF ending is not a substitute. See DMARC policies explained.
- Domain that sends no email (parked, redirect-only, old brand):
v=spf1 -allplusv=DMARC1; p=reject.
More SPF problems than the ending
In practice, the ending is rarely the real issue. The problems that cause failures are:
- Over 10 DNS lookups, which makes SPF a permanent error for every message. Count them with the SPF lookup counter and read why it happens.
- Two SPF records, which also makes SPF fail.
- A sender missing from the list, usually a tool added after the record was written.
- Relying on SPF alone: it does not survive forwarding and does not align for many third-party tools. Aligned DKIM is what makes DMARC robust. See SPF, DKIM and DMARC explained.
Frequently asked questions
Is -all more secure than ~all?
On its own, -all is a stronger statement, but with an enforced DMARC policy the difference is small: DMARC treats both softfail and fail as "not passing". Enforced DMARC is what actually stops spoofing.
Can -all cause legitimate email to bounce?
Yes. Some receivers reject on SPF fail before evaluating DKIM or DMARC, so a forwarded message that would have passed DMARC through DKIM can be refused. That is the main argument for ~all on active domains.
What SPF record should a domain that sends no email use?
v=spf1 -all, together with a DMARC record of v=DMARC1; p=reject. That tells receivers no server is allowed to send for the domain.
Keep reading
SPF too many DNS lookups · 6 min read
The SPF 10-lookup limit: why adding one more email tool breaks it
Why SPF silently fails after a few include: entries, how to count lookups, and how to fix it without breaking mail.
Guide · 13 min read
SPF, DKIM and DMARC explained: the complete guide for MSPs
How the three email authentication records fit together, with real examples, alignment explained and a rollout plan that does not break mail.
DMARC p=none vs reject · 5 min read
DMARC p=none vs quarantine vs reject, in plain English
What each DMARC policy does to fake email, and a safe path from p=none to p=reject.