How to reduce SPF DNS lookups and fix too many lookups

If your domain returns a PermError, the cause is almost always the same: your SPF record forces more than 10 DNS lookups during evaluation. Under RFC 7208, an SPF check is capped at 10 DNS-querying mechanisms and 2 void lookups — cross either ceiling and authentication fails for every message you send. The fix is to reduce the number of lookups your record triggers, and this guide walks through every reliable way to do that, from quick cleanups to permanent automation.

This is the child page under the pillar guide on SPF too many DNS lookups. If you are not yet sure how close you are to the ceiling, start with the 10-lookup limit explained and how to count your SPF lookups, then come back here to bring the number down.

Which SPF mechanisms cost you a DNS lookup?

Before you can reduce lookups, you need to know what counts. Not every part of an SPF record queries DNS — only these mechanisms and modifiers do, and each one counts against your budget of 10:

• include: — fetches another domain’s SPF record, then evaluates everything inside it. A single vendor include: commonly expands to 3-6 lookups because of nesting.
• a — resolves A/AAAA records for the domain or a named host. Counts 1+.
• mx — looks up the domain’s MX records, then resolves each mail host to an IP. Fans out to 2-6 lookups depending on how many MX hosts you run.
• ptr — reverse-resolves the client IP and forward-confirms it. Slow, brittle, and deprecated. Avoid entirely.
• exists — evaluates a domain (often via macros) with an A lookup. Counts 1 each.
• redirect= — fetches another domain’s SPF and continues there; that record’s lookups count toward the same 10.

Mechanisms that cost zero lookups are ip4:, ip6:, and all. These match directly against the sending IP with no DNS query, which is exactly why every reduction technique below funnels lookups toward explicit IP entries. The 10-lookup budget applies across the entire evaluation, so nested includes and redirect targets all draw from the same pool.

Step 1: Audit and clean up your current record

The fastest wins come from deleting things you no longer need. Records accumulate cruft as teams add SaaS tools and abandon old ones without ever pruning the SPF entry. Start by pulling your live record:

dig +short TXT yourdomain.com | grep v=spf1

Then work through it:

• Confirm you have exactly one SPF record. Two v=spf1 TXT records on the same domain is an instant PermError on its own. If you find more than one, merge them into a single record before doing anything else.
• Remove dead senders. If you switched off a marketing platform or CRM last year, its include: is still burning lookups. Delete it.
• Kill ptr outright. It is deprecated, slow, and often ignored by receivers. Replace it with ip4:/ip6: for the hosts it was covering.
• Strip duplicate and overlapping entries. If two includes resolve to the same IP block, keep one. If an ip4: range already covers an address listed separately, drop the redundant line.

For a full pruning checklist, the pattern is the same one covered in how to count your SPF lookups — inventory every mechanism, then decide what actually still sends mail.

Step 2: Replace lookup-heavy mechanisms with explicit IPs

Once the record is clean, convert the mechanisms that still cost lookups into ones that don’t. This is the core of reducing your count.

Replace mx and a first. Both fan out unpredictably. If your mail servers have stable addresses, list them as ip4: / ip6: entries and remove the mx and a mechanisms entirely:

# Before (3-4 lookups)
v=spf1 mx a include:_spf.google.com -all

# After (1 lookup)
v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.google.com -all

Then tackle third-party includes. Many vendors — Amazon SES, Mailgun, SendGrid — publish their sending ranges as documented CIDRs. Where a provider’s ranges are stable, replace include:vendor.com with the corresponding ip4:/ip6: entries and include only the regions you actually send from. The caveat: some providers rotate IPs frequently, so a hand-converted range can silently go stale and de-authorize legitimate mail. Keep an include: for genuinely high-churn vendors, or automate the refresh (see below).

Step 3: Consolidate and delegate

If you are still over budget after cleaning and converting, restructure how the record is organized.

Merge overlapping authorities. Prioritize your most-used senders as ip4:/ip6: entries at the front of the record (they cost nothing), then a single consolidated include: for your primary platform such as spf.protection.outlook.com or _spf.google.com.

