Your emails are landing in spam. Or worse, they’re being rejected outright. You pull up the delivery logs and there it is: SPF PermError: too many DNS lookups. It looks like a minor technical hiccup. It is not. That single error means every email your domain sends is failing authentication, regardless of whether the message is legitimate or not. If your DMARC policy is set to quarantine or reject, the consequences compound fast.
This article walks through exactly what causes the SPF PermError, why the 10-lookup limit exists, how it interacts with your DMARC posture, and what you can actually do to fix it without breaking your email environment in the process.
Understanding the 10-Lookup Rule That Most Teams Hit Too Late
SPF (Sender Policy Framework) works by publishing a DNS TXT record that lists every server authorised to send email on behalf of your domain. When a receiving mail server checks an inbound message, it queries your DNS to verify the sending IP against that record. Simple enough, until you start chaining services together.
RFC 7208, the specification that governs SPF, sets a hard ceiling of 10 DNS mechanism lookups per SPF check. That limit covers the include, a, mx, ptr, and exists mechanisms, plus the redirect modifier. Critically, this is a cumulative count across the entire chain. If your SPF record includes _spf.google.com, that counts as one lookup. If Google’s own record includes further mechanisms, those count too. Nested includes add up faster than most administrators realise, and the validator on the receiving side stops counting at 10 and returns a PermError, full stop.
The mechanisms that do not count against this limit are all, ip4, and ip6, since they resolve directly to addresses without requiring additional DNS queries. That distinction matters a great deal when you start optimising.
Why the Limit Exists, and Why You Should Actually Respect It
The 10-lookup ceiling is not arbitrary. It exists to protect receiving mail servers from denial-of-service scenarios. A malicious actor could theoretically craft an SPF record that triggers hundreds of chained DNS lookups, consuming bandwidth and CPU on every validator that checks it. The limit prevents that amplification attack by design.
There is also a practical performance angle. Every DNS lookup during SPF evaluation adds latency. More lookups mean more round trips, more opportunities for timeout failures, and a higher chance that the evaluation never completes cleanly. Receiving servers have finite patience for authentication checks, and a record bloated with nested includes creates real delay in the delivery pipeline.
The second threshold in RFC 7208 is a maximum of 2 void lookups (meaning lookups that return no result or an error), and it is less discussed but equally dangerous. Hit that limit and you also get a PermError. Many organisations only discover this when a third-party service they included has quietly let their SPF record lapse.
How a Growing Tech Stack Quietly Pushes You Over the Limit
This is how it happens in practice. A company starts with a straightforward SPF record: Microsoft 365 gets an include, a CRM adds one, the transactional email service adds another. At that point the organisation is probably sitting around 5 or 6 lookups, comfortably within the limit.
Then growth happens. Marketing adds a new automation platform. Support adopts a helpdesk tool that also sends email. The outbound sales team integrates a sequencing tool. Each of these services requires an include statement. Each include triggers lookups of its own, and some of those services use providers that themselves chain to sub-records. Before anyone has audited the SPF record, the organisation has breezed past 10 lookups, and the first sign of trouble is a bounce report.
The uncomfortable truth is that most organisations hit this problem not through negligence but through exactly the kind of growth their business wants. The modern SaaS stack, where every tool sends email on behalf of your domain, is structurally in tension with SPF’s architecture. That tension needs to be managed deliberately.
The DMARC Connection: Why PermError Is Worse Than a Simple SPF Fail
An SPF fail means a sending server was not authorised. A PermError means something more fundamental: the SPF record itself could not be evaluated. DMARC treats these very differently.
When DMARC receives an SPF PermError, it interprets that as an SPF fail. If your DMARC policy is p=none, that may not affect immediate deliverability, but it will show up in your aggregate reports as a systematic authentication failure. If your policy is p=quarantine or p=reject, DMARC will act on that failure according to policy, and your legitimate emails will be quarantined or dropped.
That creates a painful situation: the more security-forward your DMARC posture, the more damage an SPF PermError causes. Organisations that have worked to move from p=none through to p=reject can find that a misconfigured SPF record effectively defeats their own enforcement. The receiving server has no basis on which to trust the message, and the DMARC record tells it exactly what to do with messages it cannot trust.
Given that Google and Yahoo mandated SPF and DKIM authentication for bulk senders starting February 2024, and Microsoft followed suit for its consumer platforms in May 2025, the stakes for getting this right have increased considerably. An SPF PermError is no longer a background noise problem that only affects a percentage of deliveries. It is a compliance failure that can trigger systematic rejection.
Diagnosing the Problem: Finding Out Where Your Lookups Are Going
Before you can fix an SPF PermError, you need an accurate count of where your lookups are being spent. The starting point is straightforward.
Run a DNS query against your domain’s TXT records:
dig TXT yourdomain.com +short
Locate the record starting with v=spf1 and look at every mechanism it contains. Count each include, a, mx, ptr, exists, and redirect. Then follow each include recursively and count the mechanisms in those records too. If you are not comfortable doing this manually, any reputable SPF checker tool will flatten the chain and give you a total lookup count alongside a breakdown of where each lookup originates.
Pay attention to a few common patterns that inflate counts unnecessarily. Duplicate includes are frequent, especially when multiple administrators have added records over time without auditing existing entries. Services that have been decommissioned but whose SPF records were never removed are another source of bloat, and they carry the added risk of becoming void lookups if the provider eventually removes the record. The ptr mechanism is a particular problem: RFC 7208 actively discourages its use due to performance concerns, and it costs a lookup while delivering limited benefit.
Practical Steps to Bring Your SPF Record Back Under Control
Audit and remove stale includes. Go through every include in your chain and verify that the service is still in active use and still requires email-sending authorisation from your domain. Services you no longer use have no place in your SPF record. This step alone frequently recovers two or three lookups.
Replace include statements with direct IP mechanisms. For services that send from a predictable, static IP range, there is no reason to use an include that triggers a DNS lookup. Replace them with ip4: or ip6: mechanisms pointing directly to the address or CIDR block. This is particularly effective for internal mail servers and hosting infrastructure where the IPs are under your control and unlikely to change frequently.
Consolidate redundant mechanisms. Multiple ip4: entries covering adjacent address ranges can often be combined into a single CIDR block. Similarly, if a vendor provides multiple SPF includes across different subdomains, check their documentation: many providers now offer a single consolidated include that replaces all the separate entries.
Remove the ptr mechanism entirely. If your record contains ptr or ptr:domain, remove it. RFC 7208 discourages its use, it costs a lookup, and modern SPF implementations provide no meaningful benefit from it.
Consider SPF flattening for complex environments. SPF flattening is the process of resolving all the DNS lookups in your chain to their underlying IP addresses and publishing those directly, replacing the nested include structure with a single flat record containing explicit ip4: and ip6: entries. This brings the lookup count to one (the primary record query itself). The drawback is maintenance: when a provider changes their sending IPs, your flattened record becomes stale immediately. Automated flattening tools monitor for these changes and update records dynamically, which is the more sustainable approach for organisations with complex sending environments.
Use SPF macros if your infrastructure supports it. For advanced deployments, SPF macros allow dynamic per-recipient evaluation without consuming lookup quota in the traditional sense. This requires more careful configuration but can be the right long-term architecture for organisations managing email at scale.
After the Fix: Validating and Monitoring
Fixing your SPF record is not a one-time exercise. As soon as you add a new SaaS tool, a new marketing platform, or a new transactional email provider, the lookup count goes up again. The organisations that avoid repeat occurrences are the ones that build a review step into their vendor onboarding process and maintain documentation of which services hold a slot in the SPF record.
After making changes, validate the updated record with an SPF checker that performs full recursive resolution. Confirm the total lookup count is at or below 10. Then send test emails through the services you modified and check the authentication headers (Authentication-Results) in the received messages to confirm SPF is passing.
Your DMARC aggregate reports are a secondary verification mechanism. Within a day or two of the fix, you should see the PermError rate drop to zero across the sources that were previously failing. If it does not, there is likely a secondary record or a subdomain sending configuration that has not been addressed.
One Record, One Policy, Consistent Results
A clean SPF record is not complicated infrastructure. It is a controlled list of authorised senders kept deliberately within a hard technical boundary. The organisations that run into repeated SPF PermErrors are usually those that treat the DNS record as an append-only log rather than a maintained policy document.
The good news is that the fix is always available. Unlike some authentication problems that require co-ordination with upstream providers, an SPF PermError is entirely within the domain owner’s control. Audit the record, remove what does not belong, replace dynamic lookups with static IPs where possible, and monitor the count every time the sending environment changes.
If you are working through SPF PermError issues and need help auditing your full authentication posture, including how SPF failures are interacting with your DMARC policy and DKIM alignment, the team at DMARCS can walk through your configuration and identify exactly where the chain is breaking down. Getting this right protects your deliverability, your domain reputation, and the trust your recipients place in every email your organisation sends.
