Should SPF hardfail be enforced if DMARC is already in place?

No, if DMARC is properly implemented and enforced, SPF hardfail is generally not recommended. DMARC's policy (p=quarantine or p=reject) dictates the action for authentication failures, and its OR logic means a DKIM pass can override an SPF fail. Using SPF softfail (`~all`) is often preferred to allow DMARC to fully evaluate.

What is the difference between SPF softfail and hardfail?

SPF softfail (`~all`) suggests that an email from an unauthorized server should be accepted but marked as suspicious, often resulting in delivery to the spam folder. SPF hardfail (`-all`) explicitly states that such emails should be rejected outright at the SMTP level. With DMARC, softfail is generally recommended as it allows the email to proceed for DMARC and DKIM evaluation.

Can an email still pass DMARC if its SPF record fails?

Yes, an email can pass DMARC even if SPF fails, provided that DKIM passes and is aligned with the From: domain. DMARC uses an OR logic, meaning only one of the two (SPF or DKIM) needs to pass authentication and alignment for the DMARC check to succeed.

How does email forwarding affect SPF and DMARC?

When an email is forwarded, the originating IP address typically changes, which often causes the SPF check to fail. However, DKIM signatures usually remain intact during forwarding. This is why DMARC's reliance on either SPF or DKIM is beneficial, as it allows forwarded, legitimate emails to still pass authentication via DKIM.

Should SPF hardfail be enforced if DMARC is in place? - Technical - Email deliverability - Knowledge base

Q: Why is DMARC considered the primary policy layer for email authentication?

DMARC is crucial because it adds a policy layer to SPF and DKIM. It tells receiving servers what to do with emails that fail authentication and provides domain owners with aggregated reports on their email traffic, offering visibility into spoofing attempts and legitimate sending issues.

For years, SPF (Sender Policy Framework) has been a cornerstone of email authentication. Its primary function is to allow domain owners to specify which mail servers are authorized to send email on their behalf. When an email arrives, the receiving server checks the SPF record to verify if the sending IP address is listed as legitimate. If it's not, the SPF record's mechanism, specifically -all (hardfail) or ~all (softfail), determines the suggested action.

However, the landscape of email security evolved significantly with the introduction of DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC builds upon SPF and DKIM (DomainKeys Identified Mail) by adding a policy layer and reporting capabilities. It tells receiving servers what to do with emails that fail authentication and provides domain owners with feedback on their email traffic.

This leads to a common question for many domain administrators and email marketers: if DMARC is already in place and actively enforcing policies, is it still necessary, or even advisable, to use an SPF hardfail (`-all`)? The answer is nuanced, and understanding the interplay between these protocols is crucial for maintaining good email deliverability and preventing spoofing.

Suped DMARC monitoring

Free forever, no credit card required

Learn more

Trusted by teams securing millions of inboxes

Understanding SPF hardfail and DMARC

To grasp why SPF hardfail might not be necessary with DMARC, we need to understand how these three protocols—SPF, DKIM, and DMARC—function together. SPF verifies the sender's IP address against a list of authorized sending servers in the DNS record. DKIM uses cryptographic signatures to ensure that an email's content has not been tampered with in transit and that it originates from an authorized domain. DMARC, then, acts as the policy layer, instructing receiving mail servers how to handle emails based on the SPF and DKIM authentication results, specifically requiring domain alignment. For a deeper dive into their combined workings, explore a simple guide to DMARC, SPF, and DKIM.

A crucial aspect of DMARC is its OR logic. For an email to pass DMARC authentication, it only needs to pass either SPF or DKIM alignment. This means that if an email fails SPF but passes DKIM (and both align with the From: domain), it will still pass DMARC. Many email service providers (ESPs) and Mailbox Providers (MBPs) prioritize this DMARC verdict. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) even states that a DMARC pass overrides an SPF fail verdict. This is a significant point, as it suggests that relying solely on SPF hardfail becomes less relevant once DMARC is in play, particularly when DKIM is also configured.

