SPF PermError: too many DNS lookups

RFC 7208 caps SPF evaluation at 10 DNS lookups. Every include:, a, mx, ptr, exists: and redirect= costs one — and the includes' own includes count too. Lookup number 11 makes evaluators return permerror, and mail providers treat that as "no valid SPF": DMARC loses its SPF leg, and strict receivers reject or spam-folder your mail.

Why it happens

SPF records grow by accretion: every SaaS tool you ever connected added an include, and big providers nest 2–4 lookups inside each one. include:_spf.google.com alone is 3 lookups. Six vendor includes later you are over the cliff without changing anything yourself — a vendor adding a nested include can push you over overnight.

Diagnose it

The SPF tool below expands the full include tree and counts every lookup the way a receiver does, flagging the total against the limit — so you can see exactly which branch is expensive.

Fix it

1. Delete includes for services you no longer use — this is almost always worth 2–4 lookups.

2. Replace deep includes with flat IPs where the vendor's ranges are stable: ip4:198.51.100.0/24 costs zero lookups.

3. Never use ptr (deprecated, costly) and avoid a/mx when an ip4 suffices.

4. If you genuinely need many vendors, use a dedicated subdomain per mail stream (marketing.yourdomain with its own SPF), or an SPF-flattening service that maintains the merged IP list for you.