Adding a new email service to a domain is a routine operation. You sign up for a transactional email provider, follow their setup guide, add their include: statement to your SPF record, and call it done. Three weeks later, a significant percentage of your transactional emails are being flagged as spam. The provider's dashboard shows messages being sent, but recipients see them in the junk folder or never receive them at all.
The problem is almost always the DNS lookup limit, and it was created the moment you added that new include: statement.
How SPF Records Work
An SPF record is a TXT record published at the root of your domain. It lists the mail servers authorized to send email on your behalf. The simplest form looks like:
v=spf1 include:_spf.google.com ~all
The include:_spf.google.com part tells receiving mail servers to look up Google's SPF record and accept whatever mail servers Google specifies as authorized. This is how email providers work -- instead of publishing a static list of IP addresses, they publish a hostname, and their SPF record defines which IPs are valid.
When a receiving mail server checks SPF for an incoming message, it follows this chain: your domain's SPF record references Google's record, which may reference other records, and so on. Each reference is a DNS lookup. The SPF specification in RFC 7208 limits this chain to 10 lookups total. Exceeding the limit causes the entire SPF check to return a permerror, which most receiving servers treat the same as a failure.
The Hidden Lookup Count
Here is the problem: most include: statements do not resolve to a single lookup. They resolve to several.
When you add include:_spf.mailprovider.com to your SPF record, that counts as one lookup. But when the receiving server fetches _spf.mailprovider.com, that record may contain its own include: statements. Each of those is another lookup. A single include: in your SPF record can consume three or four lookups once the full chain is resolved.
This means a domain with four email providers -- a corporate mail service, a transactional provider, a marketing platform, and a customer support tool -- can easily have a legitimate SPF record that exceeds the limit once all the chains are followed. From looking at your own record, it looks like four includes. From the perspective of a receiving mail server evaluating the SPF check, it may be 12 or 14 lookups.
The permerror is silent from the sender's side. Messages go out, the sending server reports delivery, but SPF validation on the receiving end fails permanently for every message.
Why Adding a New Provider Triggers the Problem
Adding a fifth provider to an already-tight SPF record is the tipping point. The record was technically within limits before -- perhaps at 8 or 9 lookups -- and adding one more include: pushed it over 10. Now every message from every provider fails SPF, not just messages from the new one.
This is why the deliverability problem appears suddenly and affects all your email services, not just the new one. It looks like the new provider is broken when the actual problem is the cumulative lookup count.
How to Check Your Current Count
Run a DNS Lookup on your domain and find the TXT record starting with v=spf1. Write down every include: statement. Then fetch each of those hostnames as a DNS TXT record and note any additional include: statements. Continue recursively until you have traced every branch.
Count the total number of DNS queries you performed. If it is above 10, your SPF record has a permerror waiting to happen, or is already causing one.
For domains with complex SPF records, this manual trace is tedious. Several online tools can automate it -- they fetch and walk the entire chain and report the total lookup count. The IANA DNS root zone records provide authoritative information about how DNS delegation works if you want to understand the resolution process in more depth.
Fixing a Lookup-Limit Problem
The standard solution is SPF flattening. Instead of publishing include: statements that require real-time DNS lookups, a flat SPF record contains the actual IP addresses and ranges that are authorized to send email for the domain. The record requires no lookups to evaluate beyond the initial fetch.
A flat SPF record for a domain with three providers might look like:
v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.0/22 ip6:2001:db8::/32 ~all
The limitation of flattening is maintenance. When a provider changes their IP ranges -- which they do periodically -- your SPF record becomes inaccurate until you update it. Services that automate SPF flattening periodically re-fetch the provider chains and update the flat record when IP ranges change.
The alternative to full flattening is to remove providers you no longer actively use. Every email service added to SPF for a past integration that is no longer in use is consuming lookup budget unnecessarily. Auditing the include: list against active providers and removing stale entries often brings the count back within limits without any flattening needed.
What DMARC Reports Tell You
If you have DMARC configured with aggregate reporting (rua=), the daily reports from participating receivers show whether messages from each source are passing or failing SPF. A provider that appears in the DMARC report as failing SPF across 100% of its messages is a clear signal of an SPF problem for that source.
DMARC aggregate reports are XML files that most receiving providers (Gmail, Yahoo, Outlook) send automatically to the address in your rua= field. Parsing them manually is tedious, but several free services aggregate and visualize them. The DMARC standard is defined in RFC 7489.
"SPF is the authentication layer that looks simple until you have more than two email services on a domain. The lookup count problem is invisible until it is already affecting deliverability, which is why we always run an SPF audit before adding any new sending service to a domain." - Dennis Traina, founder of 137Foundry
Preventing Future Problems
Once you have fixed the SPF lookup count, build a process that prevents the problem from recurring. Document the current SPF record and its lookup count. When adding a new email service, check the total count before publishing the new record. If adding the service would push the count above 8, consider whether flattening or removing a legacy provider is the right move first.
The full guide to DNS lookups and email diagnostics covers SPF alongside DKIM, DMARC, and MX record checks. The DNS Lookup on EvvyTools shows all TXT records for a domain in one query, which is the first step in diagnosing any SPF problem. The EvvyTools tools directory includes additional developer and network diagnostic utilities.
SPF problems are entirely preventable. The lookup limit is a known constraint, and auditing your record before adding a new provider takes less than five minutes.
The DNS layer is often the last place developers look when email deliverability problems appear, but it is almost always the right place to start. SPF, DKIM, and DMARC are all DNS-based, and every authentication failure traces back to a record that is missing, malformed, or misconfigured. Maintaining an accurate map of which providers are authorized in your SPF record -- and verifying the full lookup chain before each change -- is the simplest form of email infrastructure hygiene. The 10-lookup limit is fixed; your job is to stay well within it.
Photo by lrobertson on Pixabay
Top comments (0)