Permerror spf permanent error

The Most Common SPF Errors

DMARC (Domain-based Message Authentication, Reporting, and Conformance) identifies and categorizes the possible SPF fails. Here are some of the SPF non-pass errors.

• none: Unable to resolve domain name or find SPF record in the domain
• neutral: The domain does not explicitly state that the IP address is authorized
• fail (hard fail): The client is not allowed to use the domain
• fail (soft fail): The host is probably not authorized
• temperror (Temporary error): SPF encountered a transient error like DNS timeout
• permerror (Permanent error): Inability to correctly interpret the domain’s published records.

What Is SPF PermError?

SPF permerror or ‘SPF Permanent Error’ is one of the common SPF errors that call for immediate resolution for emails to have higher deliverability. It signifies that DMARC could not correctly interpret the domain’s published records, and signals an error condition that requires immediate DNS intervention to be resolved. SPF permerror can occur because of any of the following reasons.

• If there are multiple SPF records on one domain
• If the SPF record has a syntax error
• If an SPF checking process lists out more than 10 DNS lookups

The most common SPF permerror is related to the third parameter, i.e., ‘too many DNS lookups.’ Let us understand what it means.

What Is SPF Permerror – Too Many DNS Lookups?

Limiting the number of DNS lookups is one of the significant safeguards put in place with SPF to avoid timeout issues. As a rule, SPF evaluates a maximum of 10 DNS mechanism lookups in an SPF record. These mechanisms include a, mx, ptr, exists, include, and redirect. If the DNS lookups exceed 10, it raises an SPF permerror. If you encounter an SPF permerror, you would have to remove some of the current mechanisms/lookups.

How Do You Avoid Encountering The Error Of 10 DNS Lookup Limit?

There are numerous ways to avoid SPF permerror – too many DNS lookups, as listed below.

Avoid unnecessary ‘include’ statements

The role of the include statement in an SPF record is to redirect DNS lookup to another domain’s SPF record for verifying any of their authorized IPs. The number of include statements in the original SPF record or the redirected ones should not exceed 10.

Use of ip4 and ip6 mechanisms

Replace the include statement with ip4 and ip6 mechanisms if possible. They are used to list a static IP range in the SPF record. It eliminates the necessity of an include statement that references another domain’s SPF record.

Remove mechanisms referring to the same domain

Removing mechanisms that refer to the same domain can avoid unnecessary DNS lookups.

Avoid ptr mechanisms

SPF recommendations caution against the use of the ptr mechanism in an SPF record. This DNS record links an IP address to a domain. Avoiding the ptr mechanism is better because it can result in a large number of DNS lookups.

Removal of legacy partner and vendor domains

One must remove all include statements that redirect SPF record check to vendors or partners who do not send emails on their behalf. Such removal eliminates unnecessary DNS lookups.

One should reference actively sending domains

One should ensure that the referenced domains are active ones. Otherwise, should consider removing them.

Perform SPF record checks

A robust SPF record checking tool can also help you diagnose whether your SPF record is over the 10-lookup limit.

We have seen the concept of SPF permerror and learned how to resolve the ‘too many DNS lookups’ issue. Let us now consider the difference between SPF temperror and SPF permerror.

SPF TempError vs. PermError

SPF temperror is a temporary error that usually doesn’t require much user intervention to solve. It usually goes away by itself. It can occur during the SPF verification process. An error like a DNS timeout is an example of an SPF temperror, whereas more than 10 DNS lookups can result in SPF permerror. If you don’t encounter SPF temperror from multiple mailboxes, you can conclude there are no DNS configuration problems with your domain and SPF record.

Email deliverability is crucial to maintain customer trust and business reputation. Errors in SPF authentication can fail to deliver emails, leading to business communication issues. As discussed above, SPF permerror is one of the crucial SPF errors that require immediate attention. Resolving such errors in time can help in having better SPF authentication, and resultantly better email deliverability.

Permerror spf permanent error

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.

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;
• multiple SPF records found 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;
• the number of void lookups involved in a single SPF check exceeds 2;

When any of the above is true, one of the following SPF authentication results 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:

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, 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;
• the SPF record is syntactically incorrect;
• the number of DNS lookups involved in a single SPF check exceeds 10;
• the number of void lookups involved in a single SPF check exceeds 2.

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

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:

