What is the SPF 10 DNS lookup limit?

RFC 7208 limits SPF records to a maximum of 10 DNS lookups during evaluation. Each 'include', 'a', 'mx', and 'redirect' mechanism counts as one lookup. If your record exceeds 10 lookups, receiving servers return a PermError and SPF fails entirely.

How do I check how many SPF lookups my domain uses?

Use MailShield's free SPF checker to see your total lookup count. It follows the entire include chain and shows you exactly how many lookups each mechanism costs, so you know which includes to optimize.

Does flattening SPF records fix the lookup limit?

SPF flattening replaces include mechanisms with their resolved IP addresses, reducing lookup counts. However, flattened records need to be updated whenever the provider changes their IP ranges, which happens frequently. It's a maintenance burden and can break if not kept current.

All posts

Technical

SPF "Too Many DNS Lookups" — How to Fix It

April 2, 20268 min

Your SPF record just broke, and you probably don't know it yet. The error is "Too many DNS lookups" (also called PermError), and it's the single most common SPF issue we encounter. When it happens, your entire SPF authentication fails silently. Every email you send fails the SPF check, and most sending tools won't tell you about it.

The SPF specification (RFC 7208) limits DNS lookups to 10 per evaluation. This limit exists to prevent denial-of-service attacks through recursive DNS queries, but in practice it's the bane of every growing organization's email setup.

What counts as a DNS lookup?

Not everything in your SPF record uses a lookup. Here's what counts and what doesn't:

Counts: include, a, mx, ptr, redirect, exists. Each of these triggers a DNS query.
Does NOT count: ip4, ip6, all. These are evaluated directly without DNS.

The critical trap: includes are recursive. If you include a domain that itself has 3 includes, that's 4 lookups total (1 for the include + 3 for the nested includes). You need to follow the entire chain.

How to count your lookups

Let's walk through a real example. Say your SPF record is:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.mailchimp.com ~all

That looks like 4 lookups. But Google's SPF record includes 3 more domains. Outlook includes 2 more. SendGrid includes 1 more. You're already at 10 or 11 lookups, and you haven't even added your helpdesk or billing tool yet.

The moment you exceed 10, your SPF evaluation returns PermError. Not SoftFail, not Neutral. A permanent error that fails authentication entirely.

How to fix it

There are several strategies, and you'll likely need a combination:

1. Remove unused includes

This is the easiest fix. Review every include in your SPF record. Do you still use that marketing platform? Did you switch email providers but leave the old include? Each unused include wastes a precious lookup. Check your DMARC reports to see which services actually send email as your domain.

2. Replace includes with IP addresses

If a service sends from a small, stable set of IP addresses, you can replace the include with explicit ip4 or ip6 mechanisms. IP mechanisms don't count against the 10-lookup limit.

Be careful: only do this for services whose IPs rarely change. Cloud email providers rotate IPs frequently, so includes are still the right approach for them. This works best for your own infrastructure.

3. Consolidate with a subdomain

Move some senders to a subdomain (e.g., mail.yourdomain.com for transactional email, news.yourdomain.com for marketing). Each subdomain gets its own SPF record with its own 10-lookup budget. This is the most sustainable long-term solution for organizations with many senders.

Make sure each subdomain also has its own DMARC record, or it will inherit the parent domain's policy.

4. SPF record flattening (use with caution)

SPF flattening resolves all includes to their underlying IP addresses and publishes them directly. This eliminates nested lookups entirely.

The problem: when the underlying IPs change (and they will), your flattened record becomes stale. You'd need to re-flatten regularly and update DNS. Some third-party tools automate this, but it adds a dependency and a point of failure. We generally recommend subdomain delegation over flattening.

Preventing future problems

The real solution is continuous monitoring. Every time someone on your team adds a new SaaS tool that sends email, they need to add an SPF include. Without monitoring, nobody knows when the 10-lookup limit gets crossed.

Monitor your lookup count continuously and alert before you hit 10
Require approval before adding SPF includes, just like you'd review a firewall rule change
Audit your SPF record quarterly: remove services you no longer use
Consider subdomain delegation proactively before you hit the limit

How MailShield helps

MailShield counts your SPF lookups in real time and follows the entire include chain. We show you exactly how many lookups each include costs, which services are using them, and how close you are to the limit. The moment you hit 10, we alert you immediately.

Add your domain to MailShield for free and see your current SPF lookup count in under a minute. If you're already over the limit, we'll show you exactly what to remove or restructure.