Sender Policy Framework (SPF) is an open, DNS-based email authentication system that gives domain owners control over which IP addresses are allowed to deliver email on their behalf. However, SPF record lookup limitations often cause senders to fail SPF authentication—but most senders aren’t aware of the lookup limits or workaround solutions.
SPF isn’t supposed to be difficult to implement; it was designed to be straightforward.
Receiving mail servers check the SPF records for incoming messages, and if the delivering server has an IP address listed in the SPF rule set, the message is marked as authenticated.
It’s a simple standard that greatly improves email authentication, reducing spam and phishing attacks. It is easy enough to implement (or appears easy enough) that it is widely used.
Below, we’ll walk you through everything you need to know about SPF lookup limits to address issues with authentication. We’ll also go over how cybercriminals take advantage of the From: address—and (more importantly) what you can do about it.
The SPF 10-lookup limit
A receiving mail server may have to make one or more DNS lookups to evaluate whether an email message passes SPF authentication.
To protect receiving mail servers from denial of service attacks, the standard includes a hard limit on the number of domain lookups a server is permitted to make when evaluating whether an email message passes SPF. That SPF limit is 10 lookups.
Unfortunately, those SPF lookups can add up fast. For example, Google asks its customers to include the SPF record _spf.google.com in their individual domain SPF records. Looking up the contents of this record in DNS, we find that it includes three Google.com subdomains.
So a Google customer whose SPF includes the Google-recommended record will have a domain lookup count of four—one for the _spf.google.com lookup and one for each of the three Google subdomains referenced by the first lookup.
Now, imagine you want to include the records provided by several other email service providers—each of which may have several DNS lookups. The total domain count of the resulting record is just the sum of the individual contributions.
The SPF lookup limitation isn’t hard to reach
The SPF lookup limit wasn’t a problem when most companies operated their mail servers. However, companies now utilize third-party senders, and each one takes up 3 or 4 servers. You can max out the 10 lookups pretty quickly.
For example, your company may use Google Apps for Business, Workday, and Zendesk. All the cloud services include the ability to send emails on your behalf, which means you’ll need to add corresponding SPF records for each one. And each of those records may include multiple DNS lookups of their own.
Making matters worse, it’s not apparent when the SPF 10-lookup limit has been exceeded. SPF records consist of a set of rules, each one evaluated sequentially. If a message is validated by one of the rules defined early in the SPF record, the message will authenticate even though the SPF record as a whole is broken.
Messages which are intended to be authenticated by rules that appear later in the SPF record will fail because the receiver will stop evaluating the record before it reaches those rules.
How to deal with SPF lookup limits
Domain owners should limit the number of includes in the SPF records for their domains. And email service providers should not recommend or require domain owners to add an “include” directive unless absolutely necessary.
Some domain owners try to address this process with domain “flattening.” They replace some of the SPF record’s domain names with the corresponding servers’ IP addresses or ranges.
This gets around the lookup limit, but if these servers change IP addresses, someone in the organization has to manually update those IP addresses in the SPF records too. That’s a time-consuming and error-prone process—exactly the problem that DNS was designed to fix.
How cybercriminals take advantage of the From: address
SPF records apply to specific Return-Path domains—not the domain in the human-readable From address.
Unfortunately, that introduces another limitation.
Humans don’t generally pay attention to the Return-Path when reading emails. Instead, they look at the name and email address that appears in the From: field in their email client or Web-based email display.
That’s where Domain-based Message Authentication, Reporting, and Conformance (DMARC) comes in. It addresses this limitation in SPF by requiring a match (called “alignment”) between the address shown in the human-readable From field and the server authenticated by SPF.
In cases where SPF authenticates but the domain doesn’t match the From address, that SPF authentication will be discarded by DMARC, resulting in a non-authenticated email address.
In 2016, non-DMARC-authenticating emails started to appear differently in Gmail and Outlook. For instance, the company logo or avatar that usually displays alongside a person’s name may be replaced with a big question mark to signal that the email was not appropriately authenticated.
Implement SPF correctly without more work
Do you want to ensure you don’t have any problems with SPF record limitations or DMARC issues? Let us take email authentication off your plate. Partner with Valimail, and we’ll handle all your DMARC, DKIM, SPF, and BIMI needs.
Schedule a demo with our team to learn how to automate the process and better protect your domains from spoofing and phishing attacks.