To fix this particular issue, you can use DMARCLY’s Safe SPF feature.

What’s the difference between ?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;

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.

Get a 14 day trial. No credit card required.

Источник

Permerror spf permanent error

«SPF PermError: too many DNS lookups» is a common error seen in many SPF (Sender Policy Framework) implementations. When an often overlooked SPF 10-DNS-lookup limit is exceeded, an SPF PermError, aka SPF permanent error, is returned. SPF PermError’s can affect your email deliverability.

This article explains what the SPF 10-DNS-lookup limit is, what the consequences are when an SPF record falls foul of it, and how to fix this issue using DMARCLY’s Safe SPF feature.

SPF PermError: too many DNS lookups

When you set up SPF on a domain, sometimes you run into some SPF permanent error along the lines of «SPF PermError: too many DNS lookups». This can be seen on an email server with compliant SPF support, or from an online SPF record checker.

How is «SPF PermError: too many DNS lookups» interpreted by DMARC?

When «SPF PermError: too many DNS lookups» is returned during an SPF check, DMARC treats that as fail since it’s a permanent error, and all SPF permanent errors are interpreted as fail by DMARC.

What is SPF DNS lookup limit?

According to the official RFC specification document RFC7208:

SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the «include» mechanism or the «redirect» modifier. If this number is exceeded during a check, a PermError MUST be returned. The «include», «a», «mx», «ptr», and «exists» mechanisms as well as the «redirect» modifier do count against this limit. The «all», «ip4», and «ip6» mechanisms do not require DNS lookups and therefore do not count against this limit.

In other words, the SPF specification requires that the number of mechanisms and modifiers that do DNS lookups must not exceed 10 per SPF check, including any lookups caused by the use of the «include» mechanism or the «redirect» modifier. Otherwise, an SPF PermError, more specifically «SPF PermError: too many DNS lookups», is returned.

This limit is imposed on the receiving email server side. Here are a few popular SPF software packages that implement this limit:

Why impose the SPF DNS lookup limit?

Why this seemingly artificial limit? Well, as it turns out, the 10-DNS-lookup limit is implemented to thwart Denial-of-Service (DoS) attacks. Consider such a scenario:

• a malicious user creates an SPF record on domain malicious.com, with references to another domain victim.com;
• he then sends a lot of emails from malicious.com to mailboxes hosted by different email service providers (ESP) with SPF implemented;
• upon receiving such an email, the ESP queries the DNS for victim.com;
• since many ESP’s are involved, they amplify this traffic; this effectively turns into a DoS attack at victim.com;
• what’s more, the true source of the attack is hidden.

As you can see, a pretty innocent email authentication mechanism can be exploited for malicious use, if no care has been taken! While the consequences can be severe, the solution to this problem is simple: putting a limit on the max number of DNS lookups per check on the ESP side can drastically mitigate it, since the amplification is limited to 10, instead of potentially much larger.

Does my SPF record exceed the SPF DNS lookup limit?

You can use our SPF record lookup tool to check your SPF DNS lookup count. In addition to the basic information about your SPF setup on your domain, it also shows the number of DNS-querying mechanisms/modifiers. Here is the result of an SPF check on microsoft.com, which has exactly an SPF DNS lookup count of 10:

I suggest that you run a similar check on your domain, and see what the number looks like.

What happens if it exceeds the SPF DNS lookup limit?

When the SPF implementation on the receiving email server encounters more than 10 DNS-querying mechanisms/modifiers in the sender’s domain’s SPF record, it returns «SPF PermError: too many DNS lookups». As mentioned above, an SPF PermError is interpreted by DMARC as fail, and consequently, the email might not land in the inbox, depending on the email server’s settings.

Therefore, your best bet is to keep the DNS-querying mechanisms/modifiers in your SPF record include for each of the services in the record counts 1 against the limit. And if they further contain DNS-querying mechanisms/modifiers, it reaches/exceeds the limit fairly quickly.

While many email service providers (ESPs) like Gmail send unauthenticated emails to spam by default, Microsoft Office 365 takes a step even further: they block email sender domains automatically if they fail email authentication, including SPF authentication.

