SPF PermError Too Many Lookups: How to Fix the 10-Lookup Limit

Short answer: the SPF specification (RFC 7208) limits authorization checks to a maximum of 10 DNS lookups to protect mail servers from denial-of-service attacks. When your record exceeds 10 lookups, receiving mail servers reject or flag your messages with an SPF PermError. To fix it, audit every include:, remove tools you no longer use, replace single-IP includes with ip4: addresses, or implement subdomains for marketing services.

Unlike a missing SPF record or multiple SPF records, an SPF PermError often sneaks up unexpectedly. Adding just one new customer relationship manager, transactional email tool, or helpdesk platform can easily push your domain over the threshold because third-party providers often nest multiple lookups inside their own includes. When SPF produces a PermError, your DMARC policy fails unless DKIM passes cleanly.

Step 1: count your current DNS lookups

Not every mechanism in an SPF string costs a DNS lookup. RFC 7208 specifies that only mechanisms requiring recursive DNS resolution count against the 10-lookup quota:

Mechanism	Lookup cost	Explanation
include:	1 + nested	Resolves the target record plus any lookups inside it
a	1	Queries the A/AAAA record for the domain
mx	1 + targets	Queries MX records, then resolves each mail exchanger
ptr	1 (deprecated)	Triggers reverse DNS queries, avoid completely
redirect=	1	Follows a redirect to another SPF record
ip4: and ip6:	0	Pure IP notation, zero DNS lookups required
all	0	Evaluation directive, zero DNS lookups required

You can check your total lookups from the command line using dig:

dig +short TXT example.com

Count every include:, a, and mx mechanism. Remember that an include like include:_spf.google.com or include:sendgrid.net often contains nested includes under the hood.

Step 2: remove inactive and redundant includes

Over the years, marketing teams test new platforms and switch between email marketing tools, but domain administrators rarely clean up old DNS records.

Review each include in your TXT record:

• Are you still using that survey tool from three years ago?
• Did you migrate from Mailchimp to Klaviyo or HubSpot?
• Do you send outbound emails directly from your web host? If your web server does not send outgoing mail, remove a and mx mechanisms from your SPF record.

For example, a record that looks like this:

v=spf1 mx a include:_spf.google.com include:sendgrid.net include:mailgun.org include:servers.mcsv.net ~all

Often costs between 11 and 14 total lookups due to nested includes. If your domain only sends through Google Workspace and SendGrid, trimming the unused providers drops the count back well below 10:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Step 3: convert static server IPs to ip4 ranges

If your SPF record contains a or mx mechanisms just to authorize your primary web server or mail server, replace them with direct ip4: mechanisms.

When you use the a mechanism, the receiving mail server must perform a DNS lookup for your root domain's A record. When you write the explicit IP address instead:

# Before (costs 1 DNS lookup):
v=spf1 a include:_spf.google.com ~all

# After (costs 0 DNS lookups):
v=spf1 ip4:198.51.100.24 include:_spf.google.com ~all

This simple substitution instantly saves one lookup while keeping authorization identical.

Step 4: delegate bulk and transactional mail to subdomains

The cleanest and most sustainable solution for growing businesses is separating email traffic by purpose across dedicated subdomains.

Instead of cramming your root domain's SPF record with every third-party service:

• Send day-to-day business emails from @example.com authorized only for Google Workspace or Microsoft 365.
• Send transactional receipts from @notify.example.com authorized for SendGrid or Postmark.
• Send marketing newsletters from @news.example.com authorized for Mailchimp or Klaviyo.

Create a separate TXT record for each subdomain in your DNS manager:

# Root domain SPF (example.com):
v=spf1 include:_spf.google.com ~all

# Transactional subdomain SPF (notify.example.com):
v=spf1 include:sendgrid.net ~all

# Marketing newsletter subdomain SPF (news.example.com):
v=spf1 include:servers.mcsv.net ~all

This isolates your lookup limits, protects the sender reputation of your primary corporate inbox, and prevents third-party quota bloat.

Step 5: understand SPF flattening and its risks

SPF flattening services replace all include: statements with a flat list of ip4: and ip6: CIDR blocks. While this eliminates all DNS lookups, it introduces serious operational risk.

Third-party providers like Google, Microsoft, and Amazon rotate and expand their mail delivery IP ranges frequently. If you paste static IP blocks into your record and the provider adds a new IP pool, your legitimate emails will fail SPF checks. Only use SPF flattening if you rely on an automated dynamic service that monitors and synchronizes IP changes via API within minutes.

Common mistakes

• Leaving deprecated ptr mechanisms in place: RFC 7208 strictly discourages ptr: because it causes slow reverse queries and wastes lookups. Remove it immediately.
• Thinking ip4 and ip6 add lookups: direct IP entries cost zero lookups. Do not hesitate to use ip4: or ip6: to authorize dedicated servers.
• Creating a second TXT record to bypass the limit: publishing two SPF records causes a syntax PermError and invalidates both records completely.
• Forgetting that void lookups have an even stricter limit: if an include or mechanism resolves to a nonexistent host (NXDOMAIN or empty answer), RFC 7208 allows a maximum of 2 void lookups before throwing a void lookup PermError.