SPF Hard Fail vs Soft Fail: Understanding -all vs ~all vs ?all

This guide breaks down the difference between SPF hard fail and soft fail, explains how each affects deliverability, and helps you choose the right setting for your domain.

💡 New to SPF or email authentication? Start with our Complete Guide to SPF, DKIM & DMARC for the basics.

Key Takeaways

• SPF fail means the sending server isn’t authorized in your SPF record. Mail servers may reject, quarantine, or mark these messages as spam. It’s a core defense against spoofing and phishing.

• Soft fail (~all) accepts mail from unauthorized sources but tags it as suspicious — often landing it in spam. Use this when rolling out SPF, mapping your legitimate senders, or testing new services.

• Hard fail (-all) tells mail servers to reject unauthorized messages entirely. Move to hard fail once your SPF record includes every valid sender to avoid blocking legitimate emails.

• Start soft, then go hard. Use soft fail during setup and transition to hard fail once your sending environment is stable. The wrong choice can lead to either excess spam or lost business emails.

• To change policies, edit your domain’s SPF TXT record in DNS and switch ~all to -all (or vice versa). Always test using an SPF checker and monitor results to confirm proper authentication.

• SPF works best with DKIM and DMARC. Together, they create a layered defense against email spoofing. Review and update your records regularly as your systems — and threats — evolve..

What Does SPF “Fail” Mean

An SPF failure means the receiving mail server couldn’t confirm that an email came from an approved source listed in your SPF record. When that happens, the server checks your SPF fail policy, either ~all (soft fail) or -all (hard fail) — to decide what to do next.

SPF (Sender Policy Framework) helps receiving mail servers verify that emails come from authorized sources. The rules for SPF are defined in RFC 7208, the official standard for SPF syntax and behavior.

If you’re seeing SPF failures already, check out our SPF Failure: Common SPF Errors & Fixes article to make sure your record itself is correct before adjusting your fail setting.

SPF Softfail (~all)

A soft fail tells mail servers, “If this sender isn’t listed, it’s probably not legitimate, but don’t reject it immediately.” Instead, the message usually passes through with a warning or gets placed in the spam folder.

Major providers like Google document this same behavior in their Workspace SPF Setup Guide, where ~all is used during initial SPF rollout to observe delivery results before enforcing stricter policies.

When to Use It

• During initial SPF setup or testing. Soft fail gives you flexibility while you confirm all legitimate senders are included.

• If you use multiple mail systems (marketing, CRM, website) and want to monitor delivery before enforcing strict rules.

• When forwarding emails frequently, since forwarding often breaks SPF alignment.

Softfail (~all) Risks

While soft fail prevents accidental bounces, it’s not strong protection. Phishers can still spoof your domain, and mail providers might treat your domain as less trustworthy.

SPF Hardfail (-all)

A hard fail tells mail servers, “Reject anything that’s not explicitly approved.” If an email comes from a server not listed in your SPF record, it will fail authentication, usually leading to outright rejection or spam quarantine.

When to Use It

• After verifying all legitimate senders. Once you know your record is complete, hard fail gives you the best protection.

• When you use DMARC. Hard fail pairs perfectly with a strict DMARC policy to stop spoofing and impersonation.

• For compliance-driven organizations that need full alignment between SPF, DKIM, and DMARC.

Once your SPF record is complete and stable, enforcing a hard fail (-all) ensures maximum protection. Major email systems like Microsoft 365 use this model to prevent spoofing and enforce sender authenticity, see Microsoft’s SPF documentation for an enterprise example of best practices.

Hardfail (-all) Risks

If your SPF record is missing a legitimate sender, or are forwarded a lot, those emails will fail, even if they’re from you. Hard fail policies require good maintenance: whenever you change providers or add tools, update your SPF record right away.

SPF Neutral (?all)

A neutral qualifier tells mail servers, “I’m not asserting anything about this sender, you decide.” When ?all is used, the SPF check technically “passes,” but without giving a clear signal of trust. It’s the equivalent of leaving SPF in observation mode.

When to Use It

• Testing and initial setup. If you’re building or auditing your SPF configuration and want to see how messages flow before enforcement.

• Parked or receive-only domains. Neutral is safe for domains that don’t send email but still need an SPF record to prevent “no SPF found” errors.

• Legacy systems and catch-alls. Some older or hybrid mail environments still rely on neutral to avoid false positives.

Neutral (?all) Risks

?all provides little to no protection against spoofing or unauthorized sending. Because it allows messages from any source to “pass” SPF, it’s not suitable for production domains. If you’re using ?all for testing, make sure to monitor delivery, then transition to ~all or -all once your record is accurate and complete.

