How many SPF DNS lookups are allowed?

SPF permits exactly 10 DNS lookups during evaluation. This limit is defined in RFC 7208 section 4.6.4 and is enforced by essentially every mail receiver in 2026. Exceeding it causes SPF to return permerror, which most receivers treat as an authentication failure. Knowing what counts as a lookup, how to count them correctly, and how to stay under the limit is the single most important operational detail of SPF in 2026.

The rule exactly as written

RFC 7208 §4.6.4: "SPF implementations MUST limit the total number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check. [...] If this limit is exceeded, the implementation MUST return 'permerror'."

In plain terms:

• Maximum 10 DNS lookups during SPF evaluation.
• Over 10 = permerror.
• permerror is typically treated as fail by DMARC-enforcing receivers.
• The count is across all mechanisms, including nested ones.

What counts as a DNS lookup

Each of the following mechanisms counts as one lookup:

• include: — one lookup, plus the full lookup count of the included record.
• a — one lookup for A/AAAA records at the given domain.
• mx — one lookup for MX records, plus potentially more for each MX.
• ptr — one lookup for PTR (discouraged in RFC 7208 and should be avoided).
• exists: — one lookup for A record existence check.
• redirect= — one lookup, plus the full count of the redirected record.

The following do not count:

• ip4: — literal IPv4 address, no lookup needed.
• ip6: — literal IPv6 address, no lookup needed.
• all — the catch-all at the end, no lookup.

So ip4: and ip6: are free and should be preferred wherever possible.

Counting nested lookups correctly

The most common SPF lookup counting mistake is counting only the top-level include: directives. The real count includes everything those includes resolve to.

Consider this record:

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

At first glance: 2 lookups. In reality:

_spf.google.com → _netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com
  (1 for _spf.google.com itself + 3 for the netblock includes = 4 lookups)

mailgun.org → eu._spf.mailgun.org, us._spf.mailgun.org
  (1 for mailgun.org + 2 for the region includes = 3 lookups)

Total: 7 lookups, not 2.

This is why a seemingly conservative SPF record with only 3-4 include: directives can be over 10 lookups.

Typical lookup counts by popular sender

Approximate lookup counts for common ESP include: directives (counts change occasionally as ESPs restructure their SPF):

_spf.google.com                      ~4
spf.protection.outlook.com           ~3
amazonses.com                        ~3
sendgrid.net                         ~3
_spf.salesforce.com                  ~5
servers.mcsv.net                     ~1
mail.zendesk.com                     ~1
_spf.hubspotemail.net                ~2
spf.mandrillapp.com                  ~2
mailgun.org                          ~3
spf.messagingengine.com              ~1
mktomail.com                         ~1

Stack four of these and you are often past 10.

Measuring the real count

Several free tools count lookups accurately:

• IntoDNS.ai returns the total lookup count and the tree of each include in a scan.
• The dig command with a recursive resolver can be used manually (tedious).
• RFC 7208 appendix A shows the evaluation algorithm for manual walking.

For day-to-day, a scan is the fastest path.

Strategies to stay under 10

Strategy 1: Remove unused senders. The cheapest optimisation. Audit your domain and remove include: directives for services you no longer use. Most domains have at least one or two zombie entries from old trials.

Strategy 2: Replace include: with literal IPs. For your own static infrastructure, use ip4: and ip6: directly instead of a or mx. For ESPs that publish their sending IP ranges (Amazon SES, some smaller ESPs), you can sometimes substitute a few ip4: blocks for an entire include: chain.

Strategy 3: Subdomain segmentation. This is the cleanest long-term solution. Send different types of mail from different subdomains, each with its own SPF record:

@                — v=spf1 include:_spf.google.com ~all     (corporate mail)
mg.example.com   — v=spf1 include:mailgun.org ~all         (transactional)
mail.example.com — v=spf1 include:servers.mcsv.net ~all    (marketing)

Each subdomain's SPF is short. The apex SPF stays short. No single evaluation exceeds 10 lookups.

Strategy 4: SPF flattening. Replace each include: with the IPs it resolves to at flatten time. Now your SPF is all ip4: and ip6: with zero DNS lookups in evaluation.

v=spf1 ip4:209.85.220.0/24 ip4:209.85.221.0/24 ... ip4:173.194.0.0/16 ~all

