SPF DNS Lookup & SPF Macro

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 SPF (Sender Policy Framework) DNS lookup is a process in which a recipient's email server looks up the SPF record for a domain in order to verify the identity of the sender of an email message.

When an email message is received, the recipient's email server will check the domain of the sender's email address against the SPF record for that domain. The SPF record is a DNS (Domain Name System) record that is published by the domain owner and contains information about which IP addresses and systems are authorized to send email on behalf of the domain.

For each DNS verification performed by your SPF record, a DNS lookup is counted. Other SPF records that you may have included in your SPF record (by the "include" mechanism) are looked up in 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. 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
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 referring to third-party managed SPF flatteners or SPF Macros that claim to be enhanced with artificial intelligence. We are uncertain about the benefits of using such solutions, which are promoted and implemented by well-known companies in this industry. To support our argument, we will outline three benefits advertised by these companies and examine what organizations that are at the forefront of technology and most affected by these issues are doing to manage 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 seeks to manage or host your SPF on your behalf may attempt to take control of your SPF, making it difficult for you to retain authority over it. Furthermore, it could be challenging to discontinue this solution if necessary, which is often due to its exorbitant cost.

While our suggestions are not entirely in line with all DMARC solutions that provide an "easy SPF lookup reducer," our aim is to safeguard the long-term reputation and security of your email streams and help maintain a concise SPF record (since Google disfavors lengthy SPF records). Therefore, we are providing vendor-neutral articles to assist you in comprehending our recommendations better :

https://docs.rackspace.com/support/how-to/managing-domain-reputation/

https://www.mailgun.com/blog/deliverability/the-basics-of-email-subdomains/

https://postmarkapp.com/guides/how-to-improve-domain-reputation-for-better-email-deliverability

https://blog.kickbox.com/sending-domains-to-subdomain-or-not-to-subdomain/

https://www.proofpoint.com/us/blog/email-and-cloud-threats/proofpoint-discloses-valimail-spf-macro-vulnerability