The last part of your SPF record—the "all" mechanism—determines what happens when an email comes from an unauthorized source. The choice between ~all (softfail) and -all (hardfail) is one of the most important decisions in your email authentication setup.
Choose wrong, and you might block legitimate emails. Choose too cautiously, and you leave your domain vulnerable to spoofing. This guide explains the difference and helps you pick the right option.
Understanding the All Mechanism
Every SPF record should end with an "all" mechanism that defines the default policy for any sender not explicitly authorized. This catches emails from servers that don't match your listed IP addresses or includes.
The Four Options
| Syntax | Name | Result | What It Means |
|---|---|---|---|
-all |
Hardfail | Fail | Reject unauthorized emails |
~all |
Softfail | SoftFail | Accept but mark as suspicious |
?all |
Neutral | Neutral | No policy assertion |
+all |
Pass | Pass | Allow all (never use this) |
In practice, the choice comes down to softfail (~all) or hardfail (-all).
Hardfail (-all) Explained
v=spf1 include:_spf.google.com -all
Hardfail tells receiving servers: "If an email claiming to be from our domain doesn't come from an authorized source, it's definitely not legitimate—reject it."
What Happens
- Receiving servers should reject emails that fail SPF
- Failed emails may bounce back to the sender
- Provides the strongest protection against spoofing
When to Use Hardfail
- You've fully audited all services sending email for your domain
- Your SPF record includes all legitimate sending sources
- You've tested thoroughly with softfail first
- You're confident no legitimate email will fail SPF
Risks of Hardfail
- Legitimate emails can be rejected if you missed a sending source
- Email forwarding often breaks SPF, causing legitimate forwards to fail
- Third-party services sending on your behalf must be included
Softfail (~all) Explained
v=spf1 include:_spf.google.com ~all
Softfail tells receiving servers: "If an email claiming to be from our domain doesn't come from an authorized source, it's probably not legitimate—but don't reject it outright."
What Happens
- Receiving servers accept the email but mark it as suspicious
- The email may be delivered to spam/junk folder
- The SPF result is considered in overall spam scoring
- With DMARC, the failure is logged but email disposition depends on DMARC policy
When to Use Softfail
- You're still auditing your email sending sources
- You want to monitor SPF failures before enforcing
- You have email forwarding in your organization
- As a stepping stone before moving to hardfail
Advantages of Softfail
- Legitimate emails aren't rejected if you missed something
- Safer for initial SPF implementation
- Works better with email forwarding
- Gives you time to identify and fix issues
How Receiving Servers Interpret These
Important caveat: what actually happens depends on the receiving server.
Hardfail (-all)
Not all servers reject hardfails. Some major providers treat hardfail as a strong negative signal but don't automatically reject. The email may go to spam instead of being bounced.
Softfail (~all)
Most servers treat softfail as one factor among many in spam scoring. A softfail alone usually won't send email to spam, but combined with other negative signals, it might.
The DMARC Factor
When you have DMARC set up, it largely controls what happens to failed authentication:
- DMARC p=none — SPF failures are reported but don't affect delivery
- DMARC p=quarantine — SPF failures go to spam
- DMARC p=reject — SPF failures are rejected
With DMARC, the SPF softfail vs hardfail distinction becomes less critical—DMARC policy is what enforces the outcome.
The Email Forwarding Problem
This is the main reason many organizations stick with softfail.
How Forwarding Breaks SPF
When someone forwards an email from your domain:
- You send email from your authorized server (SPF passes)
- Recipient's server receives it
- Recipient forwards it to another address
- The forwarding server sends it on—but it's not in your SPF record
- The final destination sees an SPF failure
With hardfail, the forwarded email might be rejected. With softfail, it's accepted (possibly with reduced reputation).
The Solution: DKIM
DKIM signatures survive forwarding because they're attached to the message itself, not the sending server's IP. This is why implementing both SPF and DKIM is important—DKIM covers the forwarding gap.
Our Recommendation
For New SPF Records
Start with softfail (~all):
v=spf1 include:_spf.google.com ~allMonitor for 2-4 weeks using DMARC reports to identify any SPF failures from legitimate sources.
After Verification
Once you've confirmed all legitimate sources pass SPF, consider moving to hardfail:
v=spf1 include:_spf.google.com -allWith DMARC
If you're using DMARC with an enforcement policy (quarantine or reject), the softfail vs hardfail distinction matters less. DMARC controls the enforcement. You can stay with softfail and let DMARC handle policy enforcement.
Migration Strategy: Softfail to Hardfail
If you want to move from softfail to hardfail:
Step 1: Audit Your SPF Record
Verify all sending sources are included:
- Your mail servers (IP addresses)
- Email services (Google Workspace, Microsoft 365)
- Marketing platforms (Mailchimp, HubSpot)
- Transactional email (SendGrid, Postmark)
- Support desk systems (Zendesk, Freshdesk)
- Any other service that sends email as your domain
Step 2: Implement DMARC with p=none
Set up DMARC to collect reports:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comStep 3: Monitor Reports
Review DMARC aggregate reports for 2-4 weeks. Look for:
- Legitimate sources failing SPF
- Unknown sending sources that might be legitimate
- Patterns of spoofing attempts
Step 4: Fix Issues
Add any missing legitimate sources to your SPF record. Investigate unknown senders.
Step 5: Switch to Hardfail
Once you're confident, change ~all to -all.
Step 6: Continue Monitoring
Keep watching DMARC reports for any issues after the switch.
Common Mistakes
Starting with Hardfail
Jumping straight to -all without testing can block legitimate email. Always start with ~all and verify.
Using +all
Never use +all—it allows anyone to send email as your domain, completely defeating the purpose of SPF.
Using ?all
Neutral (?all) provides no protection. It's essentially the same as having no SPF record for unmatched senders.
Ignoring the Forwarding Issue
If your organization or recipients use email forwarding, hardfail can cause problems. Ensure DKIM is in place to cover this gap.
Quick Reference
| Scenario | Recommended |
|---|---|
| New SPF implementation |
~all (softfail) |
| Still auditing sending sources |
~all (softfail) |
| Verified all sources, no forwarding |
-all (hardfail) |
| Using DMARC enforcement | Either works; DMARC controls enforcement |
| Email forwarding is common |
~all with DKIM |
| Maximum security needed |
-all with DKIM and DMARC p=reject |
0 comments