Sender Policy Framework (SPF) is an email authentication method that uses the DNS to authorize which IPs can send mail on behalf of your domain. The syntax of SPF allows admins to define two kinds of failure scenarios for dealing with unauthorized mail: softfail and hardfail. Although the latter is formally just called a fail in RFC 7208, we’ll use the more prevalent, colloquial term hardfail.

In short, a hardfail means that an email is explicitly not authorized. A softfail, on the other hand, signifies that an email is probably not authorized. One common interpretation of this difference is that hardfail instructs the recipient to reject the email outright. In contrast, softfail should be marked as suspicious, for example, via segregation to a spam folder. However, these outcomes are far from guaranteed.

In practice, SPF is just one piece in the jigsaw puzzle of email security, and its behavior is affected dramatically by the presence of other factors, such as Domain-based Message Authentication, Reporting & Conformance (DMARC). This article will explore the meaning and syntax of both softfail and hardfail in SPF, how other protocols like DMARC alter recipients’ interpretation of SPF, and recommendations that admins should consider when deploying SPF with either a softfail or hardfail policy.

Executive Summary

Before we dive deeper into these two SPF failure modes, let’s take a moment to review some core concepts that are important to understand when discussing hardfails and softfails in SPF. We’ll casually refer to these concepts throughout the article. 

Core Concept	What It Means
SPF	Authentication protocol to allow specific IPs to send mail for a domain
TXT Record	DNS record type in which SPF records are published
Hardfail	The sender is not authorized, and the email should thus be discarded
Softfail	Sender is probably not authorized and perhaps can be marked as suspicious
DKIM	Cryptography-based email authentication system.
DMARC	An email authentication protocol for determining authorized use of the domain in the visible From header

Softfail Versus Hardfail

SPF uses a TXT record in a domain’s DNS settings to authorize certain mail servers to send from that domain. Let’s look at the syntax and semantic differences between fail types.

Syntax Differences

We can see the SPF policy of an actual domain by performing a DNS lookup and checking the pertinent TXT record. Let’s take a peek at a real SPF record, using the nslookup command-line tool:

PS C:> nslookup -type=TXT google.com | grep spf
google.com    text = "v=spf1 include:_spf.google.com ~all"

To see an in-depth explanation of the syntax of an SPF record, check out our dedicated article on SPF record syntax. For the purposes of the current guide, we’re only concerned with the last part: ~all. The tilde means that Google prefers recipients to softfail noncompliant mail. If the tilde had instead been a dash, that would indicate hardfail. 

That’s really all there is to the syntactical difference between the two. So let’s change gears and look at what the semantic difference is.

Semantic Differences

According to RFC 7208, the difference is this:

Fail. A fail result is an explicit statement that the client is not authorized to use the domain in the given identity. (Recall that this RFC uses the term fail rather than hardfail.)

Softfail. A softfail result is a weak statement by the publishing Administrative Management Domain (ADMD) that the host is probably not authorized. It has not published a stronger, more definitive policy that results in a fail.

The classic interpretation used to be that a hardfail should result in the email being rejected outright, never even appearing in the intended recipient’s inbox. A softfail, on the other hand, should still allow the recipient to receive the message, while still offering some mitigation against its potential risk as a “probably” fraudulent email. For example, the mail provider could mark the email as suspicious.

In practice, mail providers that adopted SPF in the first few years were all over the place in how they handled SPF fails of either type. And now, with the prevalence of DMARC, the subtle distinction has largely been rendered a moot point. DMARC provides a way for domain owners to request treatment for mail using their domain that fails both SPF and DKIM. However, it doesn’t distinguish at all between hardfails and softfails from SPF.

DMARC reduces either case to have simply failed SPF. To reduce nuance even further, an email that passes DKIM but fails SPF may still pass overall for DMARC’s purposes. So, while it’s important to understand what soft and hard fails are intended to mean, it’s even more crucial to know how DMARC reacts to different kinds of failures from other protocols in aggregate; otherwise, you’re bound to run into some nasty surprises.

