How to Fix the SPF 10-Lookup Limit (Without Breaking Email Deliverability)

If your company uses multiple email services—such as Google Workspace, SendGrid, HubSpot, Zendesk, and Mailchimp—your SPF record can quickly grow out of control.

Eventually, recipient mail servers will reject your emails with a PermError: Too many DNS lookups.

This happens because the official SPF specification (RFC 7208) limits the number of mechanism lookups to 10. In this guide, we’ll explain why this limit exists, how to count your lookups, and how to fix it using SPF flattening.

Why Does the SPF 10-Lookup Limit Exist?

The 10-lookup limit was introduced as a security measure to prevent Distributed Denial of Service (DDoS) attacks. Without a limit, a malicious actor could create an SPF record with endless nested include: directives, causing receiving mail servers to make dozens of recursive DNS queries every time an email is received.

Mechanisms That Count Toward the Limit

Not all parts of an SPF record trigger a DNS lookup. Here is the breakdown:

Mechanisms that INCREASE lookup count (+1 each):

include: (e.g., include:_spf.google.com)
a
mx
ptr
redirect
exists

Mechanisms that DO NOT count (0 lookups):

ip4: (e.g., ip4:192.168.1.1)
ip6:
all

Example of an Over-Limit SPF Record

Take a look at this standard SPF record:

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

While it looks like only 4 inclusions on the surface, each provider's include: contains nested SPF records inside it!

_spf.google.com triggers 3 child lookups.
hubspotemail.net triggers 3 child lookups.
sendgrid.net triggers 2 child lookups.
mailgun.org triggers 3 child lookups.

Total Lookups = 11! This record fails RFC validation, causing your emails to drop straight into the Spam folder or bounce entirely.

How to Fix the 10-Lookup Limit

Solution 1: Remove Unused Mail Services

Audit your DNS records. If your team migrated from Mailchimp to Klaviyo two years ago, remove the old Mailchimp include: directive immediately.

Solution 2: Replace include: with Direct IP Ranges

If a provider offers dedicated IP addresses (e.g., SendGrid dedicated IP), replace include:sendgrid.net with ip4:168.245.X.X. ip4 and ip6 mechanisms cause ZERO DNS lookups.

Solution 3: Use SPF Flattening

SPF Flattening queries all nested include: domains, extracts their raw IP addresses, and condenses them into a single list of ip4 and ip6 ranges.

Audit Your Record Now: Use MXSentin’s Free SPF Record Checker to instantly see your exact lookup count and identify nested DNS bottlenecks before they impact deliverability.