SPF Record 10-Lookup Limit Explained (and How to Fix It)

An SPF record can perform a maximum of 10 DNS lookups during evaluation. Go over that number by even one, and the receiving mail server stops trying to validate your record at all. It returns a PermError, DMARC treats that error as a hard fail, and your email starts landing in spam or bouncing outright, regardless of whether the sending server was actually authorized.

This isn't a soft guideline. It's written into RFC 7208, Section 4.6.4, the technical specification for SPF, and every major receiver Gmail, Outlook.com, Yahoo enforces it exactly as written. There's no warning email, no bounce that says "your SPF is almost full." Your record simply works one day and silently stops working the next, usually right after someone in marketing signs up for a new email tool.

If you're here because deliverability tanked out of nowhere, jump straight to how to check your actual count or the fixes section. If you want to understand why this keeps happening, keep reading - it'll save you from hitting the same wall again in six months.

What Actually Counts as a "Lookup"

This is where almost every explanation online gets vague, so let's be precise. Only certain SPF mechanisms trigger a DNS query, and each one counts toward the cap:

mx deserves its own callout, because it's the mechanism most likely to quietly blow your budget on its own. The mx mechanism itself costs 1 lookup to fetch your domain's MX records, but the evaluation then has to resolve the A or AAAA record for each of those mail servers, up to the first 10 returned. If your domain has four MX records for redundancy, that single mx in your SPF line can cost 5 lookups total (1 to find them, 4 to resolve each one), not 1. Companies running their own mail infrastructure alongside a cloud provider are the ones who get bitten by this most often, because they add mx out of habit without realizing it isn't a flat, fixed cost.

The trap almost nobody sees coming with include: is that it's recursive. If you include a vendor's SPF record, and that vendor's record itself includes three more domains, you don't pay 1 lookup - you pay 4. The published TXT record on your own domain might show five include: statements and look perfectly reasonable, while the actual evaluation chain underneath is 14 or 15 lookups deep. You cannot tell how many lookups a record costs by reading it. You have to walk the whole chain.

Why a Record That "Only Has Five Includes" Can Still Break

Here's a real-world combination that a mid-sized company might publish without a second thought:

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

Five includes. Looks fine at a glance. Walk the chain and it isn't:

• _spf.google.com - 1 lookup, and it currently nests 2 more _netblocks records → 3 total
• spf.protection.outlook.com - Microsoft has trimmed this down over time, and it now often resolves in as little as 1 lookup, though it has cost 2–3 in the past depending on your tenant configuration
• sendgrid.net - resolves to SendGrid's own regional sending infrastructure → 2–5 total, depending on which SendGrid setup you're on
• servers.mcsv.net (Mailchimp) - 1 lookup
• _spf.salesforce.com - nests further → 2–4 total

Add those up and you land somewhere around 9–14 lookups before you've even added a helpdesk tool, a CRM, or a billing platform already at or over the line. This is precisely why companies that used one email vendor in 2015 and have since bolted on a CRM, a support desk, a marketing platform, and a transactional email API routinely find themselves several lookups over budget without ever touching the SPF record directly - the vendors' own records shift over time, or a well-meaning employee followed a setup guide and pasted in another include: line.

Worth flagging: the exact figures above are a snapshot, not a constant. Google, Microsoft, and other large providers actively restructure their own SPF records to reduce their lookup footprint (Microsoft's trim from 2–3 lookups down to roughly 1 is a good example), and they can just as easily add nesting back in later if their sending infrastructure changes. The lesson isn't "memorize these numbers" - it's "never assume last quarter's count is still accurate." Re-check before you rely on it.

The Silent Failure Nobody Notices Until It's Too Late

A PermError is genuinely worse than a normal SPF fail, and this distinction matters for how you triage the problem.

An SPF fail means the receiver checked your record, found the sending IP wasn't on the list, and made a decision. It's a clean result - you can debug it, because you know the record was actually read.

A PermError means the receiver gave up before finishing the check. It doesn't matter if the real sending IP was correctly listed three includes deep - the evaluation stopped, and DMARC treats a PermError exactly like a fail. Nothing in DNS itself flags this. There's no error message sitting in your zone file. The only place it shows up is in your DMARC aggregate reports (the rua reports), buried under a spf_result field reading permerror, which most people never actually open.

There's also a second, much less-discussed limit in RFC 7208: the void lookup limit, capped at 2. A void lookup happens when a mechanism resolves to nothing - an NXDOMAIN response, or a query that returns zero usable records. This typically happens when an SPF record still includes a vendor you've cancelled, and that vendor has since deleted or let their SPF DNS entry lapse. You can be at 6 total lookups, comfortably under the 10-lookup ceiling, and still get hit with a PermError because three of those lookups resolved to nothing. Almost every guide on this topic stops at "count to 10" and never mentions this second failure mode - which is exactly why it catches experienced admins off guard.

How to Check Your Real Lookup Count

Don't eyeball your TXT record. Do this instead:

1. Pull the raw record: dig TXT yourdomain.com +short
2. Walk every include manually if you want to understand it, using dig TXT against each nested domain is tedious, but it teaches you exactly where your budget is going.
3. Or use a proper SPF evaluation tool that expands includes recursively and gives you a hard number (not just a syntax check - plenty of "SPF checkers" only validate formatting and don't count lookups at all, which gives people false confidence).
4. Check your DMARC aggregate reports for any permerror entries in the spf_result field - this tells you the problem is live, right now, in production, not theoretical.

If your count comes back at 8 or 9, treat that as already over budget in practice - vendors add nested includes to their own records over time without asking you, so a record sitting at 9 today can silently become 11 after a vendor-side change you never touched.

Five Ways to Fix an SPF Record That's Over the Limit

1. Remove dead senders first

Before doing anything technical, audit which include: entries correspond to services you're actually still using. It's extremely common to find an include for a marketing platform nobody's used in two years, or a testing account that was never cleaned up. This is the fastest fix and it's free no tooling required, just deleting lines from a DNS record.

2. Replace vendor includes with static IPs where possible

If a vendor sends from a small, stable set of IP ranges, ask their support team for the actual ranges and swap include:vendor.com for ip4: entries directly. ip4 and ip6 mechanisms cost zero DNS lookups. This only works cleanly for vendors with genuinely stable, documented ranges - check their published IP list rather than guessing from current DNS results.

3. SPF flattening

Flattening tools resolve every nested include down into a flat list of IP addresses and publish that instead of the include chain. It works, and it gets you under 10 lookups immediately. The catch almost nobody mentions: flattening freezes a snapshot in time. If your email vendor rotates or expands their sending IP ranges next month - which large providers do regularly - your flattened record goes stale and starts blocking legitimate mail from your own vendor, silently, until someone re-flattens it. If you go this route, it has to be paired with automated monitoring that re-flattens on a schedule (weekly, not "whenever someone remembers"), or you've just traded one silent failure mode for another.

4. Move senders onto subdomains with their own SPF records

Instead of stacking every vendor onto your root domain's SPF record, split sending purposes across subdomains, each with its own 10-lookup budget:

Corporate mail:      example.com          → include:spf.protection.outlook.com
Marketing:           news.example.com     → include:servers.mcsv.net
Transactional email: receipts.example.com → include:sendgrid.net

This is the most durable fix for growing organizations, because it scales - each subdomain gets a fresh 10-lookup allowance instead of everyone fighting over one shared budget. The tradeoff is that senders need to actually send from those subdomains (in the visible From: or envelope-from address, depending on setup), which sometimes requires coordination with whoever configures your outbound sending tools.

5. SPF macros (advanced, and rarely worth it for most businesses)

RFC 7208 supports macros that can construct lookups dynamically based on the sending IP or domain, in theory allowing a single mechanism to replace several static includes. In practice this is fiddly, poorly supported by many vendor setup guides, and easy to get wrong in ways that are hard to debug. Reach for this only if you've already tried consolidation and subdomain delegation and still have a genuinely complex multi-brand sending setup - for a typical business with 4–6 vendors, options 1–4 will solve the problem without the added complexity.

Roughly What Common Providers Cost You

Exact figures shift over time as vendors update their own SPF records, so treat these as planning estimates rather than gospel - always verify with a real lookup tool before publishing:

• Google Workspace (include:_spf.google.com): currently around 3 lookups (1 direct + 2 nested _netblocks records)
• Microsoft 365 (include:spf.protection.outlook.com): Microsoft has optimized this heavily and it often resolves in just 1 lookup now, though it's cost 2–3 in older configurations
• SendGrid (include:sendgrid.net): around 2–5 lookups depending on your account's regional setup
• Mailchimp (include:servers.mcsv.net): around 1 lookup
• Salesforce (include:_spf.salesforce.com): around 2–4 lookups

Add just Google Workspace and Microsoft 365 together and you can be anywhere from 4 to 7 lookups before a single marketing or support tool enters the picture, depending on which side of a vendor's optimization cycle you happen to be on. This is why three or four vendors is still the realistic ceiling before most businesses need to actively manage their SPF budget rather than just adding includes as they go and why "I checked this last year" isn't good enough. Vendor-side changes mean your number can move even when you haven't edited anything.

Related Guides

Business Email Not Sending or Receiving? Common Causes & Fixes - if SPF is only part of your problem, this covers the other reasons business email breaks (MX misconfiguration, mailbox quotas, blocklisting, and more).

Why Are Business Emails Going to Spam? (SPF, DKIM & DMARC Explained) - a broader look at how SPF works alongside DKIM and DMARC, useful if you haven't set up the other two yet.

Domain Related Problems - for DNS issues beyond SPF (verification records, propagation delays, missing entries) that can also affect email deliverability.

Professional Email / Business Email Issues - if you'd rather have someone audit and fix your SPF, DKIM, and DMARC setup directly instead of doing it yourself.