SPF 10 DNS Lookup Limit: How to Fix Permerror with Flattening (2026)

What Is the SPF 10 DNS Lookup Limit?

RFC 7208 (the SPF specification) defines a hard limit of 10 DNS lookups during SPF evaluation. When a receiving mail server checks your SPF record, it follows every mechanism that requires a DNS query. If the total exceeds 10, the server must return a permerror (permanent error) result — effectively treating SPF as broken.

This limit exists to prevent SPF evaluation from becoming a denial of service vector. Without it, a malicious SPF record could trigger hundreds of recursive DNS queries per inbound email, overwhelming resolvers and slowing down mail delivery.

Why Does the Limit Exist?

SPF evaluation happens during the SMTP transaction for every inbound email. A mail server processing thousands of messages per hour cannot afford to perform dozens of DNS lookups per message. The 10-lookup limit ensures that SPF evaluation remains fast and predictable, even under high load.

Without this limit, attackers could craft SPF records that chain hundreds of include mechanisms, effectively weaponizing DNS queries against receiving mail servers. The 10-lookup cap is a security safeguard built into the protocol.

What Causes SPF Permerror?

SPF permerror occurs when a receiving server encounters a permanently invalid SPF record. The most common cause is exceeding the 10-lookup limit, but other causes include:

• More than 10 DNS-querying mechanisms in the record chain.
• Syntax errors in the SPF record (missing v=spf1 prefix, invalid mechanisms).
• Multiple SPF records published for the same domain (only one is allowed).
• Infinite loops caused by circular include or redirect chains.

When permerror is returned, most receiving servers treat it as an SPF failure, which can trigger DMARC failures and hurt your email deliverability.

How to Count SPF Lookups

Not every mechanism in an SPF record counts toward the 10-lookup limit. Only mechanisms that require a DNS query count. Here is the complete breakdown:

Mechanisms That Count (Require DNS Lookup)

• include: — 1 lookup, plus all lookups in the included record (recursive).
• a — 1 lookup (resolves A/AAAA for the specified or current domain).
• mx — 1 lookup (resolves MX, then A for each MX host — but only the MX query counts toward the 10).
• redirect= — 1 lookup (replaces the current SPF evaluation with another domain's record).
• exists: — 1 lookup (checks for the existence of an A record).
• ptr — 1 lookup (deprecated and strongly discouraged by RFC 7208).

Mechanisms That Do NOT Count

• ip4: — No DNS lookup needed. Directly matches an IPv4 address or CIDR range.
• ip6: — No DNS lookup needed. Directly matches an IPv6 address or CIDR range.
• all — No DNS lookup needed. Matches everything (used as the final catch-all).

The critical thing to understand is that include mechanisms are recursive. If include:spf.example.com points to a record with 3 more lookups, the total cost is 4 lookups (1 for the include itself + 3 for the included record). Use our SPF Checker to see your total lookup count instantly.

How SPF Flattening Works

SPF flattening is the process of resolving all include, a, and mx mechanisms into their underlying IP addresses and replacing them with ip4: and ip6: entries. Since ip4 and ip6 don't count toward the lookup limit, a flattened record can authorize the same servers using zero DNS lookups.

For example, instead of:

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

A flattened version would look like:

v=spf1 ip4:209.85.128.0/17 ip4:172.217.0.0/16 ip4:40.92.0.0/15 ip4:167.89.0.0/16 ~all

Use our SPF Flattener tool to automatically flatten your SPF record and see the resulting IP list.

Risks of SPF Flattening

While flattening solves the lookup limit, it introduces a significant maintenance challenge:

• Stale IP addresses. Cloud email providers (Google, Microsoft, SendGrid) regularly add, remove, and change their sending IP ranges. A flattened record is a snapshot in time. If a provider adds new IPs and your record doesn't include them, emails from those IPs will fail SPF.
• Manual maintenance burden. You need to periodically re-flatten your record to catch IP changes. For providers like Google Workspace, IP ranges can change without notice.
• Record size limits. A single DNS TXT record can hold at most 255 characters per string and 512 bytes per UDP response. Flattening to many IP ranges can exceed these limits, requiring multiple TXT strings or CIDR aggregation.
• Reduced transparency. An SPF record full of IP ranges is harder to audit than one with descriptive include mechanisms.

Alternatives to Flattening

If flattening isn't ideal for your situation, consider these alternatives:

• Subdomain delegation. Instead of sending all email from your root domain, use subdomains (e.g., mail.example.com for transactional, news.example.com for marketing). Each subdomain gets its own SPF record with its own 10-lookup budget.
• SPF macros. The exists: mechanism with macros (e.g., exists:%{i}._spf.example.com) can dynamically match sending IPs against a set of A records you control. Each exists costs only 1 lookup, regardless of how many IPs it covers.
• Remove unused services. Audit your SPF record regularly. Old include entries for services you no longer use waste lookups. Remove them.
• Consolidate providers. If possible, reduce the number of third-party email services you use. Each additional provider typically adds 1-4 lookups.

Verify Your SPF Record

Use these free tools to audit and fix your SPF configuration:

• SPF Flattener — Automatically flatten your SPF record to eliminate excess lookups.
• SPF Checker — Validate your SPF record, count lookups, and identify errors.
• DMARC Checker — Verify your DMARC policy and check how SPF failures affect your overall email authentication.