Sender Policy Framework (SPF) is an email security protocol for verifying that an email is authentic. When a mail server sends an email from its IP address, SPF confirms that the IP is actually allowed to send for that domain. Thus, to “fail” SPF means that the SPF policy of a domain did not approve the IP address of the sending email server to send from that domain. 

How exactly the IP is determined to be legitimate—whether it’s in an MX record for the domain, an A record, a range of subnets, etc.—depends on the syntax of the SPF policy. What happens to an email that fails also depends on a variety of factors, such as whether it was a “hard” or “soft” fail and whether other protocols like DKIM and DMARC are in place. 

In this article, we’ll explain what causes SPF failure and explore what it means to fail SPF. We’ll illustrate what happens when SPF does fail. Finally, we’ll guide you through debugging techniques for SPF failures and explore fixes for common issues.

Before we dive in, let’s start with a quick overview of some pertinent terminology.

Fail*	Indicates that the sending host is definitely not authorized to use the domain (often colloquially referred to as a “hard fail”)
Soft fail*	The sending host is probably not authorized to use the domain
SMTP Envelope	Email metadata, including the “envelope from address” that SPF validates
DKIM	A protocol that enables organizations to take responsibility for messages in a way that’s verifiable by the recipient.
DMARC	Uses SPF and/or DKIM to validate the usage of the domain in the visible “From” header.

* Note that DMARC treats both hard and soft fails as equally failing SPF, and SPF failures may be overridden by DMARC if DKIM passes.

Understanding SPF

Before we try to really understand what it means to fail SPF, we should aim to understand SPF itself. A more inclusive explanation can be found in our article What is SPF?, but we’ll provide a quick overview in this section.

SPF uses TXT records in a domain’s DNS record to publish a policy defining which servers and networks are authorized to use that domain in email. For a thorough examination of the syntax of such policies, consult our article on SPF Record Syntax. To get a basic idea of what an SPF record actually looks like, let’s use the nslookup command line tool to view the SPF record of a real, live domain. For our example, we’ll use the University of Constantinople:

$ nslookup -type=TXT constantinople.edu.gr | grep -m 1 'spf'
constantinople.edu.gr    "v=spf1 -all"

So the policy is “v=spf1 -all”. This is a pretty simple policy: The v tag indicates we are using version 1 of SPF (which is the only version right now) and the -all mechanism means that we hard fail any noncompliant mail. So what IP address must a sender have to pass this policy? Well, we never include an acceptable source, meaning that any mail sent from the University of Constantinople’s main domain will fail SPF. This is because the university handles mail from a different domain, thus anything sent from constantinople.edu.gr ought to be discarded as fraudulent. 

Blanket failure policies like this, where there is no legitimate source to send mail from, are common on domains that aren’t used for email but want to prevent abuse from would-be fraudsters.

A final note: SPF prevents senders from claiming that their email originates with a server approved for sending from your domain. But the actual from address that recipients see when they open an email is not verified by SPF. That from address is protected by a different protocol called DMARC.

What It Means to “Fail” SPF

If a recipient server checks the sending server’s IP and finds that it’s not authorized in an existing SPF policy, and that policy specifies that a hard or soft fail should occur, then the email can be said to have failed SPF.

In the case of a hard fail, this means the email may be discarded outright, never even arriving in the inbox of the intended recipient. In such a case, the sender will usually receive a “bounce” email from the receiving server letting them know that their email did not reach its destination. The bounce error code should be 550 and have an accompanying message akin to the following:

“550 SPF Hard Fail: Domain [your domain here] does not designate [sending IP address] as permitted sender.”

Note, however, that such an error message isn’t guaranteed.

A soft fail, on the other hand, will typically not produce a bounce on its own. Rather, the email might be marked as suspicious in the user’s inbox. Mail servers can reject messages for any reason their administrators choose, thus the ambiguity about what exactly will occur given a hard vs soft fail. 

As RFC 7208 Section 8.5 puts it, a soft fail “MAY subject the message to closer scrutiny than normal.” While the RFC never breaks down “closer scrutiny” into a more actionable definition, one prevalent interpretation is to send the mail to a spam folder. For example, ProtonMail, a popular email provider focused on privacy, relegates mail that soft-fails SPF into the spam folder and attaches this message to let the user know why the message has been segregated as spam:

DMARC can alter the outcome of SPF failure in two surprising ways:

