SPF at 10 Lookups: How to Manage the Limit as You Add Vendors

What the 10-Lookup Limit Actually Means

RFC 7208 limits SPF records to 10 DNS lookups per check. That sounds abstract until you are at 9 and your next SaaS tool needs an include: directive, pushing you to 11 and SPF starts failing at some receivers with no clear error.

The count is not the number of include: lines. It is the number of DNS queries triggered when a receiver evaluates your record. A single include: can trigger multiple lookups if the included record has its own includes. The actual count is often higher than expected.

When you exceed the limit, receivers treat it as a permerror a permanent failure. Some fail-open and ignore the error. Others fail-closed and reject the email. Either way, SPF authentication becomes unreliable, and you may not notice until deliverability problems show up in your metrics.

How Many Lookups Does Your Current Record Have

Before making any changes, know where you stand. Each include:, a, mx, ptr, and exists: counts as a lookup. Recursive includes count toward your total, if your include:_spf.vendor.com resolves to a record that itself has 3 includes, that is 4 lookups total for that one directive.

Use an SPF analyzer that shows the full lookup chain, not just the top-level count. DMARCFlow's SPF analysis shows the complete chain and flags when you are approaching the limit.

At 6–7 lookups: room to add vendors, but plan ahead. At 8–9: any new addition is a crisis. At 10: you cannot add anything without first reducing your existing count.

Flattening Your SPF Record

Flattening replaces include: mechanisms with the actual IP addresses they resolve to. Instead of a chain of lookups, your record contains direct ip4: and ip6: entries.

Before:

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

After flattening:

v=spf1 ip4:142.250.0.0/15 ip4:209.61.0.0/17 ip4:198.61.0.0/16 ...

The include: chain is resolved once, IPs are written directly into your record, and your lookup count drops to 1.

The trade-off: vendors rotate IPs. Your flattened record is a snapshot that becomes stale. You need a process to re-flatten, monthly, or whenever a vendor notifies you of infrastructure changes. Tools that automate re-flattening remove this operational burden. SPF analysis flags when your record needs re-flattening.

Macro-Based Includes to Consolidate Vendors

A more maintainable option, if your vendor supports it: use an SPF macro instead of separate includes per platform.

v=spf1 include:_spf.%{d} ...

This directive resolves dynamically based on the sending domain, one include handles multiple vendors if they publish their SPF under a consistent subdomain pattern. Whether this works depends entirely on the vendor's infrastructure. Some support it, many do not.

If your vendor does not support macro-based includes, this approach is not available to you.

Dedicated Sending Domains Per Vendor

The most robust architecture for organizations with many email-sending vendors: each vendor gets their own subdomain with their own SPF record.

Setup:

1. Create a subdomain: sendgrid.yourdomain.com, mailgun.yourdomain.com
2. Add the vendor's SPF record to that subdomain's DNS only
3. Configure the vendor to send from the subdomain
4. Your primary domain's SPF record does not change

The vendor's IP changes affect only their subdomain. Your primary domain's SPF record is unaffected. This is the cleanest long-term design because the lookup count for your primary domain stays constant regardless of how many vendors you use.

Not all vendors support custom sending domains, some require sending from their shared infrastructure. But for major platforms (SendGrid, Mailgun, Postmark, etc.), dedicated sending domains are standard configuration.

A Vendor Governance Policy for New Additions

The lookup limit problem is a governance problem more than a technical one. Organizations hit the ceiling because nobody tracks the SPF cost of new vendor additions.

Before approving any new email-sending vendor, require answers to:

1. What is their sending infrastructure? Can they send from a dedicated subdomain you control?
2. Do they support DKIM signing with your domain? If yes, you may not need an SPF include at all.
3. What is their SPF record URL? Ask them to confirm their current include: target.
4. How many lookups does their SPF add? Run their record through an analyzer before adding it.

This last question is the most important one. If a vendor's SPF chain adds 4 lookups and you have 7, you cannot safely add them without first reducing your existing count. Discovering this after a vendor goes live is the wrong time to find out.

DKIM-only vendors are underused. If a platform can DKIM-sign emails using your domain's key, SPF is irrelevant for that sending path. DKIM has no lookup limit and is not affected by the same failure modes as SPF. Prefer vendors that support this.

Decision Framework

At 8+ lookups and need to add a vendor:

1. Can they send from a dedicated subdomain? → do that, primary SPF unchanged
2. Can they DKIM-sign with our domain? → do that, no SPF include needed
3. Do they support macro-based includes? → use the macro
4. None of the above? → flatten your record first, then add them

FAQ

How many SPF lookups do I have? Run your record through an SPF analyzer. Each include:, a, mx, ptr, and exists: counts as a lookup. Recursive includes count fully, a single include: that resolves to a record with its own 3 includes counts as 4 lookups.

What happens if I exceed the SPF lookup limit? Receivers treat it as a permerror (permanent error). Some fail-open and ignore it. Others fail-closed and reject the email. Either way, SPF authentication becomes unreliable and emails may start landing in spam without an obvious cause.

How does SPF flattening work? Flattening resolves your include: chain once, replaces each include with the IP ranges it resolves to, and writes those IPs directly into your SPF record. Your lookup count drops to 1. The tradeoff: you must re-flatten when vendors change their IP infrastructure, or the record becomes inaccurate.

Can I use a macro to reduce SPF includes? Only if your vendor supports it. A macro like include:_spf.%{d} dynamically resolves based on the sending domain. If your vendor does not publish their SPF in a macro-compatible format, this will not work.

How do I add new vendors without breaking SPF? Start with the decision framework above. Dedicated subdomains and DKIM-only configuration do not affect your primary SPF record at all. Only fall back to adding include: directives when no other option exists, and flatten before doing so.