Learn
SPF ~all vs -all: which ending to use
The last term of an SPF record decides what happens to servers you did not list. Here is what ~all, -all, ?all and +all each tell receivers, why DMARC narrows the gap between the first two, and which one fits your domain.
By Ahmet Karaca · Updated · Checked against RFC 7208 (SPF) and RFC 9989 (DMARC, May 2026) on
What each ending tells a receiver
An SPF record lists the servers allowed to send for your domain and finishes with an all term that answers the remaining question: what about every other server? all matches anything, so RFC 7208 places it last as the record's explicit default, and any term written after it is ignored. The character in front of it, the qualifier, decides which result an unlisted server gets.
| Ending | Result | What it says (RFC 7208, section 2.6) |
|---|---|---|
| -all | fail | An explicit statement that the server is not authorized to use your domain. |
| ~all | softfail | A weak statement that the server is probably not authorized, without committing to a firm policy. |
| ?all | neutral | You explicitly decline to say whether the server is authorized. |
| +all | pass | Every server on the internet is authorized to send as you. |
A record with no all and no redirect= behaves as if it ended in ?all: the RFC gives unmatched servers the neutral result by default and recommends ending explicitly anyway, because it makes the record easier to debug. And because all takes priority, a redirect= modifier is ignored in any record that also contains all.
What receivers actually do with fail and softfail
The qualifier is a statement of intent, not an instruction. RFC 7208 sets no required handling for any result, and its guidance for the two endings people actually choose between is worded carefully:
- For fail (section 8.4), the disposition is a matter of local policy. A receiver may reject the message during the SMTP conversation, and if it does, it should answer with code 550 and the enhanced status 5.7.1. If it accepts the message, it should record the result in a header for later processing.
- For softfail (section 8.5), the result sits between fail and neutral. Receivers should not reject a message based solely on it, but may look at the message more closely than usual. The RFC suggests highlighting the status to the user or greylisting as examples.
So on paper the difference is real: -all invites rejection, ~all asks for suspicion. How much it matters depends on the receiver. Some act on SPF early in the SMTP conversation, before DMARC has run, as the section on forwarding below explains. Others feed the SPF result into DMARC and their own filtering, and that is where the choice of ending loses much of its weight.
Why, with DMARC, both usually end the same way
DMARC asks a narrower question about SPF: did it pass, for a domain aligned with the From address? Only a pass result counts. Fail, softfail, neutral and a permanent error are all simply "not a pass". For a message from a server you did not list, -all and ~all therefore give DMARC exactly the same input. What happens next depends on DKIM: if the message carries a valid signature aligned with your domain, DMARC passes regardless of SPF; if not, DMARC fails and your published policy applies.
That is why, on a domain with a DMARC policy of p=quarantine or p=reject, the real protection against spoofing comes from DMARC. A forger sending from an unlisted server fails SPF either way and has no aligned DKIM signature, so your DMARC policy handles the message whichever ending you chose. On a domain without DMARC, or still on p=none, the ending carries more weight, because it is one of the few signals you are sending at all.
When -all can cost you legitimate mail
Forwarding is the classic problem. When a recipient forwards your message from one mailbox to another, through an alias, an old university address or a forwarding rule, the next server receives it from the forwarder's IP address. Your SPF record does not list that IP, and it cannot, so SPF fails there no matter how carefully you maintain the record. If the forwarder left the message intact, your DKIM signature still verifies and DMARC passes on it.
That rescue only works if the receiver gets as far as DMARC. Section 7.1 of RFC 9989 warns that SPF was designed to run early in the SMTP transaction, so some receivers check it before any DMARC processing. A hard fail from -all can then cause a rejection on the spot, and messages that would have passed DMARC thanks to an aligned DKIM signature are rejected solely because of SPF. The same section adds a second cost: those messages never appear in your aggregate reports, because the transaction ends before the From domain is even seen. A softfail does not invite that early rejection, since RFC 7208 asks receivers not to reject on softfail alone.
When -all is the right choice
- Domains that send no email. A parked domain, a redirect-only domain or a subdomain used only for a website should say that nothing may send for it. There is no legitimate mail to lose, and a hard fail makes the domain useless for forgery:
@v=spf1 -allA domain that sends no email
- Tightly controlled senders. If you know every service that sends as you, every one of them is in the record, and your DMARC reports have shown them all passing for weeks,
-allstates the truth and costs little. It still carries the forwarding risk above, so the case is strongest when all your services also sign with an aligned DKIM key.
For everyone else, ~all is the safer default. It marks unlisted servers as suspicious, leaves room for the sender you forgot, and, combined with DMARC enforcement, gives forgers no advantage over -all.
Never +all, and avoid ?all
+all gives every server on the internet a pass for your domain. It turns SPF from a protection into an endorsement of anyone who wants to send as you, and it hands such mail an SPF pass that, if their envelope uses your domain, even aligns for DMARC. There is no situation in which it is the right ending.
?all is less dangerous but says nothing: the neutral result tells receivers you have no opinion about unlisted servers, which is the same answer as having no ending at all. It is sometimes left over from a testing phase. Replace it with ~all.
How Patchkit scores the ending
The email domain health check has one item for the ending, "SPF blocks unlisted servers", worth 5 points. Because DMARC treats fail and softfail alike, both -all and ~all earn the full 5. A record ending in ?all gets a warning and 2.5 points, and so does a record with no ending and no redirect, since it behaves the same way. A record that ends in +all fails the item and gets 0. A record that hands over to another domain with redirect= instead of an ending passes, because the target record supplies the ending.
The SPF record checker reports the same cases as findings: an error for +all, which authorizes every server on the internet, and a warning for ?all, each with a link back to this page. The SPF generator offers only the two endings worth using, with ~all preselected while you set things up and -all one click away.
If you are still deciding whether your DKIM setup is solid enough to lean on, check why DMARC can fail even though SPF passes, and What is SPF? covers the rest of the record.