A password reset email is sent out. It never arrives. No error message on the sender’s side, no bounce, no alert in your sending tool. Just silence. In some cases, the cause is a SPF record that has exceeded its limit of 10 DNS queries, without anyone in the organization realizing it. This is known as a PermError. It happens far more frequently than people think in companies using multiple SaaS services for their mailings.
What the SPF limit is and why it exists
The SPF (Sender Policy Framework) is an email authentication protocol that allows a domain to declare which servers are authorized to send on its behalf. The limit of 10 DNS lookups per SPF check is specified in RFC 7208 (IETF, 2014), the official protocol specification. It is not optional: the RFC stipulates that an SPF implementation must return a permanent error if this threshold is exceeded.
The technical reason is concrete. Each SPF mechanism like include:, a, mx, ptr or exists triggers an additional DNS query. Without a cap, a malicious or misconfigured SPF rule could force receiving servers to chain dozens of DNS queries, creating excessive load on recursive resolvers and opening the door to denial-of-service attacks. The mechanisms ip4:, ip6: and all do not trigger any queries and are not counted in the limit.
This cap dates back to when a company rarely had more than one or two email sending providers. In 2014, Microsoft 365 did not exist under this name, Salesforce Marketing Cloud was still called Exact Target, and HubSpot represented only a fraction of its current usage. The limit was designed for a world that is no longer ours.
Why today’s SaaS companies reach this limit without noticing
The problem lies in how modern email services publish their own SPF records. An include: for a provider doesn’t cost just one lookup: it costs as many as the provider has defined in its own record, including nested includes. Google Workspace (_spf.google.com) consumes between 3 and 5 lookups on its own. Microsoft 365 (spf.protection.outlook.com) consumes 3 to 5 depending on regional configuration. Add SendGrid (1 to 3), Salesforce (1 to 3), and HubSpot (1 to 2): the total exceeds 10 even before you’ve added the billing service, HR platform, or support tool.
What exacerbates the situation: providers can change their DNS infrastructure without notifying you. The service you delegated an include: to six months ago may have added new servers in the meantime, moving your count from 9 to 12 lookups without any action on your part. According to data from dmarcchecker.app regarding the top 1 million domains (2024), 2% of domains with a valid SPF record already have an invalid configuration causing a PermError. This figure seems low but represents thousands of organizations whose legitimate emails are permanently affected, often without the IT teams knowing.
What actually happens when the threshold is exceeded
When an SPF check reaches 11 DNS queries, the receiving server returns a permerror result, a permanent unrecoverable error. What happens to the email then depends on the DMARC policy DMARC configured on the sending domain.
With p=none, the email is usually delivered despite the PermError. The domain is treated as unauthenticated. This is a false sense of security: emails go through. The protection against domain spoofing does not exist. With p=quarantine, emails land in spam without an alert on the sender’s side. With p=reject, the strictest policy and the one that Google and Yahoo have been requiring since February 2024 for senders of more than 5000 messages per day, emails are rejected. Order confirmations, password resets, security alerts, and internal communications disappear without a trace in the sending tools.
It’s the hardest scenario to diagnose. The email goes out. It doesn’t come back. It doesn’t arrive.
SPF flattening: why the quick fix makes it worse
The most common reaction to this problem is “SPF flattening”: replacing all include: mechanisms with the corresponding IP addresses, bringing the number of lookups down to zero or almost. The immediate result is positive. The medium-term effects are more problematic.
The CTO of dmarcian summarizes the core issue well: most flattened records end up authorizing IP address ranges that are far too broad, belonging to large cloud hosts, some of which do not correspond to any real sending server of the provider. Malicious actors can exploit these authorized ranges to send from your domain. You solve a deliverability problem by creating a security problem.
The other difficulty is maintenance. Email providers change their IP pools regularly, without notice. A flattened record must be updated manually with each change, or else the provider’s new servers are excluded and the emails they handle fail the SPF authentication. Flattening turns a configuration problem into an ongoing operational burden.
Approaches that are sustainable over time
The first step is an audit of the actual count. Tools like MXToolbox, dmarcian’s SPF Record Checker analyze your SPF record and count cascading lookups, including nested includes. Without this audit, it’s impossible to know where the counter actually stands.
Segmentation by subdomains is the most reliable architectural solution. Moving marketing emails to marketing.yourdomain.com and transactional emails to notifications.yourdomain.com gives each subdomain its own quota of 10 lookups. This separation has an added advantage: a reputation issue on marketing campaigns does not affect critical transactional emails.
For domains that cannot easily segment, SPF macros are a serious alternative. They take the evaluation out of the standard lookup chain, passing the check to an external service via a single DNS query. Solutions work on this principle. The downside is real: if the provider’s infrastructure goes down, the domain’s SPF authentication goes with it.
The most often overlooked measure remains removing no longer needed entries. Many SPF records accumulate include: entries for providers the company hasn’t used in months or a and mx mechanisms inherited from an old configuration. An annual audit often recovers several lookups without touching the sending architecture.
Monitor over time, don’t just fix once
An SPF record that’s compliant today may exceed the threshold tomorrow if a provider changes its infrastructure. Aggregated DMARC reports (RUA format) are the most accessible indicator: they show the proportion of emails that pass or fail SPF authentication for each declared sending domain. Any sudden spike in SPF failures warrants an immediate investigation into the lookup count.
The 10 lookups SPF limit is a constraint from 2014 that RFC 7208 has not revised since. Organizations transitioning to DMARC enforcement, as Google requires since 2024 for volume senders, sometimes discover it at the worst moment: when their critical emails stop arriving and no one knows why.
What is an SPF PermError?
An SPF PermError is a permanent error returned by the receiving server when the SPF verification cannot be completed, particularly because the number of DNS queries exceeds 10. Unlike a TempError (recoverable temporary error), a PermError persists until the SPF record is corrected. DMARC treats a PermError as a complete SPF failure.
Do ip4 and ip6 mechanisms count in the 10 lookups limit?
No. The mechanisms ip4:, ip6:, and all do not trigger any DNS queries and do not count towards the limit. Only mechanisms that require DNS resolution are counted: include:, a, mx, ptr, exists, and the redirect modifier.
How to know if my SPF record exceeds the limit?
Tools like MXToolbox SPF Checker, dmarcian’s domain checker analyze the SPF record and count cascading DNS lookups, including nested includes. A result greater than 10 confirms that the record returns a PermError at each verification, regardless of the DMARC policy in place.