1. If DKIM passes, DMARC may pass the message even if SPF fails
2. DMARC doesn’t distinguish between a soft or hard SPF fail. DMARC considers either outcome to have failed SPF.

For additional information on DMARC and DKIM and their relationship to each other, check out our article on DMARC Versus DKIM.

Avoiding SPF Issues

Let’s get to the meat and potatoes of understanding how SPF can fail. This includes intentional failure (failing an email sent from an unauthorized IP) or improper behavior (implementing the record incorrectly, thus blocking mail that we’d prefer to allow). We’ll also discuss how to prevent the latter, incorrect behavior.

Testing a Policy Before Deployment

There are two ways to test a policy before deploying it to a live domain in production: validating the syntax or actually trying the policy out in a test environment.

The easiest method is to parse and validate the record’s syntax. For example, we can use the SPF Record Checker to verify that a record’s syntax is correct. The tool also provides helpful warnings for common errors, misconfigurations, and bad practices

After you’ve verified that the record’s syntax is correct, you can also try the record on a test domain or subdomain and test everything out before deploying to any production domains.

How to Locate a Domain’s SPF Policy

Once a policy is deployed, we can view it (and thereby study, analyze, and understand it) by performing a DNS query. We must be sure to query the TXT record, as many DNS lookup tools will only show us a domain’s IP address by default (the A or AAAA record, for IPv4 and IPv6, respectively).

One common way to accomplish this is using a command line tool like nslookup, much like we did for the University of Constantinople earlier in this article. Let’s try with a different domain this time.

$ nslookup -type=TXT pulaski-tn.com | grep spf
pulaski-tn.com    "v=spf1 a mx  include:us-spf.atmailcloud.com ~all"

Voila! We can see that in addition to authorizing IPs matching this domain’s A record (and AAAA record, if the connection is made over IPv6) as well as the IPs of the hosts in its MX records, the beautiful town of Pulaski, Tennessee uses an include mechanism to import the policy of another domain as well. If something doesn’t match, a soft fail is issued.

For users who are less savvy on the command line, a variety of web tools exist that will perform an equivalent DNS query for you and present the results on your browser. For example, Valimail’s own Domain Sender Identity Verification tool displays a domain’s SPF record (along with a treasure trove of additional security information).

DMARC with DKIM Pass May Override SPF Fail

Suppose you have implemented SPF with hard fail enabled, then you sent an email from an IP not authorized in your SPF policy. Yet the email arrived in the recipient’s inbox just fine. What gives?

One possible culprit is DMARC. If an email passes DKIM, DMARC will pass it even if it fails SPF. So if you are sending from a server that complies with DKIM, and you have DMARC set up, don’t be surprised if emails that you’d expect to fail make it to the inbox untouched.

Avoid Using the SPF Record Type Instead of TXT

SPF records are implemented using the TXT record type in DNS. However, for a time, SPF had its own dedicated kind of record. This never caught on and is largely forgotten. Nevertheless, many major domain providers still offer this record type. For example, the SPF record type appears as an option in the DNS record web panel for the popular domain registrar Gandi.net:

The dedicated SPF record type should not be used. If you’ve used this by mistake and are experiencing problems, there’s a good chance this is a contributing factor. SPF records should be deployed using TXT records.

No Valid Source for Mail

If -all is set (hard fail) and you neglect to authorize any IPs to send from your domain, you might end up with all mail being rejected! This can also happen if you use an include mechanism to import another domain’s policy that doesn’t include any valid sources.

This outcome is fine, of course, if it’s your intention that no mail be sent from your domain.

Mail Forwarding Breaks SPF

Mail that is automatically forwarded by an arbitrary server will typically fail SPF. When the forwarding server’s IP address is not known beforehand, there is no way to authorize it in an SPF policy. If you expect frequent forwarding of emails from your domain, you can set these to soft fail or set them to use DMARC. DMARC will pass an email as long as it passes one of either SPF or DKIM. DKIM can work with automatically forwarded mail, as long as there were no alterations to the message during the act of forwarding.

Conclusion

SPF is easy to set up, and it is a valuable asset in email security when used alongside newer email security protocols like DKIM, DMARC, and others. It’s an effective tool for preventing certain kinds of abuse, so it’s important that aspiring email administrators properly understand both its applications and limitations.

The strategies and information presented above are meant to provide you with a starting point in understanding what causes an SPF policy to fail an email or go wrong more generally. From there, you should be able to begin to debug, or better yet, prevent unwanted SPF failures while making sure mail that actually is fraudulent does fail.