Should your SPF record end in ~all or -all, and what +all authorises

End the record in ~all and publish DMARC to do the rejecting. The record you copied years ago with -all on the end still works. Once DMARC is in place it protects you no better than ~all would, and it costs you forwarded mail. If your record ends in +all you’ve told the world that anyone may send as you, and the fix is one character.

What the last token asks a receiver to do

An SPF record is a list of sending sources followed by a verdict for anything that isn’t on the list. The qualifier in front of all is that verdict.

v=spf1 ip4:203.0.113.0/24 include:_spf.example.net ~all

The receiver checks the connecting IP address against 203.0.113.0/24 and against whatever _spf.example.net expands to. If it matches, SPF passes. If it doesn’t, the receiver reaches ~all and records a softfail. With -all in that position it records a fail, with ?all it records neutral, and with +all it records a pass for anything at all.

The receiver writes the outcome into the message headers, and that line is worth learning to read because it’s how you’ll diagnose bounces later:

Received-SPF: softfail (domain of transitioning example.com does not designate 198.51.100.7 as permitted sender)
Received-SPF: fail (domain of example.com does not designate 198.51.100.7 as permitted sender)

The word “transitioning” is the softfail tell. It comes from the original SPF specification, which described ~all as the setting for a domain still moving its senders into the record. That framing is twenty years old and it’s the reason so many guides still call ~all a temporary state. Receivers stopped treating it that way a long time ago.

SPF on its own produces a verdict and nothing more; the receiver decides what to do with it. Some receivers act on a fail during the SMTP conversation. Most hand the verdict to DMARC and let your DMARC policy make the call, so what your DMARC record says matters more than the qualifier does.

The case for -all

The -all argument is the one you’ll hear from anyone who learned SPF before DMARC existed, and it’s coherent. You know your senders and you listed them. Anything else is forged, so say so in the strongest term the protocol offers. A receiver that honours a hard fail refuses the forged message during the SMTP conversation, and the sender sees a bounce like this one:

550 5.7.23 The message was rejected because of Sender Policy Framework violation

That’s a rejection with no DMARC involved, and it’s the outcome the -all camp wants. There’s a tidiness argument as well. -all reads as a decision and ~all reads as a hedge, and audits reward records that look decided. When a supplier questionnaire asks whether your SPF record uses a hard fail, ~all earns you a follow-up email and a paragraph of explanation.

The argument holds cleanly for a domain that never sends anything a human might forward. A transactional subdomain that emits receipts and password resets and nothing else can carry -all and lose nothing by it.

The case for ~all

Forwarding is where -all stops being free. Someone with a mailbox at one provider sets up a rule that forwards their mail to a mailbox at another. Your message leaves your server, lands at the first provider, and the first provider passes it on to the second with your envelope sender still on it. The second provider evaluates your SPF record against the first provider’s IP address, and that address isn’t in your record because it isn’t yours.

With -all, the final receiver sees a hard fail. A receiver that acts on SPF at SMTP time rejects the message right there, and the person who forwarded it sees the bounce, or more often sees nothing at all and stops getting your mail. With ~all, the receiver records a softfail and carries on to DMARC. DMARC passes if either SPF or DKIM aligns, and DKIM survives forwarding because the signature travels inside the message, so the forwarded message is delivered.

~all with DMARC at p=reject rejects forged mail as firmly as -all does, because DMARC acts on its own result and doesn’t care which SPF verdict fed it. What ~all adds is that legitimate mail which lost its SPF alignment on the way still has a route home through DKIM, where -all closes that route at some receivers before DMARC gets a look.

Mailing lists are the second forwarding case and the same logic applies. List software resends your message from the list’s server, your SPF fails there whichever qualifier you chose, and whether the message survives depends on DKIM and on whether the list rewrote the From header.

Which way the internet went

The census settles the argument by counting. Of the domains that publish an SPF record at all in the September 2026 census, 84,153,065 end in ~all and 57,704,429 end in -all. Softfail is the majority choice by a wide margin, and that’s the choice of the operators who got as far as publishing SPF, which is the population whose opinion on the qualifier means anything.

Some of those operators chose ~all because the record they pasted ended that way, and some chose it after their first forwarding bounce, and the census can’t tell those apart. What it can say is that a receiver treating softfail as a temporary state would be mistreating the majority of authenticated mail on earth. So the “transitioning” wording in the header is a leftover from the specification, and you can read past it.

A smaller group ended the record in ?all, which tells the receiver nothing, and another group has no terminal all at all, which the receiver also treats as neutral. Both are worse than either side of the argument. A record that lists your senders and then declines to say anything about the rest has done the work and thrown the result away.

What +all authorises

+all means pass. Put it at the end of the record and the receiver’s check is over before it starts, because any IP address on the internet is now a permitted sender for your domain. The mechanisms in front of it don’t matter, since anything that fails to match them matches +all.

v=spf1 include:_spf.example.net +all

To a receiver that record is indistinguishable from having no SPF record, except that you went to the trouble of publishing it. The census found 39,589 domains ending in +all among those that publish SPF. Each of them has written down, in public DNS, that forgery is authorised.

+all tends to arrive by accident: a record copied from a forum answer that used it as a placeholder, or a setup wizard that offered “allow all” as a way to stop a bounce during a migration. If you find it in your record, the record is void until that one character changes.

The same effect hides in ip4:0.0.0.0/0 and in an include: of a domain whose own record ends in +all. The receiver evaluates the include, its +all matches, and your record passes the forgery as if you’d written the token yourself.

The record to publish

Read what you have first. From any terminal:

dig +short TXT example.com

or from PowerShell:

Resolve-DnsName example.com -Type TXT

You’re looking for the single line starting v=spf1. If two lines start that way, receivers treat the result as a permanent error and that has to be fixed before the qualifier matters. Then look at the last token. The free scan reads the same record and reports the qualifier alongside whether a DMARC policy exists to back it, so run it on your domain before you change anything and again after.

If the last token is +all, change it to ~all today and come back to the rest of this section tomorrow. The same change applies when it’s ?all or missing. For -all with DMARC at p=quarantine or p=reject, changing to ~all costs you nothing in protection and buys back your forwarded mail. For -all with no DMARC record, the -all is doing the only enforcement you have, so add DMARC first and soften the qualifier second, and forged mail gets no window in which it passes unchallenged.

A record that reflects the argument above looks like this:

example.com.          TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.example.net ~all"
_dmarc.example.com.   TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

The enforcement lives in the second line. The first line lists your senders and then, with ~all, tells the receiver to treat anything else as suspect and consult the second. Forged mail fails both SPF and DKIM and DMARC rejects it. Forwarded mail fails SPF, passes DKIM, and gets through.

The qualifier is one token in a record that has other ways to be wrong. The lookup limit and stale includes from a provider you left are covered in the SPF piece, and the policy that makes ~all safe is in the DMARC piece. If a specific bounce on forwarded mail brought you here, email delivery walks through reading the headers on the message that came back.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.