In essence, SPF hardfail (`-all`) implies that any server not explicitly listed in the SPF record is unauthorized to send email for that domain, and mail from such servers should be rejected. In contrast, SPF softfail (`~all`) suggests that while a server is not authorized, the email should still be accepted but marked as suspicious. With DMARC in place, the specific SPF mechanism (hardfail or softfail) loses some of its direct enforcement power, as the DMARC policy will ultimately dictate the email's fate. If you're wondering what happens when DMARC passes but SPF fails, remember the OR logic.

SPF all mechanisms

The all mechanism in an SPF record defines how receiving servers should treat emails from unauthorized sources. There are two primary qualifiers for all.

Hardfail (-all): This mechanism explicitly states that any server not listed in the SPF record is not authorized to send email for the domain. It suggests that such emails should be rejected immediately at the SMTP level.
Softfail (~all): This indicates that while the server is likely not authorized, the receiving server should still accept the email, but treat it with suspicion. It often results in the email being sent to the spam or junk folder.

The case against SPF hardfail with DMARC

While SPF hardfail (`-all`) might seem like the most secure option on its own, it can actually cause more harm than good when DMARC is actively being used. The primary issue stems from the fact that a hardfail can lead to legitimate emails being rejected too early in the mail flow, before DMARC has a chance to evaluate the full authentication picture, including DKIM. This is especially true for emails that are forwarded, as forwarding often breaks SPF, but not DKIM.

If an email is bounced at the SMTP MAIL FROM stage due to an SPF hardfail, the receiving server may not proceed to evaluate DKIM or DMARC. This effectively bypasses the DMARC policy that you've carefully set up to manage authentication failures. The intention behind SPF hardfail was to save resources by rejecting bad mail early, but with DMARC's comprehensive policy and reporting mechanisms, this early rejection can become counterproductive to your deliverability and visibility.

Many email service providers (ESPs) and mailbox providers (MBPs) today do not strictly enforce SPF hardfail when DMARC is present, precisely because they defer to DMARC's more comprehensive evaluation. While some older or smaller systems might still honor an SPF -all as a hard rejection, it's not the industry's common best practice, especially with widespread DMARC adoption. This aligns with advice on soft fail vs hard fail in SPF policies.

SPF Hardfail only

Policy enforcement: Immediate rejection at MAIL FROM for non-authorized senders.
Visibility: No direct reporting mechanism to the domain owner about failures.
Flexibility: Less adaptable, may result in legitimate emails being blocked due to forwarding.
Risk: Higher risk of legitimate emails being bounced without a clear reason or feedback.

DMARC with SPF softfail

Policy enforcement: DMARC policy (none, quarantine, reject) dictates action based on SPF or DKIM alignment.
Visibility: Comprehensive DMARC reports (RUA/RUF) provide insights into email traffic and authentication results.
Flexibility: Allows for a phased approach to enforcement and adapts to scenarios like email forwarding.
Risk: Lower risk of legitimate email loss while still providing strong protection against spoofing via DMARC.

DMARC: The robust policy layer

DMARC is designed to be the definitive policy layer for email authentication. It allows domain owners to set specific instructions for how receiving mail servers should treat emails that fail SPF and/or DKIM authentication. These policies range from p=none (monitor only) to p=quarantine (send to spam/junk), and finally p=reject (block the email entirely). This granular control means you don't need SPF to independently enforce a strict rejection policy. For a secure rollout, it's advised to safely transition your DMARC policy to higher enforcement levels.

When DMARC is set to a p=reject policy, any email that fails DMARC authentication (meaning both SPF and DKIM fail alignment) will be rejected by participating receiving servers. This provides a robust defense against spoofing and phishing without the rigidity of an SPF hardfail. Moreover, DMARC's reporting feature (through RUA and RUF tags) gives you invaluable insights into who is sending email on your behalf, whether authorized or unauthorized. This visibility is something SPF alone cannot provide.

