SPF 10 DNS Lookup Limit — How to Count and Fix It

What is the 10 DNS lookup limit

An SPF record defines which servers are authorized to send email on behalf of your domain (see What is an SPF Record for background). Every time an email is delivered, the receiving server retrieves the SPF record from DNS and evaluates it. Some mechanisms in the record require additional DNS queries — and those queries are limited.

RFC 7208 (Section 4.6.4) mandates that evaluating a single SPF record must not trigger more than 10 DNS lookups. The limit protects receiving mail servers — without it, an attacker could craft an SPF record with dozens of nested include mechanisms and overwhelm the recipient's DNS infrastructure.

Exceeding the limit triggers a PermError. The SPF check fails regardless of whether the sending server is authorized. Your emails may land in spam or be rejected outright.

Which mechanisms count

Not every SPF mechanism triggers a DNS query. Understanding the distinction is key to optimizing your record.

Count toward the limit

Do not count

Watch out for nested includes

Each include retrieves the target domain's SPF record, which may contain additional include mechanisms. Those count toward the same limit. The actual number of nested lookups depends on the current structure of each service's SPF record and can change without notice — this is why regular monitoring is essential.

How to count DNS lookups

Manually counting nested include mechanisms is tedious and error-prone — nested records can also change without your knowledge.

Check your SPF record with our analyzer — it automatically counts all DNS lookups including nested ones and flags any limit violations.

Alternatively, from the command line:

dig example.com TXT +short | grep spf

This shows the raw SPF record, but you need to manually expand each include — repeat the query for each target domain and add up all lookups.

Example: how many lookups a typical domain uses

Domain example.com uses Google Workspace, SendGrid, Freshdesk, and a dedicated server:

v=spf1 include:_spf.google.com include:sendgrid.net include:email.freshdesk.com a mx -all

Each include consumes at least 1 lookup (plus any nested ones). The a and mx mechanisms add further queries. The exact total depends on the current SPF record structure of each service — verify it with an SPF analyzer.

With five or more sending services, you will approach the 10-lookup limit very quickly.

The 2 void lookup limit

In addition to the main limit, RFC 7208 recommends capping void lookups at 2 — DNS queries that return an empty response (no records) or an NXDOMAIN error. Most mail servers enforce this limit and return PermError when it is exceeded.

Void lookups typically occur when an SPF record references an include for a domain that has no SPF record or no longer exists. The most common cause: a decommissioned service whose include was left in the record.

How to fix the limit

1. Remove unused mechanisms

Review every include and a/mx mechanism in your record. If the service it references no longer sends email from your domain, remove it. This is the cleanest and safest optimization.

Common candidates for removal:

• Discontinued SaaS services (old helpdesk, previous marketing tool)
• Test environments that are no longer running
• The a or mx mechanism if your A/MX records don't point to a mail server

2. Replace includes with direct IP addresses

If a service sends email from a static IP address (typically your own server), replace the include or a mechanism with a direct ip4:/ip6:. You save at least one lookup.

# Before (2 lookups)
v=spf1 a include:_spf.google.com -all

# After (1 fewer lookup)
v=spf1 ip4:198.51.100.10 include:_spf.google.com -all

This only works for servers with stable IP addresses. For cloud services that rotate IPs, include remains the only reliable approach.

3. Subdomain segmentation

Move part of your email traffic to a subdomain. Each subdomain has its own SPF record with its own 10-lookup limit.

Example: send marketing from news.example.com, transactional email from notify.example.com:

# example.com — corporate email
v=spf1 include:_spf.google.com ip4:198.51.100.10 -all

# news.example.com — marketing
v=spf1 include:sendgrid.net -all

# notify.example.com — transactional email
v=spf1 include:email.freshdesk.com include:amazonses.com -all

Segmentation has another advantage: it isolates the reputation of each email stream. A deliverability problem with marketing campaigns won't affect invoice delivery.

4. SPF flattening

SPF flattening replaces include mechanisms with the actual IP addresses that would otherwise be resolved via DNS queries. It reduces the lookup count but comes with a critical downside: if the service changes its IP addresses, your SPF record stops working.

# Before flattening
v=spf1 include:_spf.google.com -all

# After flattening (simplified example)
v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 -all

Google (and other large providers) change their IP ranges regularly. Flattening therefore requires automation — periodic checks and updates of the IP addresses. Without automation, you risk legitimate emails failing SPF checks.

Use flattening as a last resort, only after exhausting the previous three approaches.

How to prevent the problem

The 10 DNS lookup limit rarely hits you all at once — it grows gradually as you add new services. Before adding a new include to your SPF record, verify the current lookup count with an SPF record analyzer.

Regular SPF record monitoring catches the problem before it affects your email deliverability. Changes in nested include records (for example, when Google adds a new server) can push your record over the limit without any action on your part.

If you operate a domain with more than three email services, consider subdomain segmentation from the start — you'll avoid the lookup limit problem and gain better control over the sender reputation of each email stream. For a step-by-step guide to building your record, see How to Create an SPF Record.