SPF 10 Lookup Limit Checker

Q: What counts toward the SPF 10 lookup limit?

include , a , mx , ptr , exists , and redirect count because they can require DNS queries. Nested includes count when evaluated. ip4 , ip6 , all , and exp do not count toward the 10.

Q: What happens if SPF uses more than 10 lookups?

SPF evaluation returns permerror . Receivers can treat that as authentication failure, which can push mail toward spam, junk, or rejection when other signals are weak.

Q: Is -all better than ~all?

-all is stricter. Use it after you know real senders pass SPF or aligned DKIM and your DMARC reports are clean. Use ~all while you are still auditing sources.

InboxRadar grades your email deliverability free and emails you when it changes. Check your domain.

SPF breaks at lookup number 11

One extra include can make a normal-looking SPF record fail during the receiver's check.

An SPF 10 lookup limit checker counts the DNS-querying terms a receiver may need when it tests your SPF record. RFC 7208 sets the limit at 10 during one SPF evaluation. If the count goes over 10, SPF returns permerror. That means the receiver could not interpret the domain's SPF policy. Gmail, Outlook, and other mailbox providers can treat that as failed authentication, then use reputation and other signals to decide whether to spam, junk, or reject the message.

The SPF terms that count are include, a, mx, ptr, exists, and the redirect modifier. Nested includes count when they are evaluated. ip4, ip6, all, and exp do not count toward the 10 because they do not cause DNS queries during SPF evaluation. ptr is slow and discouraged. mx and a can be expensive because each name can lead to more address lookups. A useful checker follows the paths a receiver may evaluate instead of counting only the first TXT record.

What a checker should show

A pass or fail label is too thin. You need the path that spent the lookups.

Find the single SPF TXT record at the root sending domain.
Flag more than one SPF record, because SPF returns permerror when a check selects multiple records.
Follow each evaluated include and redirect, including nested records.
Count a, mx, ptr, and exists only on paths that can be evaluated.
Warn when mx or ptr creates extra address lookups.
Show unused or duplicate senders so you can remove them with less risk.
Warn when the record ends in +all, because that authorizes any sender.

InboxRadar's free domain scorecard reads SPF, DKIM, DMARC, and MX records and points to the records most likely to hurt delivery. For this specific problem, the key output is the lookup path and the first place the count can cross 10.

How to fix an SPF record over the limit

Start by removing senders. Flattening can help, but it creates a new job: keeping IP ranges fresh.

Keep one SPF record. Remove old email platforms, unused CRMs, abandoned help desks, and duplicate includes. If two tools send through the same provider, you may need one include instead of two. Avoid ptr. Be careful with mx if your MX hosts point through a large mail service. Use direct ip4 and ip6 ranges only when the provider gives you stable ranges and supports that setup.

Use ~all while you are auditing and moving senders. Move to -all after real senders are covered by SPF or pass aligned DKIM, and your DMARC aggregate reports show clean results. A hard fail is useful after cleanup. It is risky while you are still finding mail sources.

Do not flatten blindly. Flattening replaces includes with IP ranges. Those ranges can change without warning, so a flattened record needs monitoring. If a vendor publishes an SPF include, that include is usually the source of truth unless the vendor also publishes stable IP ranges for direct use.

SPF is only one inbox signal

A clean SPF record removes one common failure. It does not erase sender reputation.

DKIM signs selected message headers and body content with a private key. The selector in the DKIM signature tells receivers where to find the public key in DNS. That lets the receiver check that signed content was not changed and that the signing domain takes responsibility for the message.

DMARC checks whether SPF or DKIM passes and aligns with the visible From domain. Its policy asks receivers how to handle mail that fails DMARC: p=none for monitoring, p=quarantine to ask for suspicious handling, and p=reject to ask for refusal. Receivers can still use local judgment. Read aggregate rua reports before tightening policy. A free DMARC report reader can turn those XML files into sender names and pass rates.

Gmail's sender guidelines require SPF or DKIM for all senders and SPF, DKIM, and DMARC for bulk senders. Microsoft 365 also weighs SPF, DKIM, DMARC, sender reputation, sender history, recipient history, and behavior signals. Complaints, bounces, bad links, sudden volume spikes, compromised hosts, and blocklists can still move mail to spam even when DNS is correct.

AI search is a separate check

Email DNS tells inboxes who may send as you. AI-search crawlability tells answer engines whether they can reach and read your site.

The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Google AI Overviews use the normal Google Search index. There is no separate Google AI Overviews opt-out crawler. Disallowing these crawlers in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

Robots.txt is a site's stated policy, not proof of what a bot did. Perplexity-User and Bytespider are reported to ignore it, so do not claim either bot's behavior from robots.txt alone. Only Googlebot documents JavaScript rendering. If key content appears only after client-side JavaScript runs, treat that as an undocumented risk for other AI crawlers and check the page with the free AI visibility checker.

Sources to trust when records disagree

Use vendor docs and the email RFCs as the source of truth. Blog posts get stale.

For SPF, check RFC 7208. For DKIM, check RFC 6376 and later DKIM crypto updates when key or algorithm details matter. For DMARC, check RFC 7489. For delivery requirements, use the current Google sender guidelines and Microsoft email authentication docs. For AI crawler controls, use the vendor docs from OpenAI, Anthropic, Perplexity, Google, Apple, and Common Crawl.

The steady fix is simple: authenticate the domain, sign with DKIM, publish DMARC, send wanted mail, keep lists clean, and watch for DNS drift. If a vendor changes its SPF include and pushes you over 10, you want to know before a launch or billing notice goes out. Related deliverability guides live at the guide library.

Common questions

What counts toward the SPF 10 lookup limit?

include, a, mx, ptr, exists, and redirect count because they can require DNS queries. Nested includes count when evaluated. ip4, ip6, all, and exp do not count toward the 10.

What happens if SPF uses more than 10 lookups?

SPF evaluation returns permerror. Receivers can treat that as authentication failure, which can push mail toward spam, junk, or rejection when other signals are weak.

Should I flatten my SPF record?

Only when removing unused senders is not enough. Flattening replaces includes with IP ranges, but those ranges can change. If you flatten, monitor the record and update it when the provider changes its sending IPs.

Is -all better than ~all?

-all is stricter. Use it after you know real senders pass SPF or aligned DKIM and your DMARC reports are clean. Use ~all while you are still auditing sources.

Can DKIM or DMARC fix an SPF lookup failure?

DKIM can still pass when SPF fails, and aligned DKIM can satisfy DMARC. That is why every sending domain should have DKIM and DMARC. SPF should not be your only control.