Why SPF Authentication Fails: none, neutral, fail(hard fail), soft fail, temperror, and permerror Explained
Tags: email, spf
Published: 2021-03-07 09:22:34

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4c92xuo23ty68vc8mqg8.png)

DMARC (Domain-based Message Authentication, Reporting and Conformance) specifies these possible errors (non-pass) in SPF (Sender Policy Framework) authentication: **none**, **neutral**, **fail** (hard fail), **softfail** (soft fail), **temperror** (temporary error), and **permerror** (permanent error).

For anyone who isn't well-versed in SPF and DMARC, this can be confusing as to why these errors occur in SPF, how they are interpreted in DMARC, and what action to take to fix them.

This article is going to take a deep dive into these topics.

#### What are SPF authentication results?
An SPF authentication result is the outcome of an SPF authentication check performed on the receiving email server. When a host tries to deliver an email to the target mailbox:

* the receiving email server extracts the domain name from the envelope from address; e.g., ```business.com```;
* the receiving email server checks the connecting host's IP address to see if it's listed in ```business.com```'s SPF record published in the DNS. If the IP address is listed, the SPF check passes, otherwise not.

For more information, refer to: [How SPF works](../how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#how-spf-works).

It's straightforward enough in the pass scenario when everything goes well: the SPF record exists, is syntactically correct, and the IP address in question appears on the list. However, it gets a bit tricky when SPF authentication fails, for various reasons.

Here is the list of common reasons that cause an SPF authentication check to fail:

* unable to resolve the domain name in the DNS;
* unable to find the SPF record on the domain;
* the SPF record is not syntactically correct;
* the IP address is not on the list specified in the SPF record;
* the number of DNS lookups involved in a single SPF check exceeds 10.

When any of the above is true, one of the following SPF authentication result is returned and then passed along to DMARC:

* none;
* neutral;
* soft fail;
* fail, or hard fail;
* temperror, or temporary error;
* permerror, or permanent error.

We are going to explain each of them below.

#### SPF none explained
When the server tries to resolve the domain for SPF authentication, it returns none as the SPF result if either of the following is true:

* unable to resolve the domain name in the DNS;
* unable to find the SPF record on the domain.

In other words, if there is no SPF record on the domain, SPF none is returned.

SPF none is treated as fail in DMARC: the SPF authentication check fails. This means if DKIM authentication fails too, it fails the final DMARC authentication.

To rectify this, simply publish a valid SPF record on your domain:
* [How to Add SPF Record in GoDaddy: GoDaddy SPF Setup Guide](../how-to-add-spf-record-in-godaddy-godaddy-spf-setup-guide)
* [How to Add SPF Record in Cloudflare: Cloudflare SPF Setup Guide](../how-to-add-spf-record-in-cloudflare-cloudflare-spf-setup-guide)

#### SPF neutral explained
SPF neutral means the SPF record on the domain has explicitly stated that it is not asserting whether the IP address is authorized. This is typically implemented by appending a ?all mechanism to an SPF record. When this mechanism is evaluated, any IP address will cause SPF to return a neutral result.

SPF neutral can be interpreted in DMARC as either pass or fail (!), depending on how you set up DMARC on your email server. This is normally controlled by a flag in your DMARC setup, and it varies across DMARC packages. In OpenDMARC by [Trusted Domain](https://www.trusteddomain.org), SPF neutral is interpreted in DMARC as fail by default.

#### SPF softfail explained
SPF softfail is a weak statement that the host is probably not authorized. The domain has not published a stronger, more definitive policy that results in a "fail". This is typically implemented by appending a ~all mechanism to an SPF record. When this mechanism is evaluated, any IP address will cause SPF to return a softfail result.

Like neutral, SPF softfail can be interpreted in DMARC as either pass or fail, depending on how you set up DMARC on your email server. In OpenDMARC, SPF softfail is interpreted in DMARC as fail by default.

#### SPF fail explained
SPF fail, also known as SPF hardfail, is an explicit statement that the client is not authorized to use the domain in the given identity. This is implemented by appending a -all mechanism to an SPF record. When this mechanism is evaluated, any IP address will cause SPF to return a fail result.

SPF fail is definitively interpreted in DMARC as fail, regardless of the DMARC package you are using.

#### SPF temperror explained
SPF temperror, also known as SPF temporary error, means the SPF verifier encountered a transient (generally DNS) error, like a DNS timeout, while performing the check. A later retry may succeed without further DNS operator action.

An SPF temperror causes the email server to return a temporary failure, i.e., the corresponding SMTP command will return an appropriate 4xx status code. The client may try again later to deliver the email, depending on how the retry policy is set up.

Therefore, DMARC interpretation of SPF temperror is irrelevant here: the error is used to return a 4xx status code and the SMTP session ends. The email is deferred, rather than delivered.

#### SPF permerror explained
SPF permerror, also known as SPF permanent error, means the domain’s published records could not be correctly interpreted. This signals an error condition that definitely requires DNS operator intervention to be resolved.

SPF permerror occurs when any of the following is true:

* multiple SPF records are found on one domain; learn more [here](../can-i-have-multiple-spf-records-on-my-domain);
* the SPF record is syntactically incorrect;
* the number of DNS lookups involved in a single SPF check exceeds 10.

Here is an example of SPF permerror caused by having exceeded the 10-DNS-lookup limit in SPF:

![](SPF-record-check-permerror.png?class=width75)

SPF permerror is interpreted in DMARC as fail. Therefore, you should fix your SPF record when you see SPF permerror. Otherwise, it impacts your email deliverability negatively.

#### SPF permanent error: too many DNS lookups
A common type of SPF permanent error is: SPF permanent error: too many DNS lookups. This happens when you have more than 10 DNS lookups in your SPF record.

In the example below, the domain's SPF record has 19 DNS lookups, which far exceeds 10:
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dlac15w7gp8jmfe01b8i.png)

To fix this particular issue, you can use DMARCLY's [Safe SPF](https://dmarcly.com/safe-spf) feature.

Refer to: [SPF PermError: Too Many DNS Lookups - When SPF Record Exceeds 10-DNS-Lookup Limit](../spf-permerror-too-many-dns-lookups-when-spf-record-exceeds-10-dns-lookup-limit).

#### What's the difference between ?all, ~all, and -all?
A commonly asked question is: which one of ?all, ~all, and -all should I use in my SPF record?

As mentioned above, one key difference between ?all, ~all, and -all is how DMARC interprets the result:

* for ?all (neutral) and ~all (soft fail), it's interpreted as fail in OpenDMARC by default; although you can change the policy so that they are interpreted as pass;
* for -all (fail), it's definitively interpreted as fail in all DMARC packages.

So if you choose to use -all, the SPF result is interpreted consistently as fail across DMARC deployments/packages, while ?all and ~all might be interpreted differently (pass or fail) on different email servers.

[Original post](https://dmarcly.com/blog/why-spf-authentication-fails-none-neutral-fail-hard-fail-soft-fail-temperror-and-permerror-explained)