Key takeaways
- SPF allows a maximum of 10 DNS lookups during evaluation; above that, SPF returns PermError.
- include, a, mx, ptr, exists and redirect count as lookups; ip4, ip6 and all do not.
- Nested includes count too, which is why records exceed the limit without looking long.
- Remove unused services first, then replace a and mx with IP ranges where possible.
- With DKIM aligned, DMARC can still pass when SPF fails, but fix the PermError anyway.
In this guide
- What the error means
- Why records exceed the limit without looking long
- Which mechanisms count
- How to count your lookups
- Six ways to get back under the limit
- Before and after: an example
- Mistakes to avoid when fixing SPF
- How to check that the fix worked
- Counting lookups by hand: a worked example
- Keep a simple SPF inventory
- Why this matters more since 2024
- Frequently asked questions
What the error means
When a receiving server checks SPF, it reads your SPF record and follows every reference in it to build the list of authorized servers. Each reference that needs a new DNS query counts as a lookup. The SPF standard (RFC 7208) limits this to 10 DNS lookups. If evaluation needs more, the result is a permanent error, PermError, and SPF is considered broken for that message.
You will see this error in SPF checking tools, in DMARC reports (permerror), or in email headers as spf=permerror. Many receivers treat it like a failure. If DKIM is not aligned for that stream, DMARC fails too.
Why records exceed the limit without looking long
A record can look short and still exceed the limit, because lookups are counted recursively. Look at this example:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net include:mail.zendesk.com include:_spf.salesforce.com mx a ~allThat is only eight mechanisms. But each include points to a record that may contain its own includes. One provider's include can cost three or four lookups by itself. Added together, this record can easily need 15 or more lookups.
Which mechanisms count
| Mechanism or modifier | Counts as a lookup? | Note |
|---|---|---|
include: | Yes | Plus every lookup inside the included record |
a | Yes | Looks up the domain's A/AAAA records |
mx | Yes | And may require extra lookups for each MX host |
ptr | Yes | Deprecated; should not be used |
exists: | Yes | Rare, used for advanced setups |
redirect= | Yes | Replaces the record with another one |
ip4: / ip6: | No | Direct IP ranges, free to use |
all | No | The final default rule |
There is a second, lesser-known limit: void lookups, meaning lookups that return no answer, are limited to two. An include pointing to a domain that no longer publishes SPF can trigger an error even when you are under ten.
How to count your lookups
- Read your current record. Use any DNS lookup tool on the TXT records of your domain. There must be only one record starting with
v=spf1; two records cause a PermError on their own. - Use an SPF checker. Free online SPF validators show the total number of lookups and the tree of nested includes. This is much faster than counting by hand.
- Note the cost of each include. You will see which providers are expensive. That tells you where to optimize.
Six ways to get back under the limit
1. Remove services you no longer use
This is the easiest and safest fix. Old email platforms, a helpdesk you replaced, a tool tested two years ago: their includes often stay in the record forever. Confirm with your DMARC reports that no mail comes from them anymore, then remove them.
2. Remove a and mx if they do not send email
Many records include a and mx by default. If your website server and your incoming mail servers do not send outgoing mail, these mechanisms cost lookups for nothing. If your web server does send mail (contact forms, for example), you can replace a with its exact ip4: address.
3. Rely on DKIM for platforms that use their own return-path
Many email marketing platforms send with their own bounce domain in the envelope sender. For those, SPF is checked against the platform's domain, not yours, so their include in your SPF record does not help DMARC at all. If the platform signs DKIM with your domain, DMARC passes through DKIM. Check the platform's documentation: some still recommend the include, others do not need it.
4. Move streams to subdomains
Send marketing from news.yourbrand.com, support emails from help.yourbrand.com, and keep the main domain for employees. Each subdomain gets its own SPF record with its own ten-lookup budget. See sending from a subdomain.
5. Replace includes with IP ranges, carefully
For a server you control with fixed IPs, writing ip4: ranges instead of an include saves lookups. Do not do this for large providers: their IPs change, and a hard-coded list becomes wrong without warning.
6. Use automatic SPF flattening as a last resort
Flattening services resolve all includes into IP ranges and keep your record updated automatically. It works, but it adds a dependency on a third party. Manual, one-time flattening is the risky version: when a provider changes IPs, your legitimate mail starts failing.
Before and after: an example
Before (about 14 lookups):
v=spf1 a mx include:_spf.google.com include:oldplatform.example include:servers.mcsv.net include:sendgrid.net include:mail.zendesk.com ~allAfter (under 10 lookups):
v=spf1 ip4:198.51.100.10 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com ~allWhat changed: the unused old platform was removed, a was replaced by the web server's IP, mx was removed because the incoming servers do not send, and the marketing platform was moved to DKIM alignment on a subdomain.
Mistakes to avoid when fixing SPF
- Publishing a second SPF record for the new tool instead of editing the existing one.
- Removing an include without checking reports: if that service still sends, its mail will fail SPF.
- Changing
~allto-allat the same time: change one thing at a time. The choice between the two is covered in SPF softfail vs hardfail. - Forgetting DKIM: a lean SPF record only works for DMARC if DKIM is aligned for the other streams. See SPF, DKIM and DMARC explained.
- Using the deprecated
ptrmechanism: it is slow, unreliable and counts as a lookup.
How to check that the fix worked
- Run the SPF checker again: total lookups under 10, no void lookup error.
- Send a test email to a Gmail address and use "Show original": SPF should show PASS.
- Watch the next week of DMARC reports:
permerrorshould disappear. - Check the authentication chart in Google Postmaster Tools.
Counting lookups by hand: a worked example
Even with a checker, it helps to understand the math once. Take this record:
v=spf1 mx include:_spf.example-mailbox.com include:spf.example-crm.com ~all| Element | Lookups | Why |
|---|---|---|
mx | 1 (+ extra for MX hosts) | Reads MX records, then resolves each host's address |
include:_spf.example-mailbox.com | 1 + its nested includes | If it contains 3 includes, total is 4 |
include:spf.example-crm.com | 1 + its nested includes | If it contains 2 includes, total is 3 |
~all | 0 | No lookup needed |
Total: at least 8 lookups for a record with only three mechanisms. Add two more tools and you are over the limit. This is why every new service deserves a quick SPF check before it goes live.
Keep a simple SPF inventory
The best long-term protection is a short internal document listing each SPF mechanism, the service it belongs to, who in your team uses it and when it was added. When a tool is cancelled, remove its include the same week. In my experience, records only exceed the limit when nobody owns them.
Why this matters more since 2024
Before the Gmail, Yahoo and Microsoft sender requirements, a broken SPF record often went unnoticed: mail still arrived, sometimes in spam. Today, authentication failures can lead to outright rejections, such as Gmail's 550 5.7.26 error or Outlook's 550 5.7.515. A PermError is no longer a cosmetic issue. Check your SPF record each time you add or remove a sending tool, and keep a short internal list of which include belongs to which service.
Frequently asked questions
What happens when SPF exceeds 10 lookups?
The SPF check returns a permanent error (PermError). Many receivers treat this as an SPF failure, which can hurt DMARC results if DKIM is not aligned.
Do ip4 and ip6 mechanisms count as lookups?
No. ip4, ip6 and all do not require DNS lookups. That is why replacing some includes with IP ranges reduces your count.
Is SPF flattening safe?
It works, but it is risky if done once by hand: when a provider changes its IP addresses, your record becomes outdated. Use flattening only with a service that updates it automatically.
What is the void lookup limit?
SPF also limits lookups that return no result (void lookups) to two. Includes pointing to domains that no longer publish SPF can trigger this error.
Can I split SPF across subdomains?
Yes. Sending different streams from different subdomains, each with its own SPF record, is a clean way to stay under the limit.
