SPF ~all vs -all vs ?all: What Each Policy Actually Means

In an SPF record, -all returns fail for any sender that reaches it, ~all returns softfail, and ?all returns neutral. The result describes whether the SMTP client is authorized to use the envelope domain. It does not order every receiver to reject, accept, or place the message in spam.

The word all is the simple part. It always matches. The character before it decides the result, so the useful question is not “Which one is stricter?” It is “What should my policy say after every earlier authorization has failed to match?”

Read the qualifier as the result of a match

SPF evaluates mechanisms from left to right. A matching mechanism ends the evaluation and returns the result attached to its qualifier. No prefix means +, which is pass. RFC 7208 section 4.6.2 defines the four qualifiers:

Qualifiers are not reserved for all. You could write -ip4:192.0.2.0/24, although that would be unusual. The qualifier belongs to the mechanism immediately after it.

all is normally last because it always matches. Anything after it is unreachable and must be ignored. A record without all or redirect ends with an implicit ?all, but an explicit ending is easier to inspect and debug.

One trace shows what the ending actually changes

Consider this hypothetical policy. The domain and IP ranges are reserved for documentation:

example.test. TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.25 ~all"

Now evaluate three SMTP clients against the MAIL FROM domain example.test:

192.0.2.44
  ip4:192.0.2.0/24 matches
  result: pass
  ~all is never reached

198.51.100.25
  first ip4 does not match
  second ip4 matches
  result: pass
  ~all is never reached

203.0.113.9
  neither ip4 mechanism matches
  ~all always matches
  result: softfail

If I change only the ending from ~all to -all, the first two clients still pass. Only the third result changes, from softfail to fail. That is the boundary to keep in mind: the terminal qualifier affects clients that have already missed every earlier authorization.

This is also why adding a new sender after all does nothing. The evaluator never gets there. Add the sender before the terminal mechanism, then test the exact envelope domain that service uses.

Does -all force receivers to reject the message?

No. SPF produces an authentication result; the receiver applies its own message-handling policy. RFC 7208 section 8.4 calls fail an explicit statement that the client is not authorized, but it also says disposition is a matter of local policy. A receiver may reject during SMTP, use the result with other signals, or accept the message for further processing.

softfail is intentionally weaker. The RFC says a receiver should not reject solely because of that result, although it may give the message closer scrutiny. neutral is weaker again: it must be treated like none, meaning there is no definite authorization assertion.

The strongest fair objection is that this makes -all sound toothless. It is not. A definitive fail gives receivers a stronger, machine-readable statement than softfail. The limitation is about control. A domain owner publishes authorization evidence; a receiving operator still decides how that evidence affects delivery.

Should you use ~all or -all?

Use -all when the sending inventory for that envelope domain is complete, every legitimate path passes, and you are prepared to make a definitive statement about everything else. Use ~all while the inventory or migration is still being validated, or when an operational constraint makes that weaker assertion deliberate.

I would not choose between them by copying a provider's sample record. Start with the identity in the SMTP MAIL FROM, then list every system allowed to use that exact domain: application mail, help desk, billing, CRM, campaign platform, on-premises relay, and any outbound gateway. Remove retired systems. Check each provider's current SPF requirement, including nested includes and the 10-term evaluation limit.

As of October 15, 2026, Google's Workspace setup guidance recommends ~all for its sample SPF records and tells administrators to identify every sender first. That is valid guidance for its customers, not a revision to the SPF standard and not a universal reason to avoid -all. The standard explicitly notes that a domain needs a policy ending in -all, directly or through redirect, when it wants receivers to make a definitive negative authorization determination.

For a domain that must never originate mail, the decision is simpler. RFC 7208 section 10.1 gives v=spf1 -all as the established policy for a non-sending domain. Do not publish ~all there merely because it feels safer. There is no legitimate sender to discover.

Tighten the policy without guessing

A safe rollout is evidence-driven. Publish the complete authorization set, send through every legitimate system, and inspect the trusted receiver's Authentication-Results header. Record the evaluated smtp.mailfrom domain and SPF result. A pass for a different envelope domain does not validate the record you are changing.

Use DMARC aggregate reports to find sources using your visible From domain, but read them carefully. SPF can contribute to DMARC only when the SPF-authenticated MAIL FROM domain aligns with the visible From domain. RFC 9989 section 4.4.2 defines that relationship. An SPF pass from an unrelated domain does not make DMARC pass.

Before changing ~all to -all:

1. Confirm there is exactly one selectable SPF record. If there are two, fix the multiple-record permerror first.
2. Trace every authorized sender through the full record, not only the visible top-level includes.
3. Send a real message from each system and verify the trusted receiver reports SPF pass for the intended envelope domain.
4. Keep DKIM signing and DMARC alignment in place. SPF alone does not authenticate the visible From domain.
5. Change only the terminal qualifier, wait through the previous DNS TTL, then repeat the same sending-path tests.

The site's SPF checker can show the published record, terminal policy, includes, and redirect target. That is configuration evidence. The receiver's result on an actual message remains the proof of how one sending path evaluated.

Why +all is different

+all makes every client pass because all always matches and + returns pass. It does not mean “accept all of my known senders.” It means any host can obtain an SPF pass for that domain's identity. That defeats SPF's authorization job and should not be used as a rollout mode.

SPF pass is not a safety verdict either. It says the client was authorized to use one envelope or HELO identity. It does not prove the message is harmless, the visible From domain aligns, the recipient mailbox exists, or delivery is guaranteed. The SPF, DKIM, and DMARC guide owns the alignment step.

My practical decision is short: use ~all when you are still validating a real sending inventory, move to -all when that inventory is complete and tested, use v=spf1 -all for domains that never send, and never use +all. That sequence ties the terminal result to sending paths you have actually verified.