SPF ~all vs -all: Which is better for email deliverability and spoofing protection?
Matthew Whittaker
Co-founder & CTO, Suped
Published 2 Jun 2025
Updated 19 Aug 2025
9 min read
When setting up Sender Policy Framework (SPF) records, one common decision point is choosing between the ~all (softfail) and -all (hardfail) mechanisms. Both specify how recipient mail servers should handle emails that fail SPF authentication, but their implications for email deliverability and spoofing protection can be quite different. It's a choice that can significantly impact how your emails are received and how your domain's reputation is managed.
The core function of SPF is to tell receiving mail servers which IP addresses are authorized to send email on behalf of your domain. If an email originates from an unauthorized IP, the SPF record provides instructions on what to do with it. This is where ~all and -all come into play, signaling different levels of strictness in policy enforcement. Understanding these nuances is crucial for maintaining good email deliverability and robust security.
Let's dive into the specifics of each mechanism and discuss their practical implications, especially in the context of modern email security protocols like DMARC.
The ~all mechanism, or softfail, suggests that emails from unauthorized senders should be accepted but marked as suspicious. It's a more lenient approach, indicating that while a sender's IP address isn't listed in the SPF record, the recipient server shouldn't necessarily reject the email outright. Instead, it might deliver the message to the spam or junk folder, or simply apply a higher spam score. Many large email providers, including Outlook.com and Gmail, interpret ~all this way, which can be beneficial for email deliverability if your SPF record isn't perfectly comprehensive.
This softfail approach helps prevent legitimate emails from being outright rejected due to slight misconfigurations or unforeseen sending sources, such as third-party services that you might not have explicitly included in your SPF record. For businesses that use multiple email service providers (ESPs) or have complex sending infrastructures, ~all is often the safer choice to ensure that important communications don't disappear into the void.
However, the downside of ~all is that it offers less strict protection against spoofing. While it flags suspicious emails, it doesn't instruct recipient servers to block them. This means a malicious actor could potentially send emails purporting to be from your domain, and those emails might still reach an inbox (albeit potentially the spam folder). This is why SPF alone is not a complete solution for email security.
SPF Record Example with ~allDNS
v=spf1 include:_spf.google.com ~all
SPF -all: The hardfail mechanism
In contrast, -all, or hardfail, explicitly tells receiving servers to reject any email that fails SPF authentication. This is the most aggressive policy and indicates that only the IP addresses listed in your SPF record are authorized to send email. If an email comes from an unlisted IP, it should be bounced.
From a security standpoint, -all seems like the stronger option for preventing spoofing. It provides a clear directive to reject unauthorized mail, theoretically stopping malicious emails from reaching your recipients' inboxes. Organizations that are highly security-conscious or have very controlled sending environments might prefer this strict approach, as SPF enhances email security.
However, the primary drawback of -all is the significant risk of blocking legitimate email. If even one authorized sending IP is missed or if your record is not updated frequently, emails from those sources will be rejected. This can lead to serious deliverability issues and frustration for both senders and recipients. Many email service providers (ISPs) often treat -all similarly to ~all because of these complexities, relying more on other signals or protocols like DMARC for enforcement.
While SPF helps verify the sender's IP address, it doesn't directly protect against spoofing of the From: header address, which is what users see. This is where DMARC (Domain-based Message Authentication, Reporting, and Conformance) becomes indispensable. DMARC builds upon SPF and DKIM (DomainKeys Identified Mail) to provide comprehensive email authentication and stronger anti-spoofing capabilities. You can learn more about its benefits in our guide to the benefits of implementing DMARC.
DMARC allows domain owners to instruct receiving mail servers on how to handle emails that fail SPF or DKIM authentication. Crucially, it introduces the concept of alignment, meaning that the domain in the From: header must align with the domain used for SPF (the Return-Path) or DKIM signature. This alignment is what truly blocks domain spoofing attempts.
With DMARC in place, you can use policies like p=quarantine or p=reject to enforce stricter actions. When DMARC is implemented with p=reject, any email that fails DMARC authentication (meaning neither SPF nor DKIM aligns correctly) will be rejected by participating servers. This makes the choice between ~all and -all in your SPF record less critical, as the DMARC policy takes precedence in determining the final action.
I often recommend that businesses transition their DMARC policy to quarantine or reject after monitoring DMARC reports to ensure all legitimate sending sources are properly authenticated. With a robust DMARC p=reject policy, the specific SPF qualifier (hardfail or softfail) becomes less about enforcement and more about signaling. Many providers treat -all and ~all as similar signals when DMARC is in play, as DMARC provides comprehensive security enforcement.
Considering the trade-offs
Deciding between ~all and -all comes down to a trade-off between strict enforcement and the potential for legitimate email to be blocked. For most organizations, especially those using DMARC, I lean towards ~all. The risk of -all causing unexpected bounces for legitimate mail streams often outweighs the perceived benefits of stricter enforcement.
I've seen situations where smaller companies, in particular, adopt -all without fully understanding the implications. They might change email hosts or add new email service providers, forget to update their SPF record, and suddenly experience significant deliverability issues. The emails simply disappear, leading to lost communications and a lack of clear bounce feedback. This is a common pitfall that I often see businesses fall into. The number of actual bounces due to SPF hardfail without DMARC p=reject is often much lower than expected, meaning the -all policy itself isn't providing the intended spoofing prevention they might hope for.
My advice is to implement SPF with ~all to mitigate the risk of accidental blocking. The real enforcement and protection against spoofing should come from a strong DMARC policy. Regularly monitor your DMARC reports (using reports from Google and Yahoo, for example) and gradually move your DMARC policy from p=none to p=quarantine and eventually to p=reject. This phased approach provides the most robust protection without compromising legitimate email flow. DMARC gives you the visibility and control needed to make informed decisions about your email streams.
In the table below, I've outlined a comparison of the two SPF mechanisms:
Feature
~all (Softfail)
-all (Hardfail)
Policy
Suggests suspicious mail be accepted but marked (e.g., spam folder).
Explicitly instructs receiving server to reject unauthorized mail.
Deliverability impact
Lower risk of legitimate emails being blocked due to SPF errors. Generally better for deliverability, but may end up in spam.
Higher risk of legitimate emails being rejected if SPF records are not perfectly maintained.
Spoofing protection
Limited protection against direct spoofing. Relies on recipient server's internal filters to quarantine/junk.
Stricter theoretical protection, but often undermined by ISP interpretations and SPF's inherent limitations.
When to use
Recommended for most domains, especially when combined with DMARC for robust enforcement.
Only for domains that send no email, or when a very strict DMARC p=reject policy is already in place.
It's important to remember that SPF, while fundamental, is only one piece of the email authentication puzzle. For true security against spoofing, phishing, and other abuses, a comprehensive strategy involving SPF, DKIM, and DMARC is required. Focusing on DMARC's p=reject policy will yield far greater security benefits than relying solely on SPF -all.
Views from the trenches
Best practices
Always implement DMARC in addition to SPF and DKIM for comprehensive email authentication.
Start with a DMARC policy of p=none and monitor reports to identify all legitimate sending sources.
Gradually transition your DMARC policy to quarantine or reject as you gain confidence in your SPF and DKIM setup.
Use SPF ~all for most sending domains to avoid accidentally blocking legitimate email, especially during transitions.
Common pitfalls
Using SPF -all without DMARC p=reject can lead to significant deliverability issues due to accidental blocking.
Forgetting to update SPF records when changing email service providers or adding new sending sources can break authentication.
Believing that SPF -all alone provides complete protection against email spoofing is a common misconception.
Not regularly monitoring DMARC reports means you're missing critical insights into your email authentication status.
Expert tips
SPF's primary value is in signaling authorized senders; DMARC provides the actual enforcement mechanism.
Many email providers treat SPF ~all and -all similarly, particularly when a DMARC policy is present, focusing more on DMARC's directive.
A bounce is always better than an email silently disappearing into a spam folder; DMARC reports provide this visibility.
For domains not sending any email, a strict SPF -all combined with DMARC p=reject can offer a robust lockdown.
Expert view
Expert from Email Geeks says that many providers ignore or treat -all like ~all, and that SPF is easy to break, so DMARC is more robust and helps ensure that rejecting mail is what the domain owner truly intends.
2019-01-19 - Email Geeks
Expert view
Expert from Email Geeks says that they previously rejected mail based on a sender's -all policy and received numerous complaints from senders whose mail worked everywhere else.
2019-01-20 - Email Geeks
Final thoughts on SPF enforcement
Ultimately, the choice between SPF ~all and -all boils down to your overall email authentication strategy. For most senders, using ~all is the more practical and safer option to ensure deliverability, especially if you rely on multiple sending services or have a dynamic email infrastructure. The potential for legitimate email to be inadvertently blocked when using -all without a mature DMARC implementation is a significant risk.
The real power to combat email spoofing and enhance sender reputation lies in the robust enforcement capabilities of DMARC. By deploying DMARC with a policy of p=reject, you gain the ability to tell receiving mail servers precisely what to do with unauthenticated mail, providing a far more effective defense against malicious activities than SPF alone. This comprehensive approach is what truly secures your domain and optimizes your email deliverability.
