Inboxpass All guides

Guides

SPF softfail vs hardfail: ~all or -all

29 October 2026

~all (softfail) says mail from servers not in your SPF record is probably not authorized. -all (hardfail) says it is not authorized, full stop. Receivers are told not to reject on softfail alone, and may reject on hardfail. For DMARC the two are the same, because only an SPF pass counts. The real choice is how much risk you accept that a hardfail rejects legitimate mail before DMARC gets to look at it.

The four endings

The last term in an SPF record, all, matches every server not listed before it. Its qualifier sets the result. RFC 7208 section 4.6.2 defines four:

The qualifier only affects servers that matched nothing earlier. Everything you list with include, ip4, and the rest still passes either way.

What receivers are told to do

RFC 7208 gives receivers guidance for each result:

The RFC’s introduction (section 2.1) explains why -all exists at all. A domain that wants receivers to reach a firm “not authorized” conclusion has to publish a record ending in -all, or redirect to one that does. Without it, there is no definite negative answer from SPF.

Why DMARC does not care

RFC 9989, the DMARC standard, counts SPF only when it produces a pass that aligns with the From domain. Fail, softfail, neutral, and none all count the same: not a pass. So an unlisted server sending as your domain fails DMARC’s SPF half whether your record ends in ~all or -all.

That changes the question. If you have DMARC at p=quarantine or p=reject, your DMARC policy is what tells receivers how to treat spoofed mail. The SPF ending adds little protection on top. It mostly adds a second, separate way for mail to be rejected.

The risk with -all

RFC 9989 section 7.1 describes the problem. A hard fail like -all can 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 an aligned DKIM signature can be rejected because of the SPF failure alone. And because the rejection happens before the message is accepted, it never appears in your DMARC aggregate reports.

The common case is forwarding. Someone forwards your invoice from their work address to their personal one. The forwarding server is not in your SPF record, so SPF fails. Your DKIM signature is still valid and aligned, so DMARC would pass. But a receiver that rejects on SPF fail never gets that far. Our guide to why DMARC fails covers forwarding in more detail.

The other case is a sender you forgot. With ~all, that mail gets a weak negative signal and is usually still judged on DKIM. With -all, some receivers bounce it outright, and you may not find out until a customer asks why they never got a receipt.

What Google and Microsoft recommend

They disagree, which tells you this is a judgment call.

Both agree on the more important point: SPF alone is not enough, and you need DKIM and DMARC as well.

How to choose

Use ~all when

Use -all when

For most small businesses with a handful of senders and DMARC in place, either choice is defensible. Which one matters less than having the right includes, DKIM on every sender, and a DMARC policy you are working toward enforcing.

Switching from ~all to -all

  1. Run DMARC at p=none with reports for a few weeks. See how to read a DMARC report.
  2. Confirm every legitimate source in the reports passes SPF on your domain or passes aligned DKIM.
  3. Check the record is under ten DNS lookups, with one record at the name. Our guide on too many lookups covers the count.
  4. Change only the last term from ~all to -all. Everything else stays the same.
  5. Watch for bounces and support tickets about missing email for a couple of weeks. If something breaks, change it back while you fix the sender.

Remember that hard-fail rejections do not show up in DMARC aggregate reports, per RFC 9989. Bounce messages and customer reports are how you will hear about them.

Things that are not a choice

Sources