There is a limit often overlooked in an SPF setup: the 10-DNS-lookup limit, aka the SPF lookup limit. When this SPF lookup limit is exceeded, SPF returns a PermError, which can affect your email deliverability.
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". Why does it happen, what are the consequences, and how can you fix it?
What is SPF lookup limit?
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.
This limit is imposed on the receiving email server side.
Why impose SPF 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
- he then sends a lot of emails from
malicious.comto mailboxes hosted by different email service providers (ESP) with SPF implemented;
- upon receiving such an email, the ESP queries the DNS for
- since many ESP's are involved, they amplify this traffic; this effectively turns into a DoS attack at
- what's more, the true source of the attack is hidden.
As your 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 this limit?
You can use our SPF lookup tool to check your SPF 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 lookup count of 10:
I suggest you to run a similar check on your domain, and see what the number looks like.
What happens if it exceeds this 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 a PermError. Depending on the email server's settings, the email might or might not land in the inbox.
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, your 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 is the IP addresses by flattening the SPF record on
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!
Probem 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 for a second!
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