SPF too many DNS lookups: how to diagnose and fix it

RFC 7208 caps every SPF record at 10 DNS lookups. Go over, and the record doesn’t just stop working — it fails silently, for everyone, with no error in your inbox to tell you.

If a tool you use for sending mail flagged your SPF record as invalid, or if mail from a domain that used to work is suddenly landing in spam with no clear reason, "too many DNS lookups" is one of the most common and most misunderstood causes. It's also one of the few SPF problems that gets worse purely by accident, over time, without anyone touching the record on purpose.

What the 10-lookup limit actually is

RFC 7208, the SPF specification, caps the number of DNS lookups a receiving mail server is allowed to perform while evaluating your SPF record at 10. Not 10 characters, not 10 IP addresses — 10 lookups, where a lookup is any mechanism that requires the receiving server to go query DNS again: include, a, mx, ptr, and exists all count. A bare ip4: or ip6: mechanism doesn't count, since it's already a raw address with nothing left to resolve.

Cross that limit, and the specification says the result is a permerror — not "some senders pass and some fail," but the whole SPF check becomes unusable, for every sender, for every message, until the record is back under 10. Most receiving mail systems treat a permerror roughly the same as an outright SPF fail. Nothing in your outbound tooling tells you this happened. The first sign is usually a slow decline in replies that nobody can explain.

How to count your current lookups

You can do this by hand in a few minutes:

1. Look up your domain's TXT record and find the one starting with v=spf1.
2. Count every include:, a, mx, ptr, and exists mechanism in that record.
3. For every include:, repeat the process on that domain's own SPF record — lookups nest. A single include:_spf.google.com can itself burn 4–5 of your 10 before you've added anything else.
4. Add it all up. If you're at 8 or more, you're one new tool away from a silent outage.

Public checkers (MXToolbox's SPF record check is a common one) will do this counting for you and flag nested lookups specifically — useful for a quick gut check, though they won't tell you which of your current includes are safe to remove versus load-bearing.

How to actually fix it

1. Remove what you don't use anymore

The fastest wins are almost always dead weight: a marketing tool you migrated away from two years ago, a duplicate include added by two different people who didn't know the other had already done it, an a or mx mechanism nobody remembers the reason for. Audit every mechanism against what's actually sending mail today before touching anything structural.

2. Consolidate redundant includes

If two tools both resolve through the same underlying sending infrastructure, you may only need one include, not two. This is worth checking with each vendor's documentation rather than assuming.

3. Flatten selectively, not wholesale

"SPF flattening" — replacing an include: with the literal IP ranges it currently resolves to — removes lookups entirely, but it's a real tradeoff: those IP ranges change on the vendor's side without notice, and a flattened record silently goes stale unless something re-flattens it on a schedule. Flattening your two or three highest-lookup-cost, most-stable vendors (not everything) is usually the better balance of safety and lookup savings.

4. Never run two SPF records

A domain is only allowed one SPF TXT record. If you find two, that's its own permerror, independent of lookup count — merge them into one before doing anything else.