The Antispam policy allows administrators to “Allow” domains regardless of the reputation of the domain. We’re changing our policies to not honor Allow rules when the domain fails authentication.

— Microsoft Office 365, April 2020

Learn more about this on Microsoft Office 365’s roadmap.

Enter SPF record flattening

There is one simple solution to this problem though. Through «flattening» an SPF record, one can reduce the number of DNS-querying mechanisms/modifiers so that it’s smaller than 10.

This is how «SPF record flattening» works: for each of the DNS-querying mechanisms/modifiers, query the DNS to get the IP addresses, then replace the original mechanism/modifier with the IP addresses. Each time a mechanism or a modifier is replaced, the total DNS lookup count is decremented by 1.

Using this SPF record flattening technique, you can turn a very complex SPF record containing well over 10 DNS-querying mechanisms/modifiers into a «flat» IP address list, staying comfortably in the «safe zone».

Let’s take a look at what a flattened SPF record looks like. Here are the IP addresses by flattening the SPF record on microsoft.com:

As you can see, this flattened SPF record contains the same IP addresses as those in the original SPF record on microsoft.com, and yet it has no DNS-querying mechanism/modifier in itself!

Problem solved? Well, not quite yet.

What if the IP addresses underlying one of the include mechanisms are changed? That means the flattened SPF record now goes out of synchronization on these IP addresses, which will produce incorrect results in SPF authentication.

Of course, you can manually flatten the SPF record again, and update it in the DNS. Needless to say, this is terribly tedious and error-prone, not to mention you will have to monitor it all the time.

Good news is, DMARCLY has a feature called «Safe SPF», which is exactly purpose-built to save your sanity.

Safe SPF to the rescue

Kill two birds with one stone with Safe SPF: always keep your SPF record’s DNS-querying mechanisms/modifiers below 10, without having to worry about manually flattening the SPF record and updating it in the DNS at all!

Follow the steps here to set up Safe SPF on your domain:

Generate Safe SPF record

In dashboard->DNS Records->Safe SPF, choose the domain you want to set up Safe SPF on, then click the Generate Safe SPF Record button, as shown below:

Publish the Safe SPF record

Now that the Safe SPF record is generated, you need to publish it on your domain in the DNS. Publish it as you would a regular SPF record. Keep in mind: a Safe SPF record is an SPF record.

Verify the Safe SPF record

Next you need to verify the Safe SPF record is published correctly and accessible to all. Click the Verify Safe SPF button now:

Save Safe SPF

Finally, you need to save Safe SPF so that your SPF record is always up to date:

Here is what it looks like:

As can be seen from above, Safe SPF is activated on the specified domain.

Once Safe SPF is activated on a domain:

• the Safe SPF record contains the same IP addresses as those in the original SPF record;
• the Safe SPF record has no more DNS-querying mechanisms/modifiers than 10;
• it is always updated when the underlying IP addresses change;
• there is zero maintenance on your side.

How to update an existing Safe SPF record (Method 1)

After you generate/publish a Safe SPF record, you might want to update the original SPF record at a later time.

For example, you might want to:

1. add a new mechanism (include, ip4, mx, a, etc.) to the SPF record;
2. update an existing mechanism in the SPF record;
3. remove an existing mechanism from the SPF record.

You can use the same Safe SPF process in the last section for this purpose. One thing to note here is that you need to update your original SPF record with your intended changes before you plug it into the Safe SPF process.

Let’s walk through a practical example to show exactly how to do this.

Say your domain is: yourdomain.com, and the original SPF record on the domain looked like this:

you created a Safe SPF record for it in the past:

and your organization plans to integrate a new email service called anotherservice. Now you need to include it in your SPF record, so that the emails sent from that service’s hosts pass SPF authentication.

Let’s assume anotherservice’s SPF include is:

you need to update your original SPF record to include this service, so that it looks like:

Next, you need to go through the whole Safe SPF process with the updated original SPF record:

Specifically, use the above value for the Original SPF Record field in the «Generate Safe SPF record» step in the «Safe SPF to the rescue» section. Then go through all the remaining steps in the Safe SPF process.

Once you are done, your new Safe SPF record on yourdomain.com contains all the IP addresses in include:anotherservice.com, in addition to the existing IP addresses. And if there is any underlying change in include:anotherservice.com, your Safe SPF record will pick it up automatically.

