DMARCLY

Everything about DMARC, DKIM, SPF, email authentication, deliverability, anti-spoofing, anti-phishing, security, and tools.

SPF PermError: Too Many DNS Lookups - When SPF Record Exceeds 10-DNS-Lookup Limit

"SPF PermError: too many DNS lookups" is a common error seen in many SPF 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 many 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 <= 10.

But I can't. I have so much stuff in my SPF record!

I understand - nowadays almost every company outsources essential services to 3rd-party service providers, like email delivery, marketing, and more. Putting an 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.

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 down to 1, far below the limit.

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 count is decremented by 1. After all such mechanisms/modifiers are replaced, the total count becomes 1 - only the topmost SPF record needs a DNS query.

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 at 1, without having to worry about manually flattening the SPF record and updating it in the DNS at all!

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 DNS-querying mechanism/modifier;
  • it is always updated when the underlying IP addresses change;
  • there is zero maintenance on your side.

Protect Your Business Email

Get a 14 day trial. No credit card required.

Create Account
Need to fix the "SPF PermError: too many DNS lookups" issue? Check out this post: Want to get the ultimate DMARC guide? Click the link below:
How to Set Up Sender Policy Framework (SPF): the Complete Guide What is DMARC Identifier Alignment (domain alignment)?
Blog Comments powered by Disqus.