You can learn more about DMARC from our blog post, What is DMARC.

The world of email security protocols can be labyrinthine for newcomers, and even experienced admins often find themselves on Google looking up basics like “spf softfail vs hardfail” for the dozenth time. The superficial difference is reasonable and easy to understand, but once contextualized in the wider ecosystem of email security, the picture starts to grow more complicated. 

Best Practices and Use Cases

Hopefully we’ve helped you cultivate at least an intuitive understanding of what hardfail and softfail mean in SPF and knowledge of the syntactical and semantic difference between the two. With that domain-specific knowledge in mind, we can solidify the abstract, conceptual understanding of SPF’s support for hardfails and softfails into practical knowledge about when and why a domain admin should use one or the other.

Below we outline some basic best practices for SPF, with particular care for the relevance of the distinction between both failure modes. Read more to build your intuition of which should be used when, and why.

Configure Domains That Don’t Send Email

What if you, as a webmaster, own a website with a domain that won’t send any email whatsoever? Even then, you’ll still likely want to prevent other people from fraudulently sending mail from your domain without your authorization. And that’s where SPF comes in: it allows you to create a policy that completely hardfails all mail sent from your domain.

Such a policy is simple to create and would look like this: v=spf1 -all.

Disallowing all outgoing mail for a domain using SPF is trivial. However, as we mentioned earlier, the presence of DKIM and DMARC policies alongside SPF might change behavior in big ways. Thus, it’s important to also ensure that DMARC is not undermining SPF. 

If you wish to learn more about how DMARC works, you may benefit from checking out our article dedicated specifically to the topic: What is DMARC.

Stick with Softfail

Automating forwarding of mail will cause SPF to fail if the forwarder is not listed in the SPF policy as an approved sender for the domain. For this reason, it’s recommended to prefer softfail instead of hardfail.

Integrate DMARC

Even when applying the stricter hardfail option, SPF has serious inadequacies if used by itself. Among its most grave weaknesses is that SPF leaves email vulnerable to spoofed “from” addresses. SPF uses the domain shown in a message’s Return-Path field for authentication, which is different from the “From:” address that the human recipient of an email will see.

To learn more about the strengths and weaknesses of SPF, you can peruse the “SPF limitations” section of our article dedicated to SPF more generally: What is SPF?

DKIM and DMARC are email security protocols that exist to complement SPF and make up for some of its inadequacies. If you’re interested in SPF, it’s probably because you are really worried about preventing fraudulent senders from abusing your domain. Learn about DKIM and DMARC via our guide: DMARC vs DKIM.

Verify Your Policy

It’s easy to misconfigure an SPF policy. When you add a DNS record, you likely won’t receive any kind of alert from the nameserver letting you know if you’ve provided a policy that makes no sense at all.

Luckily for you, free tools exist online that allow you to analyze an SPF policy to make sure it is syntactically sound and actually does what you think it’s supposed to do.A broad variety of such tools can be found easily on any search engine, but Valimail’s Domain Checker is a good starting point.

Overall, it’s an integral part of verifying or debugging an SPF policy.

Conclusion

SPF is an important part of a comprehensive email security strategy, especially when combined with a versatile enforcement mechanism like DMARC. Although DMARC changes the interpretation of hardfails and softfails substantially, the core meaning is straightforward: not allowed for hardfail vs. probably not allowed for softfail.

To complicate the picture, not all mail providers will respect that difference, even in the absence of DMARC. Nevertheless, it’s useful to know that SPF offers a means for softening the certainty of an email. After all, that’s ultimately why the IETF’s SPF working group created this distinction in the SPF protocol in the first place.

Email security is a big, complex web of protocols. Security was an afterthought in the original protocols, so different security mechanisms have been patched on after the fact, as needed, over the years. However, the maze is not unnavigable, and armed with the information above, in addition to our other articles on email security best practices, you at least have a map.