SPF record exceeds the 10 DNS lookup limit
SPF allows a maximum of 10 DNS lookups when a receiver evaluates your record. Go past that and the check returns permerror, which most receivers treat as no SPF at all, so mail that would have passed now fails, including mail from senders listed well before the limit was reached. The count is almost always driven up by include: mechanisms, because each one pulls in another provider's record and everything inside it.
Check your own domainSPF checker
What causes this
Each include:, a, mx, ptr, exists: and redirect= mechanism costs one DNS lookup, and every include pulls in that provider's own record, whose mechanisms count too. RFC 7208 caps the total at 10 to stop SPF being used to amplify DNS traffic. Once a record goes over the cap, receivers return permerror rather than evaluating the mechanisms they did manage to resolve, so the senders listed at the end of your record are not the only ones affected; the whole record fails.
What it breaks
SPF returns permerror for all of your mail, not just for the senders past the tenth lookup. Mail that would otherwise have passed SPF now fails it, and DMARC loses its SPF path.
What the receiving server does
The limit is not a warning the receiver shows you. When a mail server evaluates your SPF record it counts every mechanism that costs a DNS query as it goes, and the moment the eleventh is required it stops and returns permerror. RFC 7208 leaves what happens next to the receiver: some treat permerror as an outright fail, others as neutral. Either way your SPF no longer authenticates anything, and DMARC loses SPF as a passing path, leaving DKIM to carry alignment alone. If DKIM is also missing or misaligned, DMARC fails outright and an enforcing policy will have your mail quarantined or rejected.
Where the ten lookups actually go
A record can look short and still be over the limit, because the cost is not in the characters you wrote: it is in what those includes expand to, and that is set by your providers rather than by you. The costs below are what these records resolve to at the time of writing. They are not constants: Google and Microsoft both used to nest several includes and have since flattened to plain IP ranges, which is exactly why the only count worth trusting is the one computed against DNS as it stands today.
How to fix it
Reduce the number of lookup-costing mechanisms until the total is 10 or fewer.
- Remove includes for services you no longer use. This is usually where most of the budget has gone.
- Replace an include with the specific ip4:/ip6: ranges it resolves to where the provider publishes stable addresses. IP mechanisms cost zero lookups.
- Consolidate onto fewer sending services where the same job is being done twice.
- Avoid ptr, which costs a lookup and is deprecated.
- Re-check after each change: the count is what the receiver computes, not what the record looks like.
If you send with
- Google Workspace
- include:_spf.google.com currently resolves to plain IP ranges, so it costs one lookup rather than the four it cost when the record still nested _netblocks includes. If you are over the limit today, Google is almost certainly not the cause, and it is almost never the include to remove. Check the marketing and transactional senders first.
- Microsoft 365
- include:spf.protection.outlook.com now resolves to IP ranges directly and costs one lookup, so there is nothing left to gain by flattening it yourself, and flattening would cost you the automatic updates when Microsoft changes those ranges. Leave the include in place.
- Marketing and transactional senders
- These vary, and they are where the budget usually goes. Some are flattened and cost one: Mailchimp's servers.mcsv.net is a single lookup today. Others still nest: sendgrid.net pulls in ab.sendgrid.net for two, and mailgun.org pulls in two regional records for three. The common thread is not the vendor but the nesting, and the usual culprit is a service trialled years ago that still sits in the record and no longer sends anything. Removing dead includes is the cheapest fix and the one to try first.
Confirming the fix worked
- Publish the change, then wait for the old record's TTL to expire. Until it does, some receivers are still evaluating the previous version.
- Re-run the check above. The count we report is the one a receiver computes by resolving every include, not a count of the mechanisms you can see in the string.
- Aim to land at seven lookups or fewer rather than exactly ten. Your providers can add mechanisms to their own records at any time, and if you are sitting at ten their change breaks your SPF on a day you did not touch anything.
- If you flattened an include to IP ranges, set a reminder to re-check them. A flattened record is a snapshot, and it goes stale silently.
Common questions
- Does the 10 lookup limit count the ip4 and ip6 mechanisms in my record?
- No. ip4: and ip6: mechanisms cost nothing, because the receiver already has the address and does not need to resolve anything. Only mechanisms that require a DNS query count: include, a, mx, ptr and exists. This is why flattening an include into IP ranges reduces the count.
- Is the limit 10 lookups or 10 includes?
- Ten lookups, not ten includes. A single include can cost several lookups on its own, because the record it points at may contain includes of its own which are resolved recursively. mailgun.org currently costs three that way. A handful of includes is enough to exceed the limit, which is why records that look short still fail, and why the only number worth acting on is the one the checker computes against DNS as it stands now.
- What does permerror actually mean for my email?
- It means the receiver could not evaluate your SPF record and gave up. Most treat that as SPF not passing. The practical effect is that SPF stops authenticating any of your mail, not just mail from the senders past the tenth lookup, and DMARC can no longer use SPF as a passing path.
- Can I just add a second SPF record to make room?
- No, and it makes things worse. A domain must publish exactly one SPF record. Two records is itself a permanent error, and receivers will not merge them. You would replace a lookup limit problem with a duplicate record problem.
- Is flattening my SPF record safe?
- It is safe as long as you maintain it. Flattening replaces an include with the IP ranges it currently resolves to, which removes the lookup cost. The risk is that it freezes those addresses: when the provider changes their ranges, your record still lists the old ones and their mail starts failing SPF. Flatten providers with stable, published ranges, and re-check on a schedule.
- How close to the limit is safe?
- Seven or fewer gives you real headroom. The count is not fully under your control, because your providers' own records sit inside your includes and can grow without you making any change. A record at nine or ten is one provider-side edit away from failing.