This approach applies to all scenarios including adding, replacing, and removing.

For example, if you want to replace someservice.com with anotherservice.com in your SPF record, just update it to:

then run it through the whole Safe SPF process.

In another example where you want to remove the mx mechanism from the SPF record, simply update it to:

then run it through the whole Safe SPF process.

How to update an existing Safe SPF record (Method 2)

Another way to update your existing Safe SPF record is to add the new mechanism directly to your published Safe SPF record.

Note that this approach only applies to adding an additional mechanism, rather than replacing or removing an existing one. If you want to replace or remove an existing mechanism, please use Method 1 described above.

Let’s say you’ve published a Safe SPF record on your domain:

This record contains all the IP addresses resulted from all the mechanisms in your original SPF record.

Then you need to add a new service include:newservice.com, you can simply update the SPF record on your domain to:

Now the SPF record on your domain contains all the IP addresses resulted from all the mechanisms in your original SPF record, as well as those in newservice.com. In other words, the emails sent from newservice’s hosts will pass SPF authentication.

Partial Safe SPF

If some of the external includes in your SPF record are not flattenable, for example, Office 365 requires include:spf.protection.outlook.com in the top-level SPF record, you can use partial Safe SPF to solve the problem.

Basically, it’s nothing more than leaving the non-flattenable SPF include out, running the rest of your original SPF record through Safe SPF, then adding that SPF include back along with the generated Safe SPF record, while publishing the SPF record on your domain.

Источник

When the SPF record on a domain can’t be correctly interpreted, SPF returns a PermError (permanent error). In contrast with an SPF TempError (temporary error), an SPF PermError requires a system administrator to take measures to rectify the issue.

Here is a list of causes of SPF PermError:

• multiple SPF records are found on one domain;
• the SPF record is syntactically incorrect;
• the number of DNS lookups involved in a single SPF check exceeds 10;
• the number of void lookups involved in a single SPF check exceeds 2;
• there is an exception in redirect.

We will go through these scenarios in this article one by one.

Multiple SPF records are found on one domain

Only one SPF record can be published on a domain or a subdomain; otherwise SPF returns a PermError. Learn more here: Can I Have Multiple SPF Records on My Domain?

For example, if you publish 2 completely valid SPF records on domain.com, SPF fails with a PermError for this reason:

v=spf1 a -all

v=spf1 mx -all

The solution to this problem is to keep only one valid SPF record with all the necessary mechanisms. For example, if both the a and mx mechanisms are required, you can update the first SPF record to:

v=spf1 a mx -all

and remove the second SPF record, then the issue is fixed.

The SPF record is syntactically incorrect

Your SPF record must be syntactically correct, otherwise SPF returns a PermError.

For example, there is an invalid mechanism in the following SPF record:

v=spf1 a im -all

As no im mechanism is defined in the SPF specification, it’s considered an invalid mechanism; therefore, the SPF record is syntactically incorrect.

To fix it, update im with a valid SPF mechanism or remove it altogether, depending on your actual needs.

The number of DNS lookups involved in a single SPF check exceeds 10

When SPF evaluates the SPF record on a domain, the number of mechanisms and modifiers that do DNS lookups must not exceed 10 per SPF check, including any lookups caused by the use of the «include» mechanism or the «redirect» modifier; otherwise, SPF returns a PermError.

For example, if a domain has an SPF record like this:

v=spf1 a mx include:bluehost.com ?all

SPF can fail with a PermError, as bluehost.com already contains 13 DNS lookups and that mechanism alone violates the 10-DNS-lookup limit in SPF.

You can use DMARCLY’s free SPF Record Checker to check your SPF record for this issue.

To fix it, use DMARCLY’s Safe SPF.

Refer to SPF PermError: Too Many DNS Lookups for more information.

The number of void lookups involved in a single SPF check exceeds 2

During an SPF check, if it’s unable to resolve the DNS host for a mechanism/modifier in the SPF record, it’s called a «void lookup». These mechanisms can be the «include», «a», «mx», «ptr», and «exists» mechanisms, and the «redirect» modifier.

SPF fails with a PermError if the number of void lookups involved in a single SPF check exceeds 2.

