SPF "too many DNS lookups": what it means and how to fix it

An SPF record is only allowed to trigger 10 DNS lookups. Go over, and SPF returns a PermError, and many servers then treat your SPF as if it doesn't exist. It's a common way for a setup that looks fine to quietly stop protecting you.

What the 10-lookup limit is

To evaluate SPF, a receiver resolves every mechanism that points elsewhere in DNS. RFC 7208 caps that at 10 lookups. The count is cumulative: each include: pulls in that provider's record, which often has its own includes — and they all count.

These cost a lookup: include:, a, mx, ptr (avoid it), exists:, and redirect=. These do not: ip4:, ip6:, all, exp=.

Why it silently breaks mail

Past the limit, SPF returns PermError. Receivers treat that as a broken record — no protection, and your real mail can fail SPF alignment, dragging down DMARC too. Nothing announces it: you add one more SaaS tool, tip past 10, and weeks later wonder why deliverability slipped.

How to check your count

An SPF checker (search "SPF record check") shows the exact count and flags when you're over. To see the raw record:

# Windows
nslookup -type=txt yourdomain.com

# Mac / Linux
dig txt yourdomain.com +short

Find the v=spf1 line and count the lookup-causing mechanisms — remembering each include: can hide several more.

Why it happens

Almost always: too many senders, each with its own include — M365 or Google Workspace, plus a marketing platform, CRM, invoicing tool, help desk, and a transactional service. Five visible includes can easily be twelve real lookups.

How to fix it (in order)

Audit your senders and remove includes for tools you no longer use.
Replace includes with direct IPs where a sender publishes stable ranges.
Delegate bulk mail to a subdomain (mail.yourdomain.com) with its own SPF.
Flatten with care — expanded IPs cut lookups but change without warning, so a flattened record must be monitored or it silently fails.
Keep headroom so the next tool doesn't tip you over.

What not to do

Don't publish two SPF records — one v=spf1 only; two is itself a PermError.
Don't use ptr — deprecated and wasteful.
Don't ignore a PermError — "mostly works" means failing quietly.

Frequently asked questions

Does ip4 or ip6 count toward the SPF 10-lookup limit?

No. ip4, ip6, all and exp do not require a DNS lookup, so they don't count. The limit applies to mechanisms that query DNS: include, a, mx, ptr, exists, and the redirect modifier.

What happens when SPF exceeds 10 lookups?

SPF returns a PermError (permanent error). Many receivers treat that as if SPF isn't valid, so it provides no protection — and it can cause your legitimate mail to fail authentication, hurting deliverability and DMARC results.

Is SPF flattening safe?

Only if it's maintained. Flattening replaces includes with the provider's current IP addresses, which reduces lookups — but those IPs change without notice, so a flattened record that isn't kept up to date will silently start failing. It needs ongoing monitoring or automation.

Not sure how many lookups you're at?

StopForge's free exposure scan reads your live records and shows exactly where your email authentication stands — what passes, what silently fails, and whether anyone can still send as your domain. No changes to your mail, no obligation.

See if your domain can be spoofed

← All guides