-all says mail from unlisted senders is not authorized (fail), ~all says it probably is not (softfail), ?all makes no statement (neutral), and +all authorizes everyone. For most domains that run DMARC, ~all is a safe default and -all is correct once you are certain every sender is listed. In both cases the receiver, not SPF, decides what happens to the message. Look at your current ending with the SPF checker.
The four endings
| Ending | SPF result | Meaning in RFC 7208 | Receiver action |
|---|---|---|---|
-all | fail | “an explicit statement that the client is not authorized” (§2.6.4) | “a matter of local policy” (§8.4); rejection is allowed |
~all | softfail | “a weak statement … that the host is probably not authorized” (§2.6.5) | “SHOULD NOT reject the message based solely on this result” (§8.5) |
?all | neutral | no assertion about the IP address (§2.6.2) | “treated exactly like the ‘none’ result” (§8.2) |
+all | pass for any sender | authorizes every IP | Accepted by SPF; no protection |
+all is almost always an error or a trap. Anyone can send as your domain and pass SPF. The checker flags it as an error: “+all allows any sender”.
What receivers do in practice
The RFC leaves the disposition to the receiver. Some reject on -all, some mark the message as spam, and some use the result only as one input to a spam score. Do not count on -all to bounce forged mail on its own. The reverse also holds: a ~all message is not guaranteed to be delivered, because other signals can still send it to spam.
The result appears in the Authentication-Results header of the received message, which you can read with the email header analyzer. Look for spf=softfail, spf=fail, spf=neutral or spf=pass. A fail that comes from a forwarded message is expected: forwarding changes the connecting IP, so SPF fails even for legitimate mail. DKIM survives forwarding better, which is why DMARC accepts either.
DMARC changes what the result means
DMARC passes when SPF or DKIM passes and that passing identifier aligns with the From domain (RFC 9989 §4.4). A softfail or fail from SPF counts as no SPF pass. So with DMARC in place:
~alland-allproduce the same DMARC outcome for SPF: no pass. The DMARC policy (p=none,quarantine,reject) then governs what happens, if DKIM does not pass either.- Receivers that apply DMARC with an enforcement policy often ignore the strictness of
-all, because the DMARC decision is the one that counts. - With
-all, a receiver may reject on SPF before it ever reads DMARC. That is a risk if your record is missing a sender. A message that would have passed through DKIM and DMARC can bounce at the SPF stage.
For that reason, many guides recommend ~all with DMARC, and -all only when you control the full sender list. This is a practical judgement, not an RFC requirement. RFC 7208 §8.5 does say receivers should not reject on softfail alone.
Which should you publish?
- Setting up, unsure about senders:
~all, and use DMARC aggregate reports to find the missing ones. See DMARC reports explained. - Every sender known, DKIM aligned for all of them:
-allis reasonable. Check with the lookup tree in the checker that you are under the limit, see SPF too many lookups. - Parked domains that send no mail:
v=spf1 -all. ?all: rarely useful. It tells receivers you are not committing to anything. Some provider documents use it in examples; replace it when you are ready.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
parked.example. 3600 IN TXT "v=spf1 -all"
Changing from -all to ~all or back does not need a new DKIM or DMARC step, but lower the TTL first so you can revert quickly. See How to set up an SPF record.
FAQ
Does softfail put mail in spam? Not by rule. RFC 7208 §8.5 says receivers should not reject on it alone, but they may use it as a spam signal.
Is -all more secure than ~all with DMARC?
Only marginally. DMARC enforcement is what blocks forged mail; -all mainly adds the risk of rejecting your own mail if a sender is missing.
Why does the checker warn about “all” not being last?
Terms after all are never evaluated (RFC 7208 §5.1), so a sender placed after it is not authorized.
Sources
- RFC 7208, §2.6 Results of Evaluation: https://www.rfc-editor.org/rfc/rfc7208#section-2.6
- RFC 7208, §8 Receiving Hosts: https://www.rfc-editor.org/rfc/rfc7208#section-8
- RFC 7208, §5.1 “all”: https://www.rfc-editor.org/rfc/rfc7208#section-5.1
- RFC 9989, §4.4 Identifier Alignment Explained: https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4