SPF Soft Fail vs Hard Fail: Summary

Each SPF policy qualifier tells mail servers how to handle messages that don’t pass SPF checks. The difference between ~all, -all, and even ?all determines whether your messages are accepted, flagged, or rejected, and choosing the right one depends on how confident you are in your SPF configuration.

(Note: While ?all is rarely used in modern SPF configurations, it’s worth knowing for legacy compatibility.)

How to Change Your SPF Policy

Updating your SPF fail policy isn’t just about flipping a symbol, it’s about controlling how strictly your domain enforces authentication. Before you tighten your policy from ~all to -all, make sure your SPF record is complete and tested to prevent accidental email rejections.

1. Verify your current SPF record using Input Output's Email SPF Checker.

2. Confirm all legitimate senders (email host, CRM, marketing tools, etc.) are included.

3. Edit your DNS TXT record: change ~all to -all.

4. Save and test again using the same SPF Checker to confirm proper results.

5. Monitor your email flow for any new rejections or soft fails.

Best Practices for Reliable SPF Configuration

• Start soft, go hard: Begin with ~all, monitor results, and enforce -all when confident.

• Pair SPF with DKIM and DMARC: These standards work together to authenticate your domain and prevent spoofing.

• Review regularly: Anytime you add a new service that sends email, update your SPF record.

• Avoid common pitfalls: Multiple SPF records, syntax errors, or exceeding DNS lookup limits will cause failures. See our SPF Errors & Fixes Guide for details.

Conclusion and Next Steps

Before tightening your SPF policy, it’s smart to test your configuration. Run a quick scan with our SPF Checker Tool it highlights misconfigurations and lookup issues instantly.

If you want a deeper view of how SPF, DKIM, and DMARC work together, try iO™ DMARC Email Deliverability & Security Tool by Input Output for a full-domain analysis.

If you’re ready to take SPF management off your plate entirely, our iO™ DMARC email deliverability service that configures, monitors, and maintains SPF, DKIM, and DMARC for you, so your emails stay secure, compliant, and in the inbox where they belong.

Frequently Asked Questions

What is an SPF “fail” in email authentication?

An SPF fail means the sending mail server isn’t listed as an approved source in your SPF record. Mail servers treat it as suspicious and may mark, quarantine, or reject the message depending on your policy (~all for soft fail or -all for hard fail). This helps protect your domain and recipients from spoofing and phishing attempts.

🔗 Related reading: What Does It Mean If SPF Fails?

What’s the difference between SPF soft fail (~all) and hard fail (-all)?

Soft fail (~all) tells mail servers, “This sender is probably unauthorized, but let the message through with caution.” Hard fail (-all) says, “Reject anything not explicitly allowed.” Use soft fail during setup or testing and switch to hard fail once all legitimate senders are confirmed.

When should I use SPF soft fail?

Use soft fail while setting up SPF, adding new services, or auditing your email flow. It allows mail delivery but flags potential issues so you can spot missing senders before going strict.

Once your logs and SPF checker show clean results, move to hard fail for stronger enforcement.

When should I switch to SPF hard fail?

Switch to hard fail (-all) when you’re confident your SPF record includes all legitimate sending systems, your mail host, CRM, helpdesk, and marketing tools. Run a few weeks of monitoring, check DMARC aggregate reports, and then enforce hard fail to block spoofed messages.

What about SPF neutral (?all)?

Neutral (?all) tells mail servers, “I’m not making any assertion about this sender.” It’s mainly used for testing, parked domains, or receive-only mailboxes. Neutral is rarely recommended for production because it doesn’t protect against spoofing, it effectively lets all mail pass SPF checks.

How do I change my SPF policy safely?

To change your policy:

1. Verify your existing SPF record with the Input Output SPF Checker Tool.

2. Ensure all legitimate senders are included.

3. Update your DNS TXT record — change ~all (soft fail) to -all (hard fail).

4. Wait for propagation and retest.

5. Monitor logs and DMARC reports for any delivery issues.

🔗 Dive deeper: How to Setup SPF: Understanding Mechanisms, Modifiers, and Syntax

Will SPF hard fail hurt deliverability?

Not if your SPF record is accurate. In fact, it can improve deliverability by boosting your domain’s reputation. Just make sure you’ve included every legitimate sender before enforcing hard fail. Use DMARC reports and test accounts to catch any unintentional blocks early.

Is SPF enough to stop spoofing?

No single control is foolproof. SPF prevents unauthorized servers from sending on your behalf, but pairing it with DKIM (verifies message integrity) and DMARC (provides enforcement and reporting) delivers complete protection.

🔗 Dive deeper: Complete Guide to SPF, DKIM & DMARC