SPF Softfail or SPF Hardfail: What’s Right for Your Domain?

When it comes to email authentication, SPF offers different result qualifiers to indicate how the receiving mail server should handle emails that are outside of the list mentioned in the SPF record of the sending domain.

These result qualifiers are SoftFail and HardFail. There is no hard-and-fast rule as to which one’s the better choice — choosing the right SPF policy depends on your domain’s needs and priorities. 

Read on to learn more about the factors you need to consider and other protocols you can combine with SPF to enhance your email infrastructure. 

SPF SoftFail Vs HardFail

When a domain owner uses the SoftFail mechanism, they add the “~all” qualifier to their SPF record. This means that the domain owner recommends that the recipient’s mail server mark the email as potentially suspicious but doesn’t necessarily reject it outright. In this case, the emails subjected to the SoftFail mechanism get placed in spam folders.

In practice, many email systems treat SoftFail as a weaker indication of failure compared to HardFail. SoftFail allows for some flexibility, understanding that not all legitimate email servers may be explicitly listed in the SPF record.

On the other hand, when a domain owner uses the HardFail mechanism, it adds the “-all” qualifier to its SPF record. This indicates that the domain owner wants the recipient’s mail server to reject any email that does not match the IP addresses or “.from” in the SPF record. HardFail is a stricter policy, and it may result in a higher likelihood of legitimate emails being rejected if the SPF record is not properly configured to include all authorized mail servers, or due to instances of false positives. 

Why Might Genuine Emails Get Rejected?

SPF is a powerful tool for preventing email spoofing and phishing, but it’s important to configure it correctly to avoid unintended consequences. Here are some scenarios in which genuine emails might be rejected by recipients’ mail servers:

Incomplete SPF Records

If the SPF record for a domain is incomplete or does not include all the legitimate mail servers that send emails on behalf of that domain, genuine emails from those servers may be rejected.

Dynamic IP Addresses or Third-Party Services

If a business uses dynamic IP addresses or relies on third-party services to send emails, and these sources are not explicitly included in the SPF record, legitimate emails may be marked as spam or get rejected.

Email Forwarding

SPF can cause issues with email forwarding. If an email is forwarded through a server that is not listed in the SPF record of the original sender’s domain, the forwarded email may fail SPF checks and be rejected or marked as spam by the recipient’s mail server.

Changes in Infrastructure

If you are using a new email service provider or adding/removing mail servers, the SPF record must be updated accordingly. Failure to update the SPF record can lead to negative authentication results for legitimate emails.

Misconfigured SPF Records

Errors in configuring SPF records, such as typos or incorrect syntax, can lead to SPF failures. If the SPF record is not properly set up, even legitimate emails might fail SPF checks.

Image sourced from datto.com

Choosing the Right SPF Policy for Your Domain

Before selecting an SPF policy, it’s crucial to have a comprehensive understanding of what your organization needs. Here’s a rundown on factors to consider when choosing between SPF SoftFail and HardFail:

The Email Infrastructure

Identify all the legitimate mail servers that send emails on behalf of the domain. This includes internal servers, third-party services, and any other authorized sources. Failure to include all legitimate sources in the SPF record can result in genuine emails being rejected.

Level of Control 

The choice between SPF SoftFail (~all) and SPF HardFail (-all) depends on your desired level of control over email authentication. You should assess your risk tolerance and the importance of strict email policy enforcement. You should prioritize a strict policy over flexibility for non-email-sending domains.

Potential Impact on Legitimate Emails

SPF HardFail, while enhancing security, may result in false positives if not configured accurately. Legitimate emails could be rejected if the SPF record is not kept up to date or if there are changes in the email infrastructure. SoftFail provides more leniency, but caution is needed to avoid marking genuine emails as potentially suspicious.

Overcoming SPF’s Shortcomings with DMARC

Implementing DMARC alongside SPF and DKIM provides a more robust defense against email-based attacks and improves overall email deliverability. DMARC complements SPF by addressing its limitations and providing a more comprehensive and flexible framework for email authentication. 

One limitation of SPF is that it doesn’t provide a standardized way for domain owners to receive feedback on how their emails are being authenticated across different mail servers. DMARC introduces reporting mechanisms that allow domain owners to receive feedback reports (DMARC reports) detailing the results of SPF and DKIM authentication checks.

Email forwarding can break SPF checks because the original sender’s SPF record might not cover the forwarding server. DMARC provides a mechanism to handle forwarding scenarios more effectively by allowing domain owners to specify how to handle emails that fail authentication, such as forwarding them with a modified header.

With DMARC, domain owners can instruct receiving servers on how to handle emails that fail SPF and/or DKIM checks. This flexibility allows for a more nuanced and tailored approach to email authentication policies.

DMARC introduces the concept of alignment, ensuring that the “From” header domain aligns with the authenticated domain using SPF and/or DKIM. This helps prevent domain spoofing and strengthens email authentication overall.

Conclusion

In conclusion, the decision between SPF SoftFail and HardFail plays a pivotal role in shaping your organization’s email authentication strategy. While SoftFail allows for flexibility and caution in marking potentially suspicious emails, HardFail enforces a stricter policy, rejecting those that don’t align precisely with the SPF record. However, regardless of the chosen SPF policy, it’s crucial to address SPF’s inherent limitations. 

DMARC emerges as a powerful ally in this regard, offering additional layers of authentication, reporting mechanisms, and the means to overcome SPF’s shortcomings. By implementing DMARC alongside SPF, you can enhance your email security, reduce false positives, and ensure a more comprehensive defense against phishing and email spoofing attacks.