Understanding SPF Fail Mechanisms: The Critical Choice
For a domain that actively sends email, use ~all (soft fail) together with a DMARC policy of p=quarantine or p=reject; reserve -all (hard fail) for parked domains that never send mail. The counterintuitive part is that the more "lenient" ~all gives you the same anti-spoofing strength as -all once DMARC is enforcing, because DMARC does not distinguish soft fail from hard fail when it decides to reject — it only cares whether SPF or DKIM aligned and passed. Meanwhile ~all keeps legitimate forwarded mail alive long enough for DKIM to rescue it, which -all can kill before verification even happens.
That is the summary an AI Overview will give you. Here is what it can't show you: the actual decision tree by scenario, a side-by-side comparison of every SPF qualifier, and the exact record syntax for each case. The rest of this guide walks through when each qualifier is right, why forwarding is the deciding factor, and how the ~all + DMARC + DKIM stack actually behaves at the receiver.
When configuring your SPF (Sender Policy Framework) record, one of the most important decisions you'll make is choosing the final mechanism that determines what happens to emails that don't match any of your authorized senders. This choice comes down to two options: "-all" (hard fail) or "~all" (soft fail). While they might seem similar, this small syntax difference has significant implications for your email security and deliverability.
The mechanism you choose appears at the end of your SPF record and tells receiving mail servers how strictly to enforce your sending policy. This decision affects not only your security posture but also the likelihood that your legitimate emails will be delivered successfully, especially in edge cases like email forwarding or when using new sending services.
SPF Qualifiers at a Glance
Every mechanism in an SPF record can carry one of four qualifiers. The all mechanism at the end of your record is where the qualifier matters most, because it decides the fate of every sender you did not explicitly authorize.
| Qualifier | Name | Receiver action on a non-match | Use it when |
|---|---|---|---|
+all | Pass | Accept everything — authorizes the whole internet to send as you | Never. This disables SPF entirely. |
?all | Neutral | No assertion; receiver decides | Rarely — only during very early testing |
~all | Soft fail | Accept but mark suspicious; mail continues to DKIM/DMARC | Recommended for any active sending domain paired with DMARC |
-all | Hard fail | Reject the message outright | Parked / non-sending domains, or a fixed single-IP sender |
Which should you use? For a domain that sends email, ~all with DMARC at quarantine or reject. For a domain that sends no email, -all. Everything else is a corner case.
What Is Hard Fail (-all)?
Hard fail, denoted by "-all" in your SPF record, is the strictest SPF policy you can implement. It explicitly instructs receiving mail servers to reject any email that comes from an IP address or server not listed in your SPF record. When an email fails SPF authentication with a hard fail policy, the receiving server should treat it as unauthorized and typically reject it outright.
In practice, this means emails from servers not authorized in your SPF record will be deleted or bounced back without reaching the recipient's inbox. The hard fail policy sends a clear, unambiguous message: "If this email didn't come from one of my authorized servers, it's not from me—reject it."
This approach provides the strongest protection against email spoofing and domain impersonation. Attackers attempting to send fraudulent emails pretending to be from your domain will have their messages blocked at the recipient's mail server, assuming that server enforces SPF checks. For organizations with strict security requirements, this level of protection can be appealing.
However, hard fail comes with significant risks for legitimate email delivery. If you accidentally omit an authorized sending server from your SPF record, legitimate emails from that server will be rejected. This can happen when you set up a new email service, when third-party vendors send emails on your behalf, or during email forwarding scenarios.
What Is Soft Fail (~all)?
Soft fail, denoted by "~all" in your SPF record, takes a more lenient approach. It tells receiving mail servers that emails from unauthorized sources should be accepted but marked as suspicious. The soft fail essentially says, "This email probably isn't authorized, but don't reject it—let me know about it instead."
In practice, emails that fail SPF with a soft fail policy are typically delivered but flagged for additional scrutiny. They might be placed in the spam or junk folder, marked with a warning, or subjected to additional filtering rules. The key difference from hard fail is that the email still has a chance of being delivered and reviewed rather than being outright rejected.
Soft fail provides a safety net during SPF implementation and maintenance. If you forget to include a legitimate sending source in your SPF record, emails from that source won't be completely blocked—they'll just face additional scrutiny. This gives you time to identify and fix the omission before legitimate communications are lost.
The soft fail approach is particularly valuable when combined with DMARC and DKIM, as we'll discuss later. It allows you to maintain strong security while avoiding the delivery pitfalls that can come with hard fail.
The Modern Consensus: Soft Fail for Active Domains
The email security community has largely reached a consensus: for domains that actively send email, soft fail (~all) combined with a strict DMARC policy is the recommended approach. This might seem counterintuitive—why not use the strictest policy available? The answer lies in how modern email authentication actually works in practice.
When you use soft fail in combination with DMARC set to quarantine or reject, you get the same security benefits as hard fail while avoiding its major pitfalls. With DMARC, an email is either SPF aligned or SPF unaligned, regardless of whether you use hard fail or soft fail. DMARC doesn't distinguish between the two fail modes when making its authentication decision.
The critical advantage of soft fail becomes apparent when DKIM is also in the picture. DMARC passes if either SPF or DKIM aligns and passes. If you use hard fail and a legitimate email fails SPF (perhaps due to forwarding), some email systems may reject it before DKIM verification even occurs. With soft fail, the email proceeds to DKIM verification, and as long as DKIM passes and aligns, DMARC will pass and the email will be delivered.
This is why major email security providers and consultants, including Valimail and Mailhardener, recommend soft fail for domains that send email. It provides the same security properties as hard fail when used with DMARC, without sacrificing deliverability in edge cases.
When to Use Hard Fail (-all)
While soft fail is recommended for most active email-sending domains, there are specific scenarios where hard fail is the appropriate choice. The primary use case is for domains that don't send email at all—parked domains, domains used only for website hosting, or placeholder domains.
For these non-sending domains, using hard fail provides an extra layer of protection against phishing and spoofing attacks. Since no legitimate email should ever come from these domains, you can safely tell the world to reject anything claiming to be from them. In this case, there's no risk of blocking legitimate email because no legitimate email exists.
Another scenario where hard fail might be considered is when you have complete confidence in your SPF record's accuracy and a very simple, static sending infrastructure. If you only send email from a single, fixed IP address that never changes and you never use third-party services, hard fail's risks are minimized. However, even in these cases, soft fail with DMARC provides equivalent protection with better resilience to future changes.
The Email Forwarding Problem
One of the most significant issues with SPF, particularly when using hard fail, is email forwarding. When an email is forwarded, the SPF check at the final destination typically fails because the forwarding server's IP address isn't listed in the original sender's SPF record. This is simply how SPF works—it validates based on the sending IP, which changes during forwarding.
With hard fail, forwarded emails may be rejected entirely, preventing legitimate communications from reaching their intended recipients. This affects mailing lists, auto-forwarding rules, and any scenario where email passes through an intermediate server.
Soft fail mitigates this problem by allowing forwarded emails to be delivered, even if they're flagged for additional review. When combined with DKIM (which can survive forwarding intact), the email can still authenticate via DMARC and be delivered properly.
This forwarding issue is one of the strongest arguments for using soft fail rather than hard fail. Unless you're certain your emails will never be forwarded (a nearly impossible guarantee), soft fail provides important flexibility.
DMARC Reporting and SPF Monitoring
Another advantage of using soft fail relates to DMARC reporting. When you use hard fail, emails that fail SPF may be rejected before the DMARC authentication process completes. This means you might not receive DMARC reports for those emails, leaving you blind to potential issues with your SPF configuration.
With soft fail, emails proceed through the full authentication process, generating DMARC reports that help you identify SPF failures and their causes. This visibility is crucial for maintaining healthy email authentication and identifying legitimate sending sources that you may have forgotten to include in your SPF record.
Regular monitoring of DMARC reports allows you to spot patterns, identify misconfigured or unauthorized sending sources, and make informed decisions about your email authentication policies. This monitoring capability is essential for any organization serious about email security.
Implementation Best Practices
When implementing your SPF policy, follow these best practices to ensure both security and deliverability. Start with a comprehensive inventory of all systems and services that send email on your behalf. This includes obvious sources like your email server, but also less obvious ones like marketing automation platforms, help desk systems, notification services, and any third-party applications that send email using your domain.
Begin with soft fail (~all) even if you eventually plan to move to hard fail. Monitor your DMARC reports for several weeks or months to ensure you've caught all legitimate sending sources. This observation period is crucial for identifying edge cases and services you might have forgotten about.
If you're using DMARC (which you should be), configure it with a policy of quarantine or reject to achieve the security benefits of hard fail while maintaining the deliverability advantages of soft fail. This combination is currently considered best practice by email security experts.
Keep your SPF record within the 10 DNS lookup limit to avoid SPF failures due to too many includes. Use SPF flattening or IP address lists when necessary to stay under this limit.
Document your SPF record and maintain a list of all authorized sending sources. This documentation helps when troubleshooting issues and ensures continuity when team members change.
The Verdict: Soft Fail for Most Organizations
For the vast majority of organizations, soft fail (~all) combined with a strict DMARC policy represents the optimal balance between security and deliverability. This approach provides robust protection against spoofing and phishing while avoiding the edge-case delivery problems that can plague hard fail implementations.
Hard fail should be reserved for domains that never send email, where the risk of blocking legitimate messages doesn't exist. For all other cases, the modern email authentication stack of SPF with soft fail, DKIM, and DMARC at quarantine or reject provides enterprise-grade security without compromising legitimate email delivery.
Remember that email authentication is not a set-it-and-forget-it configuration. Regular monitoring of DMARC reports, periodic reviews of your sending infrastructure, and staying current with email authentication best practices are essential for maintaining both security and deliverability. By choosing soft fail and implementing comprehensive email authentication, you position your organization for secure, reliable email communications.