As part of evaluating whether an email message passes SPF authentication, a receiving mail server may have to make one or more DNS lookups. According to RFC7208 Section 4.6.4*, SPF limits the amount of DNS lookups per SPF verification to 10. Let's take a look at how this limit may affect you and how you can adapt to it.
A Request for Comments (RFC) is a publication in a series, from the principal technical development and standards-setting bodies for the Internet, most prominently the Internet Engineering Task Force (IETF)
What is a SPF DNS lookup?
A DNS lookup is the process by which a DNS record - in this case the SPF record -is returned from a DNS server. For each DNS verification brought about by your SPF record, a DNS lookup is counted. Other SPF records that you may have included (by the"Include" mechanism ) in your SPF are looked up the same way.
A DNS redirect is therefore counted for each SPF mechanism used in your SPF record:
- Include
- MX
- PTR
- A
- Redirect
- Exists
For example, microsoft.com's SPF has exactly 10 DNS lookups:
v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com include:_spf1-meo.microsoft.com -all
What happens if the 10 lookup limit is exceeded?
If more than 10 DNS lookups are required, the result of the SPF check will be wrong. This can have a negative effect on the deliverability of your emails which may be considered as spam.
What should I do to avoid exceeding the 10 DNS lookup limit?
There are several options available to you to avoid the inconvenience of an SPF exceeding the 10 "lookups" limit. Here is what we recommend to our clients in order of preference :
- Clean up your SPF. Use our DMARC report analysis tool to identify unused SPF records and remove them from your SPF. Overly large IP spaces for domains will get your domain SPF reputation discounted in the Google spam filter => prefer a custom value containing your IPs only
- When possible, use IP addresses in your SPF. The verification of your SPF by your recipients anti-spams will be much faster, which will decrease the possible DNS errors (don't forget that the DNS protocol is based on UDP, a protocol subject to network packet loss!);
Whenever possible, try to dedicate domains or subdomains to your different email solutions. This will make it easier to manage the SPF of your root domain and your subdomains. Dedicating a sub-domain to each email solution also helps protect the email reputation of each of these domains. Constrained in its own subdomain, your e-mail marketing solution will not be able to degrade the e-mail reputation of your top domain or your transactional e-mail domains.
Have you noticed?
We are not talking about SPF flatteners or SPF Macros, managed by a third party and supposedly boosted with artificial intelligence.
The benefits of using these solutions, promoted and implemented by companies known to this market, are not obvious to us. To illustrate our point, we will list three advantages put forward by these companies and we will look at what the organizations most concerned by these issues, and at the cutting edge of technology, are doing for their own SPF.
1/ The use of SPF macros makes it possible to hide the list of authorized senders from hackers
The NSA doesn't seem to care.
On the other hand, the use of SPF macros hides the list of authorized senders from the right actors such as incident response teams, or in many cases, these SPF macros, SPF flatteners, or Hosted SPF do not allow "cloud" solutions sending emails to check that the SPF has been configured correctly, which may create alerts in the "Dashboard" configuration of these solutions, or even make it impossible to send emails with your domains
2/ The use of SPF macros makes it possible to bypass the limits of SPF "includes", and to improve the performance of requests:
Google, Microsoft and Mailchimp send out a lot of emails and yet they don't seem to use these solutions, so why should you need them?
3/ The use of SPF macros makes it possible to tight control of the sender's permissions
The NSA doesn't seem to care.
On the other hand, by blindly trusting a semi-automated solution, you take the risk of authorizing the whole world to send e-mails on your behalf, with just one click, under the guidance of a robot boosted by artificial intelligence. On this side, the risks outweigh the benefits.
Finally, SPF authentication is not always possible. SPF flatteners and other SPF macros will not help you configure DKIM on a mailchimp, sendgrid, amazonses, postfix, ironport, etc. system. Manual interventions, in collaboration with the teams in charge of these systems and DNS, will remain mandatory.
Why add a second "point of failure" to your registration, with an additional tool that has its own intrinsic risks: availability, DNS information updates, knowledge management and user training, etc.?
Everything that is done for me, without me, is done against me. - An African proverb
A solution that wants to manage (or host) your SPF, for you, is a solution that may try to make you lose control of your SPF. In any case, it is a solution that will be difficult to decommission if the need arises, a need often linked to prohibitive prices.
Do you have questions about your SPF and email authentication? We can offer you the tools and advice to implement SPF/DKIM/DMARC with peace of mind.