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)

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

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.

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 :

1. Clean up your SPF. Use our DMARC report analysis tool to identify unused SPF records and remove them from your SPF;
2. 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!);

3. 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.

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.?

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.