Therefore, when DMARC is properly implemented and enforced, using SPF softfail (`~all`) is generally the recommended approach. It allows emails to pass the initial SPF check, giving DMARC the opportunity to conduct its comprehensive evaluation. If an email subsequently fails DMARC (due to both SPF and DKIM misalignment), the DMARC policy will then dictate the appropriate action, whether it's quarantine or outright rejection. This approach prevents legitimate emails from being blocked prematurely, especially in complex sending environments or scenarios involving forwarding, while still providing strong anti-spoofing protection. You can learn more about the benefits of implementing DMARC.

Example SPF record with softfailtext

v=spf1 include:_spf.example.com ~all

Implementing a balanced authentication strategy

Given DMARC's capabilities, the optimal strategy typically involves setting your SPF record to ~all (softfail) and relying on your DMARC policy for enforcement. This allows for a more flexible and robust authentication system. It ensures that emails are not prematurely rejected based solely on SPF, which is prone to breaking during forwarding, and instead allows the DMARC evaluation to take into account the more resilient DKIM signature.

When you have DMARC in enforcement mode (e.g., p=quarantine or p=reject), you have a clear mechanism to manage non-compliant emails and receive reports on unauthorized sending attempts. This level of control and insight far surpasses what SPF hardfail can offer on its own. It's a critical component in protecting your domain's reputation and ensuring your legitimate emails reach the inbox.

Ultimately, the decision to use SPF hardfail or softfail should be made in the context of your overall email authentication strategy. If DMARC is actively deployed and monitored, a softfail SPF record is generally more prudent. It supports the collaborative nature of SPF and DKIM, allowing DMARC to serve its intended purpose as the ultimate decision-maker for email authentication policies. This balanced approach provides strong security against impersonation without inadvertently blocking your own legitimate mail or that of your users.

DMARC policy	Action on authentication failure	Use case
p=none	No specific action, emails are delivered as normal.	Monitoring phase, gathering reports to understand email traffic.
p=quarantine	Emails failing DMARC are sent to spam or junk folder.	Soft enforcement, testing the impact of policy on legitimate email.
p=reject	Emails failing DMARC are rejected and not delivered.	Strongest enforcement against unauthorized use of the domain.

Views from the trenches

Best practices

Always prioritize DMARC for policy enforcement over strict SPF hardfail mechanisms.

Use SPF softfail (~all) when DMARC is actively deployed to ensure comprehensive evaluation.

Regularly monitor DMARC reports to identify legitimate email sources and potential spoofing attempts.

Common pitfalls

Setting SPF to hardfail (-all) when DMARC is active, potentially blocking legitimate email due to forwarding.

Over-reliance on SPF alone for anti-spoofing, ignoring the more robust DMARC layer.

Not configuring DKIM, leaving DMARC to rely solely on SPF, which is more fragile.

Expert tips

Consider a phased approach for DMARC deployment, starting with `p=none` to gather data before moving to `p=quarantine` or `p=reject`.

Remember that DMARC's OR logic means an email can pass if either SPF or DKIM aligns and passes.

Be aware that some legacy mail servers might still honor SPF hardfail before DMARC evaluation, though this is less common now.

Expert view

Expert from Email Geeks says that DMARC pass typically overrides an SPF fail verdict unless the SPF record is set to `v=spf1 -all`. A DMARC pass requires only a DKIM or SPF pass with proper domain alignment. Therefore, an SPF fail verdict should not result in rejection until after DMARC has been evaluated and found not to pass.

2023-10-19 - Email Geeks

Marketer view

Marketer from Email Geeks says that most receivers do not enforce SPF hardfail and defer to DMARC. However, some do honor a `-all` and will stop processing at MAIL FROM, indicating that while it's not the majority, it still happens.

2023-10-20 - Email Geeks

Final considerations for your email security

In conclusion, while SPF hardfail (`-all`) served its purpose in an earlier era of email security, its direct enforcement is largely superseded by DMARC. For optimal email deliverability and robust protection against spoofing and phishing, the focus should be on implementing a strong DMARC policy, supported by both SPF and DKIM with proper domain alignment. By favoring SPF softfail (`~all`) and allowing DMARC to be your primary policy enforcer, you create a more resilient and manageable email authentication system that provides both security and flexibility.