The RFC 7208 10-DNS-lookup limit rule
When adding email services to your domain—such as Google Workspace, Microsoft 365, SendGrid, Zendesk, and HubSpot—you typically paste include: mechanisms into your SPF (Sender Policy Framework) DNS TXT record:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all
However, the official SPF specification (RFC 7208 Section 4.6.4) enforces a strict ceiling: an SPF evaluation must not require more than 10 total DNS lookups.
If an incoming mail server (like Gmail, Yahoo, or Outlook) encounters an 11th lookup while parsing your SPF record, it immediately aborts evaluation and triggers a permanent failure:
550 5.7.1 SPF PermError: too many DNS lookups (limit is 10)
When this occurs, recipient mail servers treat your authentication as broken. Your marketing newsletters, transactional receipts, and everyday employee communications will be routed straight to spam or bounced completely.
Which SPF mechanisms count toward the 10-lookup limit?
Not all SPF mechanisms trigger a DNS query. Understanding the difference is key to keeping your record within the safe threshold:
| Mechanism | Counts Toward 10 Limit? | Explanation |
| :--- | :--- | :--- |
| include: | YES (+1 per include) | Queries the target domain's SPF record, plus any nested lookups inside it. |
| a / a:domain | YES (+1) | Resolves the domain's IPv4 or IPv6 address. |
| mx / mx:domain | YES (+1) | Queries MX mail exchanger records for the domain. |
| ptr | YES (+1) | Deprecated and dangerous reverse-DNS lookup. |
| exists: | YES (+1) | Queries whether a specific DNS record exists. |
| redirect= | YES (+1) | Delegates SPF evaluation to a secondary domain. |
| ip4: | NO (0 lookups) | Direct CIDR IP address range. Evaluated locally in memory. |
| ip6: | NO (0 lookups) | Direct IPv6 address range. Evaluated locally in memory. |
| all (~all, -all) | NO (0 lookups) | Fallback default policy qualifier. |
The danger of "nested" includes
A common pitfall is nested lookups. When you add a single include:example.com, that external provider might include two other third-party records inside its own SPF, which in turn include another. A single line in your TXT record can silently consume 3 to 5 lookups against your quota.
How to test your current SPF lookup count
Use our free SPF Record Validator & Syntax Checker to inspect your live DNS TXT record.
The validator automatically:
- Traverses all nested
include:directives in real time. - Tallies your exact lookup count against the RFC 10-lookup limit.
- Warns if you are approaching the threshold (8 or 9 lookups) or have exceeded it (10+ lookups).
- Flags syntax errors, duplicate records, and dangerous
+allwildcards.
You can also inspect your raw SPF TXT record from your terminal using dig:
dig +short TXT yourdomain.com
4 proven ways to fix the "Too Many Lookups" error
1. Remove obsolete and duplicate email providers
Over time, companies test and discard marketing tools, CRM platforms, and support ticketing systems without removing them from their DNS records. Audit your include: statements and remove services your team no longer uses (such as old Mailchimp, Mandrill, or Constant Contact accounts).
2. Replace hostname mechanisms (a and mx) with direct IPs
If your domain has a or mx mechanisms in its SPF record:
# Bad: Consumes 2 lookups
v=spf1 a mx include:_spf.google.com ~all
Replace them with explicit ip4: addresses:
# Good: Consumes 0 lookups
v=spf1 ip4:198.51.100.25 include:_spf.google.com ~all
Since ip4: and ip6: mechanisms do not require external DNS queries, they do not count toward the RFC 10-lookup quota.
3. Move transactional mail to dedicated subdomains
Rather than crowding all corporate, marketing, and transactional senders into your root apex domain (yourdomain.com), isolate them across dedicated subdomains:
- Marketing Newsletters:
news.yourdomain.com - Transactional Receipts:
billing.yourdomain.com - Internal Corporate Mail:
yourdomain.com
Each subdomain maintains its own independent 10-lookup budget:
# TXT for news.yourdomain.com
v=spf1 include:sendgrid.net ~all
# TXT for billing.yourdomain.com
v=spf1 include:postmarkapp.com ~all
4. SPF flattening (Dynamic SPF macros)
If your enterprise genuinely requires more than 10 lookups and cannot separate subdomains, you can "flatten" your SPF record. SPF flattening periodically resolves all include: hostnames into their underlying ip4: CIDR ranges and writes them directly into your TXT record.
Warning: Because cloud providers (Google, Microsoft) periodically update their IP ranges without notice, manual flattening can cause delivery failures. Use an automated dynamic SPF flattening service if you choose this path.
Common SPF PermError traps to avoid
Having multiple SPF records
RFC 7208 strictly forbids publishing more than one SPF TXT record on a single domain. If your DNS host contains:
TXT: "v=spf1 include:_spf.google.com ~all"TXT: "v=spf1 include:sendgrid.net ~all"
Receiving mail servers will reject both records with PermError: duplicate SPF records. You must merge them into a single unified string:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Using the dangerous +all qualifier
Using +all allows any computer on the entire internet to send email on your behalf with full authorization. Always use softfail (~all) or hard fail (-all).