SPF Include Tree

⚙ DNS & authentication

Expand your SPF record — including every nested include and redirect — into a tree, and see exactly where your DNS lookups go.

No sign-up required Runs on our own infrastructure Also available via API
Try:

Runs on our diagnostic API. We don’t attach your input to an account for these free tools; short-lived rate-limit/security logs may exist, and requests are rate-limited per IP.

Most broken SPF records aren’t broken because of a typo — they’re broken because they quietly grew past the 10-DNS-lookup limit. The record still looks fine when you read it, but somewhere down inside a provider’s include is another include, and another, and the total tips over 10. At that point receivers stop evaluating and return permerror, and every message from your domain fails SPF — including the legitimate ones. This tool expands the whole record into a tree so you can see exactly where the lookups are going and which sender is eating your budget.

How the lookup count actually works

RFC 7208 caps the number of DNS-querying mechanisms a receiver has to resolve at 10. The ones that count are include, a, mx, ptr and redirect (and mx can multiply, since each returned host may need its own lookup). The trap is nesting: when you write include:_spf.google.com, that record itself contains several more includes, and every one of them counts toward your total. A record with just three or four provider includes can already be at eight or nine lookups before you’ve noticed. Note that ip4: and ip6: mechanisms cost nothing — they’re resolved from the record you already fetched.

What the tree shows you

  • Where the budget goes. Each branch is a lookup. If one provider accounts for five of your ten, that’s your consolidation target.
  • Void lookups. A branch that resolves to nothing — a stale include for a service you dropped, or a typo’d hostname. RFC 7208 also limits void lookups, and they’re pure waste.
  • Loops and dead ends. An include that eventually points back at itself, or a redirect chain that never terminates cleanly.

Fixing an over-limit record

Once you can see the tree, the fixes are the familiar ones — and the trade-offs matter:

  1. Remove senders you no longer use. The cheapest fix, and the most common one. Old ESP includes linger for years.
  2. Replace an include with explicit IPs. If a provider publishes stable ranges, swapping include: for ip4:/ip6: drops the lookup cost to zero. The trade-off: you now own the maintenance — if the provider changes IPs, your record goes stale and mail fails. Only do this where the provider documents fixed ranges.
  3. Consolidate overlapping includes or move a heavy, low-volume sender onto a dedicated subdomain with its own SPF record.
  4. Be cautious with “flattening” services. Automated SPF flatteners inline every provider’s current IPs into one record and re-check them on a schedule. That solves the lookup count, but it introduces a dependency on the flattener staying current — if it lapses, you’re silently authorising the wrong IPs.

When you’re done trimming, confirm the pass/fail verdict with the SPF Checker, regenerate a clean record with the SPF Generator, and make sure the whole stack lines up with the Email Health Check.

Frequently asked questions

Why does exceeding 10 lookups break SPF entirely?
RFC 7208 makes receivers return permerror past 10 lookups, and permerror is treated as failure. So going over knocks out SPF for all your mail, legitimate included.
Do ip4 and ip6 mechanisms count toward the limit?
No — only DNS-querying mechanisms (include, a, mx, ptr, redirect) count. ip4:/ip6: are free, which is why swapping an include for explicit ranges helps.
Is SPF flattening a good idea?
It fixes the count but adds a dependency — the flattener must keep re-checking provider IPs, or your record goes stale. Use it deliberately, and prefer trimming unused senders first.
What is a void lookup?
A DNS query in your SPF that returns nothing — usually a stale include or a typo. RFC 7208 limits them and they waste budget, so clearing them is an easy win.