SPF Softfail vs Hardfail: Which Should You Use?

At the end of every SPF record, there's a short piece of syntax that makes a big difference to your email delivery. The ~all (softfail) and -all (hardfail) qualifiers tell receiving mail servers what to do when an email comes from a server that isn't listed in your SPF record. Choosing the wrong one can mean lost emails or a false sense of security.

This guide explains what each qualifier does, how they differ in practice, and which one you should use depending on where you are with your email setup. For the full picture on SPF configuration, see our complete SPF guide.

What Softfail and Hardfail Mean

Every SPF record ends with an all mechanism that acts as a catch-all rule, as defined in RFC 7208. The character in front of all determines how strict that rule is.

Softfail (~all) tells receiving servers: "If the sending server isn't in my SPF record, treat this email with suspicion — but don't necessarily reject it."

Hardfail (-all) tells receiving servers: "If the sending server isn't in my SPF record, reject this email. It's not from us."

Here's what each looks like in a real SPF record:

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

The only difference is one character — the tilde (~) versus the hyphen (-) — but the impact on email handling can be significant.

How Receiving Servers Treat Each

In theory, the distinction is clear. In practice, it depends on the receiving mail server.

Here's the reality that surprises many people: most major providers like Gmail and Microsoft 365 treat softfail and hardfail similarly. They use SPF as one signal among many — alongside DKIM, DMARC, sender reputation, and content analysis. A softfail doesn't get a free pass, and a hardfail doesn't always mean instant rejection.

However, some stricter corporate mail servers do follow the qualifiers literally. With hardfail, these servers will reject emails from unlisted servers. With softfail, they'll accept the email but mark it as suspicious.

Why Most Domains Start with Softfail

If hardfail sounds more secure, you might wonder why most SPF records use softfail. There are several practical reasons.

You might not know all your senders. Many businesses are surprised to discover how many services send email on their behalf — CRM tools, help desks, billing systems, project management apps, and more. If you use hardfail before accounting for all these senders, legitimate emails get rejected.

Forwarded email breaks SPF. When someone forwards your email, it's now being sent from a server that isn't in your SPF record. With hardfail, forwarded emails fail SPF and may be rejected. With softfail, they're more likely to be delivered.

It's safer during setup. When you're first configuring email authentication, softfail gives you room to identify and fix issues without losing real emails. Need help building your record? SPF Creator can generate one with the right qualifier for your situation.

When to Switch to Hardfail

You should consider switching to -all when:

• You've had ~all in place for at least a few weeks
• You've checked your DMARC reports and confirmed no legitimate senders are failing SPF
• You've accounted for all services that send email on your behalf
• You're confident your SPF record is complete

Think of it like a staged rollout. Softfail is your testing phase. Hardfail is your production enforcement.

How DMARC Changes the Equation

Here's something important that many guides overlook: if you have a DMARC policy set to p=reject or p=quarantine, the difference between softfail and hardfail matters less than you might think.

DMARC sits above SPF and DKIM. When DMARC is set to p=reject, it tells receiving servers to reject emails that fail both SPF and DKIM alignment — regardless of whether your SPF record uses softfail or hardfail.

In other words, DMARC enforcement overrides SPF softfail. If an email fails DMARC alignment, it gets rejected even if your SPF record only softfails.

That said, hardfail still provides an extra layer of defense for receiving servers that check SPF before DMARC, and it's a clear signal of your domain's authentication intent.

The Other Qualifiers

While softfail and hardfail are the most common, SPF actually supports four qualifiers:

You should almost never use +all or ?all. The +all qualifier allows anyone to send as your domain, and ?all makes your SPF record meaningless. Stick with ~all or -all.

What Should You Do Right Now?

If you're not sure which qualifier to use, here's a quick decision guide:

• New domain or just starting with SPF? Use ~all. Get everything set up and monitored first.
• Established domain with all senders accounted for? Switch to -all for maximum protection.
• Have DMARC at p=reject? Either works, but -all is cleaner and signals strong authentication intent.
• Frequently forward emails or use mailing lists? Consider staying with ~all to avoid delivery issues with forwarded messages.

Whatever you choose, having an SPF record in the first place is what matters most. A record with ~all is dramatically better than no record at all.

References

• RFC 7208: Sender Policy Framework (SPF) — The current SPF specification, including qualifier definitions
• RFC 7489: DMARC — How DMARC policy interacts with SPF results

Monitor Your SPF Records