SPF Hard Fail vs Soft Fail: What the Difference Means for Your Email

The short answer: Use -all (hard fail) once your SPF record is complete — it tells receiving servers to reject email from any unlisted server. Use ~all (soft fail) only temporarily while you're still identifying all your senders — it marks unlisted senders as suspicious but still delivers the mail. Never use +all, which allows any server to send from your domain and negates SPF entirely.

The last mechanism in every SPF record is the all qualifier — and most domain owners either copy it from a template without understanding what it does, or deliberately choose the weaker option out of caution.

The difference between -all (hard fail) and ~all (soft fail) determines what receiving mail servers do with email that comes from a server not listed in your SPF record. Getting this right matters — both for your security posture and your deliverability.

The Four Options for the all Mechanism

SPF uses a qualifier prefix before the all mechanism. There are four:

Qualifier	Name	Meaning
`-all`	Hard Fail	Reject or discard email from unlisted servers
`~all`	Soft Fail	Accept but mark email from unlisted servers as suspicious
`?all`	Neutral	No policy statement — treat unlisted senders like anyone else
`+all`	Pass All	Allow any server to send — never use this

In practice, nearly every SPF record should use either -all or ~all. The other two are rarely appropriate.

What -all (Hard Fail) Does

v=spf1 include:_spf.google.com -all

When a receiving server checks the SPF record and the sending IP isn't listed, -all instructs it to treat the message as a hard fail. The server is authorised to reject or discard the email.

In practice: What actually happens depends on the receiving server's local policy. Some servers reject the message outright. Others deliver it but mark it with a failure result. The RFC specifies that -all signals "definitely not authorised" — but enforcement is up to the receiver.

With DMARC: If you have p=reject set in your DMARC record, the DMARC policy enforcement takes precedence anyway. But at p=none, SPF -all is one of the few signals that can still cause rejection at strict receiving servers.

What ~all (Soft Fail) Does

v=spf1 include:_spf.google.com ~all

When a sending IP isn't listed in the SPF record, ~all marks the result as a soft fail — suspicious but not definitively unauthorised. Most receiving servers treat soft fail as "deliver but lower the trust score."

In practice: Email from unlisted senders is more likely to be flagged as spam or have its spam score increased. It's generally delivered, but with reduced confidence.

The common misconception: Many domain owners think ~all is safer because it won't accidentally block legitimate email. This is mostly backwards — if you've correctly listed all your legitimate senders in SPF, -all won't block them. The only email -all stops is email from servers that shouldn't be sending on your behalf. That's exactly what you want.

What +all Does (and Why You Should Never Use It)

v=spf1 include:_spf.google.com +all

+all tells receiving servers that any server on the internet is authorised to send email from your domain. This completely defeats the purpose of SPF — it tells receivers to trust everyone, which provides zero protection against spoofing.

If your SPF record ends with +all, remove it immediately and replace it with -all. There is no legitimate reason to use +all in production.

Hard Fail vs Soft Fail: Which Should You Use?

Use -all when:

You're confident all legitimate senders are correctly listed in your SPF record
You have DMARC configured and are monitoring aggregate reports
Your authentication setup is stable

Use ~all temporarily when:

You're still discovering all your sending services (during the p=none monitoring phase)
You're making changes to your SPF record and want a safety net while verifying
You have services you suspect are sending on your behalf that you haven't confirmed yet

The goal is to reach -all. Use ~all as a transitional state, not a permanent one.

Does -all vs ~all Still Matter When You Have DMARC?

Yes — but less directly than before DMARC existed.

With DMARC at p=reject, unauthenticated email is blocked by the DMARC policy regardless of whether SPF says -all or ~all. In that sense, your DMARC policy becomes the primary enforcement mechanism and SPF's all qualifier becomes secondary.

But:

Not all receiving mail servers evaluate DMARC
SPF results are still used independently by spam filters, even outside DMARC evaluation
Some receiving configurations give weight to SPF hard fail specifically
Using -all signals a complete, well-configured SPF record — which is a trust signal in itself

Best practice is -all plus DMARC at p=reject. Both together.

A Common Mistake: Omitting the all Mechanism Entirely

Some SPF records are published without any all mechanism at the end:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com

This is treated the same as ?all (neutral) — no policy statement. Unlisted senders get no guidance from your SPF record. This is weaker than ~all and significantly weaker than -all.

Every SPF record should end with an explicit all qualifier.

What Your SPF Record Should Look Like

A correctly structured SPF record for a domain using Google Workspace:

v=spf1 include:_spf.google.com -all

For a domain using both Google Workspace and SendGrid:

v=spf1 include:_spf.google.com include:sendgrid.net -all

If you're building or rebuilding your SPF record, use the generator to select your providers, add any custom includes or IP ranges, and set the enforcement level.

Build your SPF record — free SPF Record Generator at EmailAudit.io

After publishing, verify the record is correct and check your lookup count stays under 10.

Validate your SPF record — free SPF Checker at EmailAudit.io

Related Guides

Get a free Full Audit PDF at EmailAudit.io — it shows your SPF record, enforcement level, lookup count, and whether your overall authentication setup is protecting your domain. No account required.