For example, if none of badhost1, badhost2, and badhost3 exists, and you have an SPF record as shown below:

v=spf1 a:badhost1 include:badhost2 exists:badhost3 -all

SPF will fail with a PermError, as the number of void lookups in the above record is 3.

To avoid this, either publish valid SPF records on those hosts, or remove them.

There is an exception in redirect

If a «redirect» mechanism is used in an SPF record, the target name of the mechanism must have an SPF record, otherwise SPF fails with a PermError.

For example, if your SPF record looks like this:

v=spf1 redirect=_spf.example.com

And if there is no SPF record on _spf.example.com, SPF fails with a PermError.

To avoid this, make sure your redirect mechanism points to a target name with a valid SPF record on it. In the case above, publish an SPF record on _spf.example.com.

To learn more about SPF authentication results, refer to Why SPF Authentication Fails.

Have you ever seen an email fail SPF? If you have, then I’m going to tell you exactly why SPF authentication fails. Sender Policy Framework, or SPF, is one of the email verification standards we’ve all used for years to stop spam. Even if you weren’t aware of it, I’ll bet if I checked your login account settings for Facebook it would likely show you “opt-in” to “email from friends only”. That is effectively the same thing as SPF.

What is SPF Authentication?

SPF is an email authentication protocol that is used to verify that the email sender matches with their domain name in the From: field of the message. The sending MTA will use DNS to query a preconfigured list of SPF servers to check if the sending IP is authorized to send email for that domain. There may be inconsistencies in how SPF records are set up, which is critical to understanding why emails can fail SPF verification, and what part you can play to ensure issues don’t occur in your own email marketing efforts.

Why SPF Authentication Fails : None, Neutral, Hardfail, Softfail, TempError, and PermError

SPF authentication failures can happen due to the following reasons:

• The receiving MTA fails to find an SPF record published in your DNS
• You have multiple SPF records published in your DNS for the same domain
• Your ESPs have changed or added to their IP addresses which have not been updated on your SPF record
• If you exceed the 10 DNS lookup limit for SPF
• If you exceed the maximum number of permitted void lookup limit of 2
• Your flattened SPF record length exceeds the 255 SPF characters limit

Given above are various scenarios of why SPF authentication fails. You can monitor your domains with our DMARC analyzer to get reports on SPF authentication failures. When you have DMARC reporting enabled, the receiving MTA returns any one of the following SPF authentication failure results for the email depending on the reason for which your email failed SPF. Let’s get to know them better:

Types of SPF Fail Qualifiers

The following are types of SPF Fail qualifiers each of which is added as a prefix before the SPF fail mechanism:

“+” “Pass”
“-” “Fail”
“~” “Softfail”
“?” “Neutral”

How do these matter? Well in a situation your email does fail SPF, you can choose how stringently you want receivers to handle it. You may specify a qualifier to “pass” messages that fail check (deliver them), “Fail” delivery, or take a “Neutral” standpoint (do nothing).

Case 1: SPF None result is Returned

In the first case scenario,- if the receiving email server performs a DNS lookup and is unable to find the domain name in the DNS, a none result is returned. None is also returned in case no SPF record is found in the sender’s DNS, which implies that the sender doesn’t have SPF authentication configured for this domain. In this case SPF authentication for your emails fails.

Generate your error-free SPF record now with our free SPF record generator tool to avoid this.

Case 2: SPF Neutral Result is Returned

While configuring SPF for your domain, if you have affixed a ?all mechanism to your SPF record, this means that no matter what the SPF authentication checks for your outbound emails conclude, the receiving MTA returns a neutral result. This happens because when you have your SPF in neutral mode, you are not specifying the IP addresses that are authorized to send emails on your behalf and allowing unauthorized IP addresses to send them as well.

Case 3: SPF Softfail Result

Similar to SPF neutral, SPF softfail is identified by ~all mechanism which implies that the receiving MTA would accept the mail and deliver it into the inbox of the recipient, but it would be marked as spam, in case the IP address is not listed in the SPF record found in the DNS, which can be a reason why SPF authentication fails for your email. Given below is an example of SPF softfail:

 v=spf1 include:spf.google.com ~all

Case 4: SPF Hardfail Result