Use redirect= for shared policies. If you run several sibling domains with near-identical SPF, point each at one canonical policy with v=spf1 redirect=_spf.parent.tld. You maintain one record instead of many, and every child inherits a under-budget policy. Use redirect= to eliminate duplicate policy across domains — use include: when you need to merge multiple authorities inside one domain’s record.

Segment senders onto subdomains. Give each platform its own envelope-sender subdomain (mg.example.com, sg.example.com), each with its own SPF record. This localizes the lookup cost of a bloated vendor to a subdomain instead of loading it onto your root domain, where it competes with everything else for the 10-lookup budget.

Step 4: Flatten the record

Flattening is the most thorough reduction technique and a completely valid fix. It resolves every include:, a, mx, and redirect= down to the underlying ip4:/ip6: addresses, collapsing a record that needed 12+ lookups into one that needs zero (or close to it). For the full walkthrough, see SPF flattening.

The tradeoff is maintenance. A hand-flattened record is a point-in-time snapshot: the moment Google, Microsoft, or SendGrid rotates an IP range, your static record goes stale and starts failing legitimate mail. It also grows long — watch the 255-character-per-string TXT limit, splitting into multiple quoted strings when needed. That is why flattening is only durable when something keeps it fresh.

This is where automatic SPF flattening service earns its place. AutoSPF resolves your includes to exact sending IPs, rescans every 15 minutes, and auto-updates the published record when a vendor’s ranges change — so the record stays flat, accurate, and permanently under the 10-lookup limit without manual busywork. It de-duplicates overlapping CIDRs, splits long TXT strings safely, and rolls back if a change would cause a PermError.

Step 5: Validate and monitor

Never publish a reduced record without confirming it resolves cleanly. Run it through the SPF Checker to see the exact lookup count and mechanism-by-mechanism expansion. Aim for 6-8 lookups in steady state, not the full 10 — that headroom absorbs provider-side nesting changes and transient DNS anomalies without tipping you back into PermError.

After publishing, allow for DNS propagation (up to a few hours depending on TTL), then re-check. Because vendor IPs and your own sending stack drift over time, reducing lookups once is not a permanent fix on its own — schedule a quarterly review, or let automated monitoring alert you before the count creeps back over the line.

Frequently Asked Questions

What is the fastest way to fix too many SPF lookups?

Delete unused senders first — old CRMs, retired marketing tools, and duplicate includes are usually the quickest wins. Then replace mx, a, and ptr mechanisms with explicit ip4:/ip6: entries. If you are still over 10, flatten the record so every include: becomes a static IP.

Does the redirect= modifier count toward the 10-lookup limit?

Yes. redirect= triggers at least one DNS query to fetch the target domain’s SPF record, and every lookup inside that redirected record counts toward the same budget of 10. Use redirect= to centralize policy across sibling domains, not as a way to bypass the limit.

Will flattening my SPF record break when a vendor changes IPs?

It can, if you flatten manually. A static flattened record is a snapshot, and providers like Google and SendGrid rotate their ranges without notice — when they do, a hand-built record silently de-authorizes real mail. Automated flattening with monitoring, such as AutoSPF’s 15-minute rescan and auto-update, rebuilds the record whenever ranges change so it never goes stale.

How many DNS lookups should my SPF record use?

The hard ceiling is 10, but engineer your record to 6-8 in steady state. That buffer absorbs the extra lookups that appear when a vendor adds nesting to their own include, plus temporary DNS timeouts, without pushing you over into PermError.

Can I just remove mx and a from my SPF record?

In most cases, yes — and you should if your mail hosts have stable addresses. Replace them with explicit ip4:/ip6: entries for your actual outbound IPs. mx can fan out to many hosts and a varies with hostname resolution, so both cost lookups that direct IP entries do not.

Do ip4: and ip6: mechanisms count against the limit?

No. ip4:, ip6:, and all match the sending IP directly with no DNS query, so they cost zero lookups. This is exactly why every reduction technique aims to convert lookup-heavy mechanisms into explicit IP entries — you can list dozens of IP ranges without ever touching your budget of 10.