Should I use SPF hardfail or softfail with DMARC?

Key findings

• DMARC primacy: When DMARC is in place, its policy (none, quarantine, or reject) should ultimately dictate how an email is handled, not necessarily the SPF qualifier alone. DMARC relies on both SPF and DKIM for authentication.
• Receiver behavior: Some mailbox providers (MBPs) might immediately reject emails failing SPF with -all before even checking DKIM or DMARC. This can lead to legitimate emails being bounced.
• Forwarding issues: Email forwarding frequently breaks SPF authentication, as the mail may be relayed through an unauthorized IP address. Using -all in such cases can cause legitimate forwarded messages to fail.
• Obsolete practice: Many experts consider -all largely obsolete when DMARC is fully implemented, as DMARC's purpose is to manage unauthorized email behavior more comprehensively.

Key considerations

• Prioritise DMARC: If DMARC is configured, especially with p=quarantine or p=reject, using ~all in your SPF record typically offers a safer approach to ensure email deliverability, as it allows DMARC to evaluate both SPF and DKIM. Learn more about whether SPF hardfail should be enforced.
• Authentication chain: For a DMARC pass, either SPF or DKIM must align with the DMARC domain. Using ~all provides SPF a soft failure, allowing DKIM to potentially carry the authentication. This is crucial for handling complex email flows.
• Gradual enforcement: The M3AAWG Best Practices (Section 4) recommends using ~all as a prudent step when you are monitoring DMARC reports and before moving to a stricter DMARC policy. You can find their guidelines in their Email Authentication Recommended Best Practices document.
• Monitoring DMARC reports: Regardless of your SPF qualifier, thorough DMARC report analysis is essential to understand how different receivers are processing your emails and to identify any unexpected failures or rejections.

Key opinions

• Deliverability impact: Many marketers find that using SPF hardfail can negatively affect deliverability because some receiving mail transfer agents (MTAs) may reject messages outright based on an SPF failure, even if DMARC would otherwise pass through DKIM.
• Security vs. deliverability: There's a common misconception that hardfail is always better for security. However, with DMARC in place, the DMARC policy itself should manage the security outcome, making SPF softfail a safer choice to avoid blocking legitimate mail.
• Anecdotal evidence: Some marketers have observed actual deliverability problems, such as increased bounces or quarantined messages, when using hardfail, even with correct DMARC setup.
• SPF relaying problems: The nature of SPF makes it vulnerable to breaking during mail relaying (forwarding). Softfail mitigates this by allowing DMARC to rely on DKIM alignment for authentication.

Key considerations

• DMARC policy choice: The effectiveness of SPF -all versus ~all is heavily dependent on the p= policy set in your DMARC record. For a comprehensive overview, review when to use DMARC p=none, p=quarantine, or p=reject.
• Test thoroughly: Before committing to -all, conduct extensive testing and monitor DMARC reports to ensure deliverability isn't negatively impacted for your specific email sending patterns.
• Understand authentication flow: Marketers should have a clear understanding of how SPF, DKIM, and DMARC interact to authenticate emails. A simple guide to DMARC, SPF, and DKIM can help clarify this.
• Adapt to ecosystem: While industry best practices evolve, the email ecosystem is not uniform. Be aware that some providers may still prioritize SPF hardfail over DMARC evaluation, as discussed in communities like Spiceworks Community forums.

Key opinions

• DMARC-first approach: Experts strongly advocate for allowing DMARC to handle the policy enforcement, rather than letting an SPF hardfail prematurely reject an email that might otherwise pass DMARC via DKIM alignment. This is the core reason -all is often discouraged.
• DMARC reliance on SPF/DKIM: DMARC is built upon SPF and DKIM. If SPF hardfails too early, it can prevent the DMARC evaluation, losing the benefit of DKIM authentication. Learn why DMARC authentication can fail even when SPF and DKIM pass.
• Evolution of protocols: Some experts believe SPF, as an older technology, might eventually be deprecated or its role further diminished in favor of more robust, layered authentication systems like DMARC that account for more complex mail flows.
• Deliverability is not solved: The ongoing discussions and evolving practices around SPF, DKIM, and DMARC highlight that email deliverability remains a complex challenge, with constant new considerations and adaptations required.

Key considerations

• Avoid premature rejection: If you want to ensure both SPF and DKIM have a chance to contribute to a DMARC pass, avoid using -all in your SPF record. This is especially relevant for considerations for using soft fail versus hard fail.
• Current relevance of SPF: While DMARC provides robust policy enforcement, SPF and DKIM remain foundational. They are not being phased out, as DMARC and newer protocols like BIMI rely on their underlying authentication mechanisms.
• Complexity of the ecosystem: The email authentication landscape is constantly evolving, with discussions around new protocols and improvements to existing ones. This indicates the ongoing need for vigilant deliverability management, as highlighted by Al from SpamResource.
• Handling forwarded emails: SPF is known to break with email forwarding. Using ~all in SPF, combined with a strong DMARC policy, helps to manage DMARC failures when email is forwarded, by allowing DKIM to carry the authentication.

Key findings

• DMARC policy distribution: The DMARC RFC 7489 states that DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.
• SPF qualifiers and DMARC: Section 10.1 of the DMARC RFC acknowledges the interaction between SPF qualifiers (-all or ~all) and DMARC, particularly concerning cases where SPF fails but DKIM passes.
• Forwarding compatibility: The M3AAWG Best Practices document (Section 4) points out that SPF can be problematic with mail forwarding due to changes in the sending IP, suggesting that ~all is generally safer to prevent legitimate mail from being rejected in such scenarios.
• Future authentication: The DMARCbis draft, a proposed update to the DMARC specification, includes provisions for future authentication mechanisms to integrate with DMARC, ensuring alignment with the author domain. This indicates an evolving standard where SPF and DKIM remain core but new methods could be added.

Key considerations

• Use DMARC for policy: Documentation implies that the DMARC policy itself (p=none, p=quarantine, p=reject) is the designated tool for controlling how unauthenticated messages are handled, making the SPF qualifier less critical for final disposition if DMARC is correctly implemented.
• Facilitate DMARC pass: To allow for scenarios where SPF may fail but DKIM passes (and DMARC still aligns), using SPF ~all is the recommended approach. This ensures that a single authentication failure does not automatically reject the email. This is particularly important for managing SPF TempError in your DMARC reports.
• Consider M3AAWG guidelines: The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) emphasizes practical deployment considerations, recommending ~all for domains implementing DMARC to avoid unintended rejections and to gather comprehensive DMARC reports. Access their full Email Authentication Best Practices.
• Alignment is key: The RFC 7489 states that DMARC validation involves checking alignment between the RFC5322.From domain and the SPF/DKIM authenticated domains. This alignment is what ultimately matters for DMARC pass, irrespective of a softfail or hardfail result from SPF alone.