When should I use SPF hard fail vs soft fail?

Key findings

• Strictness: SPF hard fail (-all) explicitly instructs receiving servers to reject mail that originates from an unauthorized IP address, offering maximum control against spoofing for the specified domain. In contrast, soft fail (~all) suggests that mail from unauthorized sources should be accepted but marked as suspicious.
• DMARC interaction: Hard fail carries a risk of messages being rejected early in the transaction, potentially before DKIM and DMARC policies can be evaluated. If DMARC passes but SPF fails, it can impact deliverability, making the SPF choice significant.
• Mail flow considerations: Soft fail is generally safer for domains with complex or evolving email infrastructures, especially those involving indirect mail flows like forwarding, which can legitimately break SPF alignment.
• Primary policy enforcement: When DMARC is implemented, it typically takes precedence in defining the ultimate policy for email authentication failures. SPF then acts as a contributing signal to DMARC.

Key considerations

• Risk tolerance: Hard fail offers strong control but poses a higher risk of blocking legitimate emails if your SPF record is incomplete or if mail passes through forwarders. Soft fail mitigates this risk.
• Deployment and testing: During initial SPF implementation or significant changes to your sending infrastructure, soft fail is often recommended. This allows you to monitor mail flow and identify any legitimate sending sources not yet included in your SPF record without causing rejections. More on understanding SPF soft fail and hard fail use cases can be found on AutoSPF's blog.
• Non-sending domains: For domains that are explicitly not used for sending email, a hard fail policy (v=spf1 -all) is a secure and recommended practice to prevent spoofing.
• Receiver behavior: The enforcement of SPF policies, particularly hard fail, can vary significantly among mailbox providers. Some may not strictly reject messages based solely on SPF failure, especially if other authentication methods like DKIM pass. If you're encountering intermittent email delivery failures caused by SPF, this could be a factor.

Key opinions

• Advocacy for hard fail: Some marketers prefer hard fail to provide mailbox providers with a firm, unambiguous instruction, aiming for immediate rejection of unauthorized mail and desiring clear policies for their clients if mail fails SPF.
• Soft fail reliability: Other marketers report experiencing fewer issues with soft fail, noting that unexpected rejections have occurred with hard fail in the past, suggesting that not many providers consistently enforce hard fail.
• Situational choice: Many agree that hard and soft fail serve different purposes, and one is not objectively superior. The choice depends on confidence in the SPF record and specific domain use, such as using v=spf1 -all for non-sending domains and ~all for sending domains.
• DMARC's role: There's a strong sentiment that DMARC should be the primary policy layer for email authentication, given its data-driven approach and situational awareness, rather than relying solely on SPF to make definitive decisions.

Key considerations

• Real-world enforcement: Despite the stated policy, the actual enforcement of SPF hard fail by large receivers is often inconsistent, leading to varied deliverability experiences. This is a key factor when considering whether to use SPF hard fail or soft fail with DMARC.
• Trade-offs and risk management: Marketers must weigh the trade-offs between strict security and potential deliverability issues. The decision is a calculation of benefits versus risks, where soft fail is often considered best practice except in specific use cases.
• Security audit findings: Security auditing companies may flag SPF soft fail, even if it's appropriate for the domain's configuration, which necessitates a clear understanding of the 'why' to navigate these findings. For more information, read GodMARC's perspective on SPF hard fail vs soft fail.
• Persuasion and education: Framing the discussion around trade-offs rather than absolute right or wrong is key for productive discussions and helping stakeholders understand the implications of SPF policy changes on why emails are going to spam.

Key opinions

• Early rejection risk: SPF hard fail comes with the inherent risk that an email may be rejected early in the SMTP transaction, preventing later authentication checks like DKIM and DMARC from occurring.
• Interdependence of protocols: The effectiveness and choice between hard and soft fail largely depend on whether a domain relies on DMARC or DKIM for comprehensive email authentication.
• Impact of mail forwarding: Indirect mail flows, especially email forwarders, can legitimately cause SPF to fail for otherwise valid messages. Experts generally prefer soft fail to avoid rejecting such mail.
• Receiver enforcement: There's an ongoing discussion and some skepticism regarding whether large mailbox providers reliably block emails based solely on an SPF hard fail, as precise data is difficult to acquire.

Key considerations

• Authentication order: Be aware that DKIM and DMARC evaluations typically occur after the message body is transmitted, meaning an SPF hard fail can cause rejection before these deeper checks are performed. This affects whether SPF hardfail should be enforced if DMARC is in place.
• Specific use cases for hard fail: Hard fail is generally appropriate only for domains that send no email at all (using v=spf1 -all) or for domains explicitly used only in direct mail flows where the owner accepts potential rejections from intermediate hops.
• Soft fail as best practice: For most active sending domains, ~all is considered the safest and most robust practice to accommodate the complexities of global mail routing and forwarding. More on this topic is available on the Spamresource blog, Ask Al.
• Data collection difficulty: It is challenging to definitively ascertain how frequently large mail providers block purely due to SPF hard fail, making the decision sometimes reliant on theoretical risks and observed deliverability patterns. This is part of the broader issue of troubleshooting SPF and DNS issues.

Key findings

• Recommended default: The M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) Email Authentication Recommended Best Practices document (September 2020) explicitly recommends the use of ~all (soft fail) in SPF records for active sending domains.
• Receiver behavior for hard fail: Documentation often advises that receiving mail servers should avoid rejecting messages too early, specifically at the MAIL FROM stage, even with an SPF -all policy, unless the record is simply v=spf1 -all (indicating a non-sending domain).
• Flexibility vs. strictness: Official guidelines prioritize flexibility in SPF to prevent legitimate emails from being incorrectly blocked due to the nature of email forwarding and complex mail paths.
• Integration with DMARC: The documentation implies that SPF should be viewed as one component of a broader email authentication strategy, where DMARC provides the overarching policy enforcement layer.

Key considerations

• Adherence to standards: Following recommendations from bodies like M3AAWG helps ensure compatibility and optimize email deliverability across the internet. This aligns with considerations for using soft fail vs hard fail.
• Understanding early rejections: While many modern receivers follow the spirit of these recommendations, it is still possible for some legacy systems to perform early rejections with a hard fail policy.
• Complementary role: SPF's role is to identify authorized sending sources, but DMARC is critical for defining the policy (e.g., quarantine or reject) based on SPF and DKIM alignment results. This is key for improving email deliverability.
• Accessing resources: Referencing documents like the M3AAWG Email Authentication Recommended Best Practices provides comprehensive guidance for secure and effective email practices.