SPF hardfail, also known as SPF fail is when receiving MTAs would discard emails originating from any sending source that is not listed within your SPF record. We recommend you to configure SPF hardfail in your SPF record, if you want to gain protection against domain impersonation and email spoofing. Given below is an example of SPF hardfail:

v=spf1 include:spf.google.com -all

Case 5: SPF TempError (SPF Temporary Error)

One of the very common and often harmless reasons why SPF authentication fails is SPF TempError (temporary error) which is caused due to a DNS error such as a DNS timeout while an SPF authentication check is being performed by the receiving MTA. It is, therefore, just as the name suggests, usually an interim error returning a 4xx status code that can cause temporary SPF failure, however, yielding an SPF pass result when tried again later.

Case 6: SPF PermError (SPF Permanent Error)

Another common result that domain errors are faced with is SPF PermError. This is why SPF authentication fails in most case scenarios. This happens when your SPF record gets invalidated by the receiving MTA. There are many reasons why SPF might break and be rendered invalid by the MTA while performing DNS lookups:

• Exceeding the 10 SPF lookup limit
• Incorrect SPF record syntax
• More than one SPF record for the same domain
• Exceeding the SPF record length limit of 255 characters
• If your SPF record is not up to date with changes made by your ESPs

Note: When an MTA performs an SPF check on an email, it queries the DNS or conducts a DNS lookup to check for the authenticity of the email source. Ideally, in SPF you are allowed a maximum of 10 DNS lookups, exceeding which will fail SPF and return a PermError result.

How Can Dynamic SPF Flattening Resolve SPF PermError?

Unlike the other SPF errors, SPF PermError is much more tricky and complicated to resolve. PowerSPF helps you mitigate it easily with the help of automatic SPF flattening. It helps you:

• Stay under the SPF hard limit
• Instantly optimize your SPF record
• Flatten your record to a single include statement
• Make sure your SPF record is always updated on changes made by your ESPs

Want to test if you have SPF configured correctly for your domain? Try out our free SPF record lookup tool today!

SPF SoftFail – Everything that Causes an SPF Fail

SPF is an important email authentication protocol that reduces the number of spammers that succeed on the web. SPF failure occurs when your record is not set up properly among other reasons.

Is your SPF Record Set Up Correctly?

Read this article to learn more about SPF, SPF failures, how to avoid them, and how SPF authentication affects DMARC.

What is SPF?

SPF (Sender Policy Framework) is an email authentication protocol that explicitly lists different servers and applications that are allowed to send emails from your domain.

Sender Policy Framework has helped protect millions of domains against email spoofing and prevents legitimate outgoing email messages from being marked as spam.  SPF, along with DKIM, DMARC, and BIMI make up the building blocks of email authentication.

Your SPF record is like your car’s insurance policy. Try to visualize your sending domain as a new car. Before you start driving your car, you need to make sure you have valid insurance that covers everyone who will be driving your car.

How Does SPF work?

SPF is a TXT record that is published in your domain’s DNS settings.

Every time you send emails, they have to first travel through the receiving servers’ spam filters and firewalls. This is similar to going through a police checkpoint. The “police officer” will check your driving record to see if you have valid insurance (or SPF record). If you do, they’ll determine whether or not you’re allowed to drive your vehicle based on your insurance policy and whether you’re listed as an authorized driver.

Like the above example, when a sender sends an email message, the receiving mail server will perform a DNS lookup on the envelope sender “From” address of the message to find out if the senders IP address or email service provider is allowed to send mail on behalf of that domain. If the IP address is listed as a valid email sender in your SPF policy, authentication will pass.

If the sender’s IP address is not listed in your SPF record, then your SPF authentication fails and your email is less likely to reach its destination. Many internet service providers (ISPs) may blacklist any IP addresses where SPF fails too often in order to prevent email spoofing and unauthorized IPs from abusing that domain’s reputation.

What does an SPF Failure Mean?

Authenticating your email is easy enough when everything is in place and SPF passes. However, it gets a bit tricky when SPF authentication fails. SPF soft fails can be due to any of the following reasons.

SPF failure occurs when:

