When setting up your Sender Policy Framework (SPF) record, one of the most common dilemmas revolves around choosing between a -all (hard fail) or a ~all (soft fail) policy. This decision isn't always straightforward, and what might seem like a minor detail can significantly impact your email deliverability and security posture. It is a nuanced choice that requires understanding how different receiving mail servers interpret these directives and how they interact with other email authentication protocols like DMARC and DKIM.
The core of the debate lies in balancing strict security with the flexibility needed for modern email ecosystems. A hard fail policy instructs receiving servers to outright reject emails from unauthorized senders, while a soft fail suggests that such emails should be accepted but marked as suspicious. Neither option is universally superior, as the best choice depends heavily on your domain's specific use cases and your overall email authentication strategy.
My goal here is to demystify these options and help you make an informed decision for your domain. We’ll explore the implications of each policy, consider common scenarios, and discuss how SPF interacts with other authentication methods to ensure your emails reach their intended recipients without unnecessary rejections or being flagged as spam.
Understanding SPF hard fail vs. soft fail begins with knowing how SPF works. SPF records are DNS TXT records that list authorized mail servers that are permitted to send email on behalf of your domain. When a recipient mail server receives an email, it checks the sender's SPF record to verify if the sending IP address is authorized.
Hard fail (-all)
A hard fail, denoted by -all at the end of your SPF record, is the most stringent policy. It explicitly tells receiving mail servers that any email originating from an IP address not listed in your SPF record should be rejected immediately. This provides a strong defense against spoofing, as unauthorized senders are prevented from delivering mail in your domain's name. However, this strictness also carries risks. If your SPF record is incomplete or incorrect, legitimate emails could be rejected, leading to significant deliverability issues.
Soft fail (~all)
Conversely, a soft fail, indicated by ~all, is a more permissive policy. It suggests that emails from unlisted IP addresses should be accepted but marked as suspicious (e.g., sent to the spam or junk folder). This is often seen as a temporary or testing measure. While it offers less direct protection against spoofing than a hard fail, it significantly reduces the risk of accidentally blocking legitimate emails, which is crucial for maintaining good sender reputation and ensuring message delivery, even for transient or unexpected sending sources.
SPF Record with Soft FailDNS
v=spf1 include:_spf.example.com ~all
Choosing between these two qualifiers boils down to your domain's specific needs, your confidence in your SPF record's accuracy, and whether you are deploying DMARC policies.
When to use SPF hard fail (-all)
There are specific scenarios where using SPF hard fail (-all) is the appropriate choice. This is typically when you have absolute confidence in your SPF record and desire maximum protection against unauthorized email sending.
Domains that don't send email
If a domain is not intended to send any email, such as a parked domain or a domain used exclusively for web hosting, setting an SPF record with -all is a robust security measure. This immediately tells any receiving server that no mail should ever originate from this domain, and any such attempt is spoofing. This configuration is highly effective in preventing misuse of such domains for malicious purposes.
SPF Record for Non-Sending DomainDNS
v=spf1 -all
Domains with stable, predictable sending infrastructure
For organizations with very stable and well-known email sending infrastructure, a hard fail can be considered. This includes domains that use a limited number of dedicated email service providers and have a rigorous process for updating their SPF records whenever a new sender is added. In such controlled environments, the risk of legitimate emails being rejected due to an incomplete SPF record is minimal, and the benefit of strong anti-spoofing protection is maximized. However, this level of confidence is rare for most businesses with evolving email needs.
When to use SPF soft fail (~all)
For most active sending domains, using SPF soft fail (~all) is generally recommended. It offers a balance between security and deliverability, especially in dynamic email environments.
During initial SPF deployment or changes
When you are first setting up an SPF record or making significant changes to your email sending infrastructure (e.g., adding a new ESP), starting with ~all is crucial. This allows you to monitor the impact of your SPF record without the risk of legitimate emails being outright rejected. You can then progressively move to a stricter policy once you are confident that all your legitimate sending sources are correctly included. This phased approach helps to resolve SPF softfail errors and prevent disruptions.
Complex or evolving email infrastructures
Many organizations use multiple email service providers (ESPs), transactional email platforms, and internal mail servers. In such complex setups, maintaining an exhaustive and always up-to-date SPF record with -all can be challenging. A soft fail policy provides a safety net, allowing emails from new or transient legitimate sources to still be delivered, albeit with a possible spam flag. This flexibility is vital for preventing temporary SPF alignment failures from causing outright rejections and impacting email deliverability. It's also important to note SPF records should not exceed the 10 DNS lookup limit, which can be more easily managed with SPF flattening.
The role of DMARC in your decision
The conversation around SPF hard fail versus soft fail changes significantly when DMARC (Domain-based Message Authentication, Reporting, and Conformance) is deployed. DMARC builds upon SPF and DKIM to provide a comprehensive email authentication policy and reporting mechanism.
DMARC and SPF alignment
With DMARC, the key is alignment. For an email to pass DMARC based on SPF, the domain in the SPF MAIL FROM (also known as the Return-Path or Envelope From) must align with the domain in the From header that users see. If this alignment holds, and SPF passes, then DMARC considers the email legitimate. The SPF qualifier (-all or ~all) becomes less critical for final delivery policy once DMARC is in enforcement mode (e.g., p=quarantine or p=reject). In these cases, DMARC's policy will dictate the action taken, overriding SPF's individual -all or ~all directive.
Many email deliverability experts and industry bodies, such as the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), now recommend ~all in SPF records for domains that also publish a DMARC record. The reasoning is that DMARC is the policy layer that should be making the final decision on how to handle emails that fail authentication. An SPF hard fail (-all) can lead to legitimate emails being rejected early in the mail transaction, even before DMARC or DKIM can be fully evaluated. This is especially true for messages that pass through mail forwarders, which often break SPF. With DMARC in place, the security benefits of -all are largely redundant, and the risks to deliverability are amplified. You can learn more about this perspective from Al Iverson's insights on SpamResource.
Therefore, if you are using DMARC, particularly with a p=quarantine or p=reject policy, using SPF ~all is often the more pragmatic and safer approach for your email deliverability. This allows DMARC to be the primary enforcement mechanism, leveraging its reporting capabilities to identify and address any legitimate mail streams that are not yet authenticated.
Considering your domain's needs
Hard fail risks
Rejection risk: Legitimate emails from unlisted IPs (e.g., mail forwarders) can be outright rejected before DMARC or DKIM evaluation.
Deliverability impact: Higher chance of legitimate emails failing to reach the inbox, leading to lost communications.
Maintenance burden: Requires meticulous and constant updates to the SPF record to include all sending sources.
When hard fail is suitable
Non-sending domains: Ideal for domains that should never send email, like parked or purely web-hosting domains.
Highly controlled environments: Only when you are 100% certain of all sending IPs and can consistently update your record.
Soft fail benefits
Reduced rejections: Minimizes the risk of blocking legitimate emails, improving overall deliverability rates.
Flexibility: Accommodates dynamic sending environments, including third-party senders and mail forwarders.
Better with DMARC: Allows DMARC to be the primary enforcement mechanism, leveraging its comprehensive reporting.
When soft fail is suitable
Active sending domains: Recommended for most domains that send email, especially with diverse sending sources.
Testing and deployment: Ideal when initially setting up SPF or making changes to minimize disruption.
When choosing your SPF policy, consider your overall email security strategy. Are you relying solely on SPF, or do you have DMARC in place? With DMARC, a soft fail SPF provides flexibility, allowing DMARC to manage the policy for failed emails.
Also, think about your domain's sending patterns. If you use many different services to send email, a hard fail can lead to legitimate emails being marked as spam or rejected outright if you miss an IP. If your sending environment is constantly changing, soft fail offers more resilience.
Ultimately, the right choice is the one that best supports your email deliverability goals while providing adequate protection against unauthorized sending. For most businesses today, especially those using DMARC, soft fail is often the more practical and safer approach.
Views from the trenches
Best practices
Use SPF soft fail (~all) if you have DMARC implemented, as DMARC should handle the policy for failed authentication.
Always monitor your DMARC reports to identify legitimate email sources that are not yet correctly covered by your SPF record.
For domains that send no email, use SPF hard fail (-all) to explicitly block any unauthorized sending attempts.
Common pitfalls
Using SPF hard fail (-all) without DMARC can lead to legitimate emails being rejected, especially if sent via mail forwarders.
Not regularly updating your SPF record when adding new sending services, regardless of hard or soft fail policy.
Over-relying on SPF alone for email authentication without also implementing DKIM and DMARC for comprehensive protection.
Expert tips
SPF hard fail can increase the risk of rejection before DKIM and DMARC are evaluated.
A well-configured DMARC policy, especially in enforcement mode, renders the strictness of SPF hard fail largely redundant.
Even if SPF fails, DMARC can still pass if DKIM aligns, providing a safety net for deliverability.
Expert view
Expert from Email Geeks says SPF hard fail carries a risk that messages might be rejected early in the transaction, preventing DKIM and DMARC evaluation.
2024-05-01 - Email Geeks
Marketer view
Marketer from Email Geeks says they have experienced issues with hard fail previously, but never with soft fail.
2024-05-02 - Email Geeks
Making the right choice for your domain
The choice between SPF hard fail and soft fail is a critical one for your email security and deliverability. While hard fail provides the strictest enforcement against unauthorized sending, its rigidity can sometimes lead to legitimate emails being rejected, especially in complex or evolving email environments, or when mail is forwarded. Soft fail, on the other hand, offers more flexibility and is generally recommended for active sending domains, particularly when combined with DMARC. DMARC serves as the primary policy layer, allowing you to define how receiving servers should handle emails that fail authentication while providing valuable reporting to fine-tune your configuration. Ultimately, the best practice involves carefully assessing your domain's specific needs and leveraging a comprehensive email authentication strategy that includes SPF, DKIM, and DMARC to ensure optimal deliverability and protection against spoofing.
