SPF Softfail vs Hardfail: Which Should You Use?

Use ~all (softfail) when you’re still identifying senders. Use -all (hardfail) when you’re confident your SPF record is complete. The difference is how strongly you’re telling receivers to treat unauthorized email—softfail suggests caution, hardfail demands rejection.

The all mechanism at the end of your SPF record defines what happens to email from servers not explicitly listed. Your choice signals your confidence level.

The Four Options

SPF records end with one of these:

Mechanism	Name	Meaning
+all	Pass	Allow everyone (defeats the purpose of SPF)
?all	Neutral	No opinion on unlisted servers
~all	Softfail	Unlisted servers are suspicious but not forbidden
-all	Hardfail	Unlisted servers are unauthorized—reject them

In practice, you’ll use either ~all or -all. The others are rarely appropriate.

Softfail (~all)

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

What it means: “I’ve listed my authorized senders, but I might have missed some. Treat unlisted senders with suspicion, but don’t outright reject them.”

How receivers interpret it:

• Gmail: May deliver to spam, adds to spam scoring
• Microsoft: Similar—factors into junk filtering
• Others: Varies, but generally marks as suspicious

When to use softfail:

• You’re still discovering all your legitimate sending sources
• You’ve recently added DMARC and are in monitoring mode
• You’re not 100% sure your SPF record is complete
• You have legacy systems that might send email unexpectedly

Hardfail (-all)

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

What it means: “These are my authorized senders. Period. Anything else is unauthorized and should be rejected.”

How receivers interpret it:

• Some reject outright
• Others deliver to spam with strong negative scoring
• Combined with DMARC p=reject, most will reject

When to use hardfail:

• You’ve audited all your sending sources
• Your DMARC reports show no legitimate senders missing from SPF
• You’re ready for stricter enforcement
• Your DMARC policy is at quarantine or reject

The Reality: Receivers Make Their Own Decisions

Here’s what many people don’t realize: receivers don’t always follow your SPF instruction literally.

Hardfail doesn’t guarantee rejection. A receiver might see -all, note the SPF failure, but still deliver to spam based on other factors (sender reputation, content, DKIM status).

Softfail doesn’t guarantee delivery. Combined with other negative signals, softfail can still result in rejected or junked mail.

The real enforcement comes from DMARC policy. SPF’s all mechanism is one signal among many.

Migration Path: Softfail to Hardfail

Step 1: Start with Softfail

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

Step 2: Add All Known Senders

As you identify legitimate senders from DMARC reports, add them:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all

Step 3: Monitor DMARC Reports

Look for SPF failures from legitimate sources. If you see failures from IPs you recognize as legitimate, add them before switching to hardfail.

Step 4: Switch to Hardfail

Once you’re confident:

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

Step 5: Keep Monitoring

New services get added. Employees sign up for tools that send email. Keep watching reports for new legitimate senders.

Common Scenarios

”I just set up SPF for the first time”

Use ~all. You haven’t discovered all your senders yet.

”I’ve had SPF for years with ~all, should I switch?”

Probably yes—if you’ve been monitoring and your record is complete. Check DMARC reports first to confirm no legitimate senders are missing.

”My DMARC is at p=reject, does SPF matter?”

Yes. Even with DMARC enforcement, -all provides clearer signaling. It tells receivers you’re confident in your configuration. Some receivers may honor strict SPF even before checking DMARC.

”I keep finding new senders I forgot about”

Stay at ~all until you’ve stabilized. There’s no shame in softfail—it’s the responsible choice when you’re not certain.

Softfail Is Not Weakness

Some guides treat ~all as “not serious about security.” That’s wrong.

Softfail is appropriate when:

• You’re actively working toward enforcement
• You’re being honest about your configuration certainty
• You’d rather not block legitimate email while you figure things out

Premature hardfail that blocks your own email is worse than softfail that allows some suspicious mail through.

The Interaction with DMARC

SPF result feeds into DMARC evaluation:

SPF Result	DMARC Check
Pass	SPF passes, check alignment
Softfail	SPF fails for DMARC purposes
Hardfail	SPF fails for DMARC purposes
None/Permerror	SPF can’t contribute to DMARC

For DMARC, softfail and hardfail are treated the same—both are failures. The difference is how receivers treat the email before DMARC evaluation, and as a signal of your intent.

Quick Decision Guide

Situation	Recommendation
New SPF setup	~all
DMARC at p=none	~all
Still finding senders in reports	~all
DMARC at p=quarantine, SPF complete	-all
DMARC at p=reject, confident in config	-all
Not sure	~all (you can always tighten later)

The Bottom Line

• ~all (softfail): Safe default while you’re learning your email ecosystem
• -all (hardfail): Use when you’re confident your SPF is complete
• Neither guarantees anything: Receivers make their own decisions
• DMARC matters more: Your DMARC policy is the real enforcement lever

Start with softfail. Move to hardfail when you’re ready. Don’t rush—blocking your own email is worse than being cautious.

For the complete SPF troubleshooting guide, see SPF Troubleshooting.

---

Verkh tracks your SPF configuration and shows which senders would be affected by switching to hardfail. See your SPF status at verkh.io.