SPF Too Many Lookups: Fix the 10-Lookup Limit Safely

SPF breaks when evaluation needs more than 10 DNS-querying mechanisms, including nested include, a, mx, ptr, exists, and redirect terms. If you ignore it, receivers can return SPF permerror, and DMARC may fail when DKIM is not aligned. This guide shows how to count the chain, split senders by subdomain, and repair the record safely.

SPF is only one authentication check. Keep DKIM and DMARC aligned too, especially if you send cold outreach from a new domain. Use this alongside our SPF, DKIM and DMARC setup guide, then verify every sender before you raise volume.

The common mistake is adding one include per service. Each service can include more records. Your DNS may show five includes, but a receiver may need more than 10 DNS queries to evaluate the full tree.

The fix is not always SPF flattening. In many cases, the safer repair is to stop forcing every sender through the root domain’s SPF record.

What counts toward SPF's limit?

SPF is evaluated against the envelope sender domain. You may see this called the Return-Path, bounce domain, MAIL FROM domain, or smtp.mailfrom in headers. It can differ from the visible From address your recipient sees.

The 10-lookup rule comes from RFC 7208 section 4.6.4. It limits DNS-querying SPF mechanisms and redirect processing during SPF evaluation.

Do not count only the terms in your top-level TXT record. Count the mechanisms that cause more DNS work, including nested includes.

A short-looking record can still fail:

v=spf1 include:_spf.google.com include:zohomail.com include:amazonses.com ~all

The true count is the full evaluation tree. Google, Zoho, and Amazon SES can each publish nested SPF records. Providers can also change their SPF structure, so do not copy a lookup count from an old post.

Check the provider’s current documentation before editing. Google lists include:_spf.google.com in its official Workspace SPF guide. Amazon SES explains SPF and custom MAIL FROM setup in its sender authentication guide. Zoho lists current SPF values in its SPF configuration help.

How do you count the chain?

Start with the domain in the Return-Path, not the visible From address. If a message says From: alex@example.com but the Return-Path is bounce.mail.example.com, SPF checks bounce.mail.example.com.

Then expand every DNS-querying SPF term. If your record includes Google, and Google includes more SPF records, those nested records count toward the same limit.

Use a checker for the first pass, but also inspect a real message header. A checker tells you whether the record can pass. Headers tell you which domain your sender actually used.

Look for these header fields:

• Return-Path
• MAIL FROM
• smtp.mailfrom
• spf=pass, spf=fail, or spf=permerror
• dkim=pass
• dmarc=pass

The initial TXT query that fetches your SPF record is not the useful number to manage. Your practical job is to keep DNS-querying SPF mechanisms and redirect processing at 10 or fewer.

Also check that each domain has exactly one SPF TXT record. Two separate TXT records starting with v=spf1 are not a way to split SPF. They create another SPF error.

How do you fix spf too many lookups?

Start with deletion. Remove senders that no longer send mail for the domain.

Old newsletter tools, CRMs, helpdesks, recruiting platforms, and SMTP relays often remain in SPF long after the account is closed. Each unused include makes the next sender harder to add.

Do not remove a sender only because you do not recognise it. Match it to a real system first. Check billing, DNS notes, CRM settings, provider dashboards, and recent sent-mail headers.

Then decide whether each active sender belongs on the root domain or on a subdomain. Human mailbox sending often belongs on the mailbox domain. Bulk, transactional, and campaign platforms often belong on authenticated bounce or MAIL FROM subdomains.

Use this “do this now” checklist before you publish changes.

The safest first edit is removing inactive senders. The second safest edit is separating senders by subdomain. The riskiest edit is manual flattening without monitoring.

Which senders need subdomains?

SPF checks the envelope sender domain. That gives you room to split senders without changing every visible From address.

For example, your recipient may see alex@example.com. A sending platform can still use bounce.mail.example.com as the Return-Path if it supports a custom MAIL FROM, bounce domain, or return-path domain.

That means example.com does not need every sender in its SPF record.

This works best when DMARC alignment is clear.

DMARC can pass through aligned SPF or aligned DKIM. SPF alignment compares the visible From domain with the envelope sender domain. In relaxed alignment, a subdomain such as bounce.example.com can align with example.com because they share the same organisational domain.

DKIM is often the steadier alignment path for bulk senders. If DKIM signs with example.com or an aligned subdomain, DMARC can pass even when SPF uses a bounce subdomain.

Do not split blindly. Some mailbox providers send from your root domain. Some marketing tools require their own return-path setup. Some free tiers do not expose custom bounce domains. Check the provider’s current authentication settings before you move a sender.