• your domain has multiple SPF records
• mail servers were unable to resolve the domain name in the DNS
• your record exceeded the 10-DNS-lookup limit
• A single SPF check involves more than two void lookups.
• A receiving email server is unable to find the SPF record for the domain listed
• the SPF record does not have correct syntax
• the IP address is not on the list specified in the SPF record

If any of the statements above are true, SPF authentication will respond with one of the following results and then is passed on to DMARC:

• none
• neutral
• SPF soft fail
• fail, or SPF hard fail;
• temperror, or temporary error
• permerror, or permanent error

What is an SPF soft fail?

An SPF soft fail is a status result that means that the senders IP address is probably not authorized. The domain owner has not issued a more definitive restriction that results in a stronger “fail.” This is can be accomplished by adding an ~all mechanism to your SPF record.

Therefore, any IP address that is not listed in your SPF policy will result in a soft fail.

An SPF soft fail may be viewed as a pass or fail, depending on how you configure DMARC in your email server.

SPF soft fail example:

v=spf1 ip4 142.456.22.56 ~all

What is an SPF hard fail?

An SPF fail, or SPF hard fail, occurs when the IP address that the emails’ originating from is not listed as an authorized sender.

To ensure that only the IP address authorized can send emails, add an -all mechanism to your SPF record. Any unauthorized servers will trigger SPF to fail and the email messages can be discarded altogether.

An SPF failure will also fail in the DMARC SPF alignment so it’s important to publish your SPF record with the correct sending IP and email servers to prevent a hard fail.

SPF hard fail example:

v=spf1 ip4 132.45.55.65 -all

What is the difference between an SPF soft fail and an SPF hard fail?

The main difference between the two is pretty simple. Is it listed on your SPF record? 

SPF Hardfail vs SPF Softfail

SPF Hard Fail

Hard fails can cause emails to be blocked completely. If you send emails from a server that’s not listed in the SPF record, your emails may be discarded altogether and fail SPF. 

SPF Softfail

Soft fails can cause emails to get marked as spam or flagged as suspicious.

What are other SPF Failures?

SPF None

If there is no SPF record present, or if the SPF record does not explicitly define a policy for the given domain, then this will also result in a failure.

SPF none is also treated as a fail in DMARC authentication; the SPF check failed, therefore, DMARC fails. Likewise, if your DKIM authentication fails, it fails the final DMARC authentication check as well.

To fix this, publish a valid SPF record for your domain:

How to Deploy SPF Email Authentication

SPF Neutral

SPF neutral is when the SPF record for your domain explicitly states that it cannot confirm whether the IP address is authorized. A neutral result can be achieved by adding an ?all keyword to your SPF record. Any IP address will result in a neutral result when this mechanism is applied.

DMARC authentication can interpret SPF neutral as either pass or fail, depending on how you set up DMARC on your email server.

SPF PermError (SPF Permanent Error)

SPF PermError often happens when a single domain has multiple SPF records, a syntax error occurs, or if your record exceeds the 10-DNS-lookup limit.

SPF TempError (SPF Temporary Error)

SPF TempError (temporary error) is caused by a DNS error such as DNS timeout during an SPF authentication check conducted by the receiving servers.

If a user experiences a temporary error while trying to send an email, they will be prompted to retry. However, the success of this second attempt depends on how the initial policy is set up. For example, if there is an SPF temperror, the SMTP command will return with a 4xx status code.

How do I Avoid SPF Failures?

You can avoid SPF (Sender Policy Framework) failures by making sure that your SPF record lists every tool and application you will be using to send emails from your own domain.

You can also use our Uptime Monitor to get notified as soon as any emails fail SPF, DKIM, or DMARC records. This will help you stay out of spam and improve your email deliverability.

How can I Monitor SPF Failures?

There are a few tools that allow you to monitor your SPF along with your DKIM, DMARC, IP Blacklists, and more. These tools were created to help you improve your email deliverability with a proactive approach.

To prevent SPF failures, use our free DMARC analyzer to ensure all of your emails are properly authenticated and reach your customers.

Learn More about SPF:

How the New Email Uptime Monitoring Helps with Multiple SPF Records
How to Catch Spoofing Attack in 2021
How to Deploy SPF Email Authentication
How to Optimize Your SPF Record
Improving Email Deliverability Using MX, SPF and PTR Records
What is DMARC: Email Security with DMARC, SPF, and DKIM