Problem: vendor IP ranges change. You need automation to re-flatten regularly (weekly is a reasonable minimum). If you do not re-flatten, messages will start failing when vendors add new IPs.

Strategy 5: Switch ESPs. Some ESPs have much shorter SPF chains than others. If you are stuck near the limit, switching to a lean-SPF ESP can reclaim 2-4 lookups.

Other SPF limits to know

Besides the 10-lookup rule, RFC 7208 imposes two other limits:

Two "void lookups" maximum. A void lookup is a DNS query that returns NXDOMAIN or an empty response. More than two void lookups during evaluation returns permerror. This matters when include: targets have deprecated subrecords.

512 byte total record length (for DNS resolver compatibility). Records longer than 450-512 bytes can be truncated by some resolvers, so keep total length under 450 as a safety margin.

MX mechanism MX limit: if you use mx, the evaluation looks up MX records and then looks up each MX hostname's A/AAAA. Limit is 10 MX records; exceeding returns permerror.

Troubleshooting

permerror in Authentication-Results. You are over 10 lookups. Scan with IntoDNS.ai and see the tree.

Count seems fine but SPF fails. Check for void lookups — some includes have deprecated subrecords that return NXDOMAIN.

Count changes between days. Some ESPs restructure their SPF. An include that was 3 lookups last month may be 4 this month. Monitor.

You are at exactly 10. One lookup headroom is risky. Aim for 7-8 to absorb future ESP growth.

Adding a new ESP pushes you over. Either remove an unused sender, move the new ESP to a subdomain, or start flattening.

Concrete examples

Under limit (well configured):

v=spf1 ip4:185.71.60.245 include:_spf.google.com include:mailgun.org ~all

Count: 0 + 4 + 3 = 7 lookups. Safe.

At limit (dangerous):

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

Count: 4 + 3 + 3 = 10 lookups. One more include breaks it.

Over limit (broken):

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

Count: 4 + 3 + 3 + 3 = 13 lookups. Returns permerror. All SPF evaluation fails.

When to use IntoDNS.ai

IntoDNS.ai parses your SPF record, expands every include: recursively, counts real DNS lookups (not just top-level), flags void lookups, and shows you exactly where your count is going. After every SPF change, scan to confirm you are still under 10 with headroom. For production monitoring, scheduled scans and free fix digests catch ESP SPF restructurings before they break your mail.

A deeper look at flattening

SPF flattening is controversial. In exchange for headroom it trades DNS maintainability and visibility into what is authorised. The mechanics:

1. Resolve each include: recursively to the full set of IPv4 and IPv6 ranges.
2. Rewrite the SPF record as a long sequence of ip4: and ip6: blocks.
3. Schedule a job to re-resolve weekly or whenever ESP IP ranges change.
4. Monitor for changes and re-publish.

Practical considerations:

• Record length. A flattened SPF record for a domain with 5 ESPs can easily be 800-1200 characters. DNS TXT records support this but some older resolvers misbehave above 512 bytes. Modern resolvers are fine.
• Automation required. Manually re-flattening is impractical because vendor IP ranges change without notice. Without automation, messages will start failing when vendors add new sending IPs.
• Visibility loss. A flattened record shows a wall of IP blocks; a normal record shows named ESPs. Auditing becomes harder.
• Risk transfer. With flattening, you depend on the accuracy of your resolution pipeline. A stale resolution can accept or reject legitimate mail incorrectly.

For most domains the right answer is not flattening but reducing: remove unused senders, move to subdomains, and stay under 10 lookups the normal way.

When you actually need more than 10

You do not. If you think you need more than 10, you have an architectural problem with too many senders on one domain. The solution is subdomain segmentation. Split mail by purpose:

example.com              (executive mail, one or two includes)
mg.example.com           (transactional via Mailgun)
mkt.example.com          (marketing via Mailchimp)
notifications.example.com (application notifications via SES)
support.example.com      (Zendesk/Intercom/similar)

Each subdomain has a short SPF, its own DKIM setup, and ideally its own DMARC record. The apex is protected by a minimal SPF and an enforced DMARC that either includes a sp= or is overridden by per-subdomain DMARC records.

This pattern scales to arbitrary numbers of senders and is what most large email programs use by 2026. Once set up, new ESPs are added on a new subdomain rather than being stacked on an ever-growing apex SPF chain.