SPF Softfail (~all) vs Hardfail (-all): Which Should You Use?

The last characters of an SPF record decide how strictly receivers treat unauthorised senders. Compare ~all, -all, ?all and +all, and choose the right one.

3 min read

Every SPF record ends with an all term and a qualifier in front of it. That tiny symbol tells receivers how to treat any server that is not on your list. Choosing it badly either lets spoofers through or blocks your own mail.

For the full picture of how SPF works, start there. This article is only about the ending.

The four qualifiers

EndingNameMeaningTypical result
-allHardfailOnly the listed servers are allowedMessage fails SPF
~allSoftfailProbably not allowed, but do not be strictMarked suspicious
?allNeutralNo opinionTreated as no policy
+allPassEveryone is allowedNever use this

+all turns your SPF record into a statement that anyone on the internet may send as you. If you ever see it in a record, remove it.

What receivers really do with each

The SPF standard describes results, but it leaves the final decision to the receiving server. In practice:

  • Hardfail (-all) gives a clear fail result. Many large providers do not reject outright on SPF fail alone; they combine it with other signals and with your DMARC policy.
  • Softfail (~all) is treated as a weak signal. The mail is usually accepted but scored as slightly more suspicious.
  • Neutral (?all) is mostly ignored.

Since DMARC became widespread, the exact choice between ~all and -all matters less than it used to. DMARC evaluates SPF and DKIM together and applies your DMARC policy. A message that fails SPF but passes aligned DKIM still passes DMARC.

Which should you choose?

Use ~all while you are building and testing. It is forgiving. If you forgot a legitimate sender, mail will still arrive, only with a weaker authentication signal. Pair it with a DMARC record at p=none so you can see which senders fail, as described in our DMARC rollout guide.

Move to -all once you are confident that every sender is listed and your DMARC reports are clean. It states your intent clearly and makes spoofing from unlisted servers fail SPF unambiguously.

Many mail administrators leave ~all permanently and rely on DMARC p=reject for enforcement. This is a reasonable choice, especially because forwarding breaks SPF regardless: a forwarded message from a legitimate sender can fail, and a hard fail can make that failure more severe at strict receivers.

A pragmatic rule:

  • Domain that sends mail for many tools, or with unclear senders: ~all plus DMARC.
  • Domain with a small, fully known sender list: -all plus DMARC.
  • Domain that never sends email: v=spf1 -all. This is the strongest anti-spoofing record you can publish for a parked domain.

Example records

A domain with one mail server and one application relay:

v=spf1 ip4:203.0.113.25 include:_spf.relay.example ~all

A domain that sends nothing:

v=spf1 -all

Mistakes to avoid

  • Placing text after all. Terms after all are never evaluated. Put all last.
  • Using ?all for years. It signals that you do not care. Receivers treat it like having no SPF.
  • Switching to -all before checking your senders. You will block your own invoices, password resets or newsletters.
  • Adding a second SPF record to change the ending. Edit the existing one. Two records cause an error.

Changing it safely

  1. Review the last few weeks of DMARC reports for any legitimate source failing SPF.
  2. Add the missing senders, staying within the 10-lookup limit.
  3. Edit the single SPF TXT record and change the ending.
  4. Test with a message to a mailbox you control and inspect the headers, as in how to check SPF, DKIM and DMARC.

With Mailions

The SPF record shown in Mailions for each domain ends with a softfail so a forgotten sender is not blocked while you are setting up. You can tighten it later by editing the TXT record at your DNS provider, and the panel's DNS check will confirm the live value.