How should Google, Zoho, SES split?

Here is a realistic setup.

You use Google Workspace for people, Zoho Mail for one support team, and Amazon SES for product notifications. Someone created this root SPF record:

v=spf1 include:_spf.google.com include:zohomail.com include:amazonses.com ~all

It may pass today, or it may exceed the limit after nested includes. The exact count depends on current provider records. It is also hard to maintain because three mail systems now depend on one DNS line.

A cleaner setup separates the streams.

This is an example, not a universal record. Zoho SPF values can vary by region or setup. Amazon SES custom MAIL FROM also needs the MX record SES provides for your selected AWS region.

If the support team must send as support@example.com through Zoho, Zoho may still belong in the root domain SPF record. Remove unused senders first, then test the real count.

If SES signs DKIM for example.com, product notifications can pass DMARC through DKIM even when SPF uses bounce.example.com. That is usually cleaner than adding SES to every human-mail SPF record.

For cold outreach, avoid mixing all streams into one mailbox or one DNS identity. A new outreach domain should have fewer moving parts. Our new domain warm-up guide shows a slower setup for domains with no sending history.

When is SPF flattening safe?

SPF flattening means replacing includes with the IP addresses they currently resolve to.

It can reduce DNS lookups because ip4 and ip6 mechanisms do not count toward the 10-lookup limit. It can also break mail if the sending provider changes IP ranges and your flattened record is not updated.

Flattening is reasonable in three cases:

• The sender gives you stable, dedicated IPs.
• You use an automated SPF flattening service with monitoring.
• You own the sending infrastructure and control the IPs.

Flattening is risky in these cases:

• The provider uses shared or changing cloud infrastructure.
• Nobody owns DNS maintenance internally.
• The record was copied from a one-time lookup.
• You cannot test every active sender after the change.

Do not flatten Google Workspace by copying whatever IPs _spf.google.com returns today. Google maintains that include so it can change the underlying records. The include is the contract; a manual IP copy is a snapshot.

Use the same caution with Zoho and Amazon SES. If the provider tells you to use an include, prefer a separate subdomain over manual flattening.

If you must flatten, keep a change log. Record the owner, provider, date, source, and next review date. Recheck after provider migrations, region changes, and account upgrades.

Also watch TXT size. Very long flattened SPF records may need multiple quoted strings inside one TXT record. They must still publish as one SPF record for that name.

How do you test safely?

Before editing DNS, collect three things: the current SPF record, the list of systems that send mail, and recent message headers from each system.

After you publish the new record, wait for DNS based on your TTL. Do not change every sender and raise sending volume in the same hour. Make one change, test it, then continue.

A checker catches obvious SPF errors. A real test message catches routing mistakes.

Use our SPF checker for the record, then send test mail from each platform. If Gmail is a key receiver, open the delivered message and inspect the original headers after it arrives.

If your problem is broader than SPF, use the Gmail spam troubleshooting guide or the new-domain spam fix. SPF permerrors often appear beside weak DKIM, missing DMARC, new-domain reputation, and fast sending ramps.

Fixing SPF does not create sender reputation by itself. It removes a technical failure that can stop reputation from building.

Once SPF, DKIM, and DMARC pass, use a controlled ramp. For an existing domain, a week of warm-up is usually enough before light outbound. For a new domain, use two to three weeks and keep volume low.

During active campaigns, keep warm-up at 10 to 15 emails per day per mailbox. Keep real outreach around 30 to 50 emails per day per mailbox. Add mailboxes rather than forcing more volume through one identity.

BobWork Email Warm-up checks SPF, DKIM, and DMARC daily per domain in the dashboard. The warm-up engine starts at 3 emails per day, adds 2 per day, and caps at 30 per day by default. The free warm-up dashboard does the DNS recheck automatically while your mailboxes build history.

It uses a shared warm-up network by default, or a private pool per account if you prefer. New accounts get up to 10 mailboxes free, with no credit card and no time limit. Outlook and Microsoft 365 are not supported yet.

If you compare tools after fixing SPF, the free warm-up tools comparison explains which options are free plans and which are trials. If you manage several domains, the multi-mailbox warm-up guide covers volume control across mailboxes.

The safest SPF repair is boring: count the real lookups, remove unused senders, split active platforms by subdomain, and avoid manual flattening unless someone will maintain it. After DNS passes, connect the mailbox to BobWork Email Warm-up so daily SPF, DKIM, and DMARC checks continue while warm-up runs.

Frequently asked questions