SPF softfail vs hardfail: should you use ~all or -all?

Every SPF record ends with an all mechanism, and the character in front of it is one of the most argued-over details in email authentication. The answer used to matter a lot. With DKIM and DMARC in place it matters much less, but there are still a few cases where the choice changes what happens to your mail.

What do ~all, -all, ?all and +all mean?

The character before a mechanism is its qualifier. RFC 7208, section 4.6.2 defines four, and if you leave it out the default is +. The all mechanism always matches, so it sets the result for any server not listed earlier in the record.

The quotes are from section 2.6. +all is never correct; it lets anyone send as your domain. If you need a refresher on the rest of the record, see SPF record syntax and examples.

What do receivers actually do with each result?

RFC 7208 deliberately leaves the decision to the receiver. It says there is "no comprehensive normative requirement for message handling in response to any particular result". It does give guidance:

• Fail (section 8.4): if a receiver rejects during the SMTP session, it should use reply code 550. Otherwise it should record the result in a header. What happens next "is a matter of local policy".
• Softfail (section 8.5): receivers "SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal".
• Neutral (section 8.2): "MUST be treated exactly like the 'none' result", the same as having no SPF at all.

Big mailbox providers describe the difference loosely. Google's About SPF records page says that with ~all, receivers "typically accept messages from senders that aren't in your SPF record, but mark them as suspicious", and with -all they "may reject" them.

In practice, most large receivers combine SPF with DKIM, DMARC and reputation rather than rejecting on SPF alone. Microsoft 365, for example, has an Advanced Spam Filter setting called SPF record: hard fail that marks hardfailing messages as high confidence spam, but Microsoft Learn lists it as off by default. Smaller or self-run mail servers vary. Some reject on any -all failure.

How does DMARC change the picture?

DMARC only cares whether SPF passed for a domain that aligns with the From address. RFC 9989 uses the SPF identity "if there is an SPF 'pass' result". Fail, softfail, neutral and none all mean the same thing to DMARC: SPF didn't help, so DKIM has to. Microsoft's SPF guidance puts it directly: "DMARC treats -all (hard fail) and ~all (soft fail) as SPF failures."

So once you publish DMARC with an enforcing policy, your DMARC policy decides what happens to spoofed mail, not the SPF qualifier.

The one place -all can hurt you

There's a catch. Some receivers check SPF early in the SMTP session, before they ever look at DKIM or DMARC. RFC 9989, section 7.1 warns that a hardfail "could cause a message to be rejected early in the SMTP transaction, before any DMARC processing takes place". A message that would have passed DMARC through aligned DKIM is rejected anyway. And because it was rejected early, it "will never appear in aggregate DMARC reports", so you won't see it happen.

The usual trigger is forwarding. When a message is forwarded, it arrives from the forwarder's server, which isn't in your SPF record. RFC 9989 section 7.4 says such mail "will most likely fail SPF checks" while "DKIM signatures will generally remain valid".

M3AAWG's email authentication best practices address this from both sides. For receivers, an SPF fail "should not result in a message rejection until after DMARC has been evaluated and been found to not pass". The only exception is a record of exactly v=spf1 -all, which says the domain sends no mail at all. Not every receiver follows that advice.

Why do Microsoft, Google and M3AAWG disagree?

They're optimizing for different risks.

All three agree on the bigger points: list every legitimate sender, set up DKIM and publish DMARC. For domains that don't send, Microsoft and M3AAWG recommend v=spf1 -all, while a tip on Google's About SPF records page suggests ~all.

How do large sites choose? In our scan of the Tranco top 1,000 domains in October 2026, 764 published SPF. Of those, 438 (57.3%) ended in -all, 274 (35.9%) in ~all, 19 (2.5%) in ?all, and 33 (4.3%) delegated the decision with redirect. None used +all.

Which one should you use?

1. Domains that never send mail: v=spf1 -all, plus a DMARC record of p=reject. Microsoft and M3AAWG both recommend this for parked domains.
2. Domains that send mail, while you're still finding all your senders: ~all. A missed service gets marked rather than rejected, and your DMARC reports show you what you missed.
3. Domains that send mail, with DKIM on every service and DMARC enforcing: either ~all or -all is defensible. ~all follows M3AAWG and Google and avoids early rejection of forwarded mail. -all follows Microsoft and gives receivers that act on SPF alone a stronger signal. Don't switch to -all until reports show every legitimate source passing.
4. Never use +all, and don't leave ?all in production. Microsoft calls ?all a testing value.

Changing the qualifier doesn't fix a broken record. If your SPF returns PermError, for example because of too many DNS lookups, the all mechanism is never reached.

How to check what your domain uses

1. Look up your record with the SPF Checker. It shows the all qualifier and flags +all and ?all.
2. Send a test message to an outside mailbox and open the headers in the Email Header Analyzer. Look for spf=pass and dkim=pass in Authentication-Results.
3. Read a week of DMARC aggregate reports and confirm every legitimate source passes DMARC through aligned DKIM, not just SPF.
4. If you need to rebuild the record, the SPF Generator produces a clean one with the ending you choose.

Next steps

• Check which ending your mail providers document: SPF records by email provider lists each provider's exact record.
• Publish v=spf1 -all and p=reject on every domain you own but don't send from.
• On sending domains, make sure aligned DKIM is in place everywhere before you worry about the qualifier. Setting up DKIM in Microsoft 365 and Google Workspace covers the two most common platforms.
• Keep an eye on changes. iBlockSpam's domain monitoring alerts you when your SPF or DMARC record changes: weekly on Protect, daily on Protect Plus.

Browse our other SPF, DKIM and DMARC guides.