Quick answer
The most-asked SPF question is what separates ~all from -all at the end of a record. Both apply only to senders your record does not otherwise list. -all is a hardfail: it tells a receiver those senders are explicitly not authorized. ~all is a softfail: it tells a receiver those senders are probably not authorized, which is advisory, so the mail is usually accepted but marked. The all mechanism itself always matches (RFC 7208 §5.1); the qualifier in front of it carries the entire policy for every sender the rest of the record did not match. For every other SPF mechanism, see the full SPF record syntax reference; to see the result a receiver actually computes for your domain, run the SPF checker.
The four qualifiers on all
A qualifier is a single character in front of a mechanism, and on all it sets the default result for every sender your record did not otherwise match. There are four (RFC 7208 §4.6.2):
-allis fail (hardfail). Only the senders you listed are authorized; everything else fails.~allis softfail. Unlisted senders are probably not authorized, a deliberately weak statement.?allis neutral. You make no assertion at all about unlisted senders.+allis pass. Every sender is authorized, which is almost never what you want.
The qualifier is optional and defaults to + (RFC 7208 §4.6.2), so a bare all means +all. Because all always matches, it belongs at the very end of the record: any mechanism placed after it is never reached. The mechanisms that come before all, such as include, a, mx, ip4, and ip6, are what actually authorize your real senders, and they are covered in the SPF record syntax reference.
What each result tells a receiver to do
Publishing a qualifier is only half the story. What matters is what a receiving server does once it computes that result. RFC 7208 defines the results in §2.6 and the handling guidance in section 8.
- pass (
+all, or a sender you matched): the sender is authorized.+allhands this to every IP on the internet, which is why it is unsafe to publish. - fail (
-all): §2.6.4 is an explicit statement that the client is not authorized to use the domain. Disposition is a matter of local policy, and a receiver that chooses to reject during the SMTP transaction SHOULD use reply code 550 (§8.4). - softfail (
~all): §2.6.5 is a weak statement that the host is probably not authorized. Receiving software SHOULD NOT reject on softfail alone, but MAY subject the message to closer scrutiny than normal (§8.5). In practice that means accept-but-mark. - neutral (
?all): §2.6.2 says a neutral result MUST be treated exactly likenone, the result you get from publishing no SPF policy for that sender at all. It gives a receiver nothing to act on.
The gap that trips people up is between fail and softfail. Neither one forces a receiver to bounce the message, and both leave the final decision to the receiver. -all states the policy in the strongest terms the specification allows, and ~all states a softer version of the same thing.
Why -all is not the riskier choice
Tutorials often present ~all as the safe option and -all as the aggressive one that will bounce your legitimate mail. With modern DMARC in place, that framing is backwards. Three facts explain why.
First, SPF authenticates the return-path (the MAIL FROM address), not the visible From: header a person reads. A receiver evaluating -all is judging the envelope sender, and §8.4 leaves the disposition of a fail to local policy. Major mailbox providers rarely reject outright on an SPF fail by itself, because doing so would break ordinary forwarding.
Second, forwarding is exactly where SPF fails for legitimate mail. When a mailing list or a forward-to-my-other-account rule relays your message, it keeps your MAIL FROM but sends from its own IP, which your record does not list, so SPF fails whether you published ~all or -all. This fragility is the original reason receivers were reluctant to hard-reject on SPF alone.
Third, DMARC is the layer that turns authentication into an enforced policy, and it rescues that forwarded message. DMARC passes when either SPF or DKIM produces an aligned pass, so a message that fails SPF after forwarding still passes DMARC through its aligned DKIM signature. The reject decision then comes from your DMARC policy, not from the SPF qualifier. For how those policies work, see DMARC policy modes.
Put together: once every real sender is in your record and DMARC plus DKIM are working, -all is the correct, unambiguous setting. The Gmail and Yahoo bulk-sender rules do not mandate -all over ~all (they require a valid SPF or DKIM pass plus DMARC alignment), but with a clean record -all is the natural destination and costs you nothing. ~all does not protect your forwarded mail any better, because DKIM is what saves it, and softfail buys you nothing except a weaker, hazier statement.
How DMARC changes the calculus
For DMARC, ~all and -all are nearly interchangeable. DMARC only asks whether SPF produced an aligned pass; every other SPF result, softfail and fail alike, counts the same as not-a-pass. So moving a record from ~all to -all does not change how DMARC treats your legitimate, aligned mail. That mail already passes through the SPF or DKIM path, and unauthorized mail was already going to miss the aligned-pass bar. What -all adds is a clear signal at the SPF layer, for the receivers and filters that read the SPF result directly before DMARC is even considered. To confirm your record resolves to the sender list you expect, run the SPF checker; to see how the pieces fit together, read email authentication explained.
When ~all still makes sense
~all is a reasonable setting while you are still discovering which platforms send as your domain. Softfail lets you publish SPF and watch DMARC aggregate reports for sources you forgot, without a missing entry turning into a hard fail during the discovery window. Once the reports are clean and every legitimate sender is authorized, move to -all. Treat ~all as the rollout state and -all as the destination, not as two equally good permanent options.