Why your SPF record stops working: the 10 DNS lookup limit explained
Here's a scenario that catches a lot of growing businesses off guard: your SPF record looks completely correct. You can read it, it references your real email providers, and nothing about it looks broken. And yet mail servers are treating it as if it doesn't exist at all.
The cause is almost always the same thing — your SPF record has quietly crossed the 10 DNS lookup limit, and once it does, the entire record is ignored. Not "partially ignored." Ignored. Here's why that limit exists, how businesses hit it without noticing, and how to fix it.
A quick refresher: what SPF actually does
SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are allowed to send email on behalf of your domain. When a message arrives claiming to be from yourcompany.com, the receiving server looks up your SPF record and checks whether the sending server is on the approved list.
Each include: mechanism doesn't just add a name to a list — it tells the receiving server to go and perform its own separate DNS lookup to fetch that provider's SPF record, which may itself contain further include: statements pointing to still more records. This is where the problem starts.
The rule: no more than 10 DNS lookups, ever
RFC 7208, the technical specification for SPF, sets a hard limit: a receiving mail server may perform a maximum of 10 DNS lookups while evaluating your SPF record. This includes lookups triggered by include, a, mx, ptr, and exists mechanisms — and, critically, it includes the lookups triggered by nested includes inside the records you're including.
If evaluating your record would require an 11th lookup, the receiving server doesn't just ignore that one extra provider. It stops evaluating the record entirely and returns a result called permerror — a permanent error. As far as the receiving server is concerned, your domain effectively has no usable SPF policy at that point.
Why this happens without anyone noticing
The lookup count creeps up gradually, and it's rarely one obvious mistake — it's an accumulation of ordinary decisions:
- Every new tool adds at least one lookup. Google Workspace or Microsoft 365 for regular mail, plus SendGrid or Postmark for transactional email, plus Mailchimp or HubSpot for marketing, plus a CRM or helpdesk tool that also sends on your behalf — each is one
include:, minimum. - Some includes are more expensive than others. A single
include:can reference a provider record that itself includes three or four more records. You added one line to your SPF record; the actual lookup cost might be four or five. - Old integrations never get removed. A marketing tool you cancelled two years ago often still has its
include:sitting in your SPF record, quietly consuming one of your 10 lookups for a service you no longer use. - Nobody checks the lookup count when adding a new tool. Setup guides tell you to "add this line to your SPF record" — they don't tell you how many lookups it costs or how close you are to the limit.
The record can look completely reasonable — five or six include: statements isn't unusual for a modern small business — and still silently exceed the limit because of what's nested inside those includes.
The worst part: it fails silently
Unlike a typo in your DNS record, a lookup-limit failure produces no error message you'll ever see. Your SPF record still resolves fine in a browser or a basic DNS lookup tool. There's no warning in your DNS provider's dashboard. The only place it shows up is in how receiving mail servers treat your outgoing messages — which, from your side, just looks like emails increasingly landing in spam or getting rejected, for no reason you can identify.
If you have DMARC configured with aggregate reporting (rua=), this is one of the few ways to actually catch it — the reports from Google, Microsoft, and Yahoo will show SPF results of permerror instead of pass or fail. Without DMARC reporting, most businesses never find out this is the cause.
How to fix a record that's over the limit
Use an SPF record checker that expands nested includes and reports a total lookup count, rather than just reading the top-level record. Five include: lines can easily add up to 12+ real lookups once nested records are counted.
Audit every include: against tools you actually send email through today. Cancelled marketing platforms, old CRMs, and one-off transactional services from a previous project are common candidates for removal.
If several tools relay mail through the same underlying provider, you may not need a separate include for each. Some providers also publish a single flattened include that covers multiple products — check their documentation rather than adding one per product.
Flattening replaces include: mechanisms with the actual ip4:/ip6: ranges they resolve to, cutting the lookup count to near zero. It works, but it comes with a real maintenance cost: if a provider changes its sending IP ranges (which happens without notice), your flattened record goes stale and starts rejecting your own legitimate mail. Only flatten if you're prepared to keep it updated, or use a service that maintains it for you.
Before adding a new SPF include for a new SaaS tool, check your current lookup count first. If you're already at 8 or 9, that new tool may be the one that quietly breaks everything.
SPF isn't the whole picture
Even a perfectly valid SPF record only checks the technical routing address, not the visible "From" header your recipients see — and it does nothing on its own without a DMARC policy telling receiving servers what to do about failures. A broken SPF record matters most because it undermines DMARC alignment, which is what actually protects your domain from being spoofed. If you haven't set up DMARC yet, that's the more foundational piece to get right first.
Check your own domain's SPF lookup count right now
See your actual email security score in about 10 seconds — no signup needed.