Why the obscure 10-DNS-lookup limit is now one of the most consequential technical constraints in modern email, and what you should do about it.

Somewhere in your DNS settings, there is a single line of text that determines whether your emails reach their intended recipients or vanish into spam folders. That line is your SPF record. And if your organization uses more than a handful of email-sending services, there is a strong chance that record is either broken right now or one vendor change away from breaking.

The problem is deceptively simple: the Sender Policy Framework specification (RFC 7208) enforces a hard cap of 10 DNS lookups every time a receiving server evaluates your SPF record. Exceed that limit by even one lookup and the result is a PermError, a permanent failure that tells receiving servers your email cannot be authenticated. The server does not try again. It does not look at the rest of your record. It simply stops.

For a small business running email through a single provider, this limit is irrelevant. But for any organization that has added a CRM, a marketing automation platform, a helpdesk tool, a transactional email service, and perhaps an HR system that sends onboarding emails, the math gets uncomfortable very fast. Each of those services typically requires an include statement in your SPF record, and each include triggers at least one DNS lookup, often more through nested references.

Adding Google Workspace alone to an SPF record consumes 4 of the 10 allowed DNS lookups. A typical enterprise setup with 5+ email services routinely exceeds the limit without anyone noticing until emails start failing. (Source: Valimail Help Center)

This is where SPF flattening enters the conversation. According to AutoSPF, SPF flattening resolves all nested include mechanisms into a flat list of IP addresses, reducing DNS lookups from 10 or more down to just 2 or 3. It works. It solves the immediate problem. And it introduces a new set of risks that every organization needs to understand before implementing it.

This article puts the numbers in perspective, connects the technical constraint to real business consequences, and provides a practical framework for deciding whether and how to flatten your SPF records.

The Scale of the Problem: Email Authentication in 2026

To understand why SPF flattening matters, you first need to understand the state of email authentication globally. The numbers paint a picture of an ecosystem that has made significant progress but remains deeply vulnerable.

Most Domains Are Still Unprotected

According to the EasyDMARC 2025 DMARC Adoption Report, which analyzed the top 1.8 million domains by visitor traffic, DMARC adoption grew from 29.1% to 47.7% between 2023 and 2025. That is a 63.9% increase in domains with valid DMARC records, representing meaningful progress. But the flip side of that statistic is stark: 52.3% of the top 1.8 million domains still have no DMARC record at all.

Red Sift’s broader analysis of 73.3 million domains found that only 14.9% have even begun their DMARC journey as of December 2025. The strictest enforcement policy, p=reject, which is the only setting that actually prevents spoofed emails from being delivered, is deployed by just 2.5% of domains globally, roughly 1.8 million out of over 73 million examined.

Validity’s research tells a similar story: among domains and subdomains actively used in email From addresses, 84% have no published DMARC record whatsoever. For .com domains specifically, 75% lack any DMARC record. The numbers are even worse for .net and .org, where over 95% are missing records.

The EasyDMARC 2026 report shows continued growth: valid DMARC adoption reached 937,931 domains by early 2026, up from 523,921 in 2023. But enforcement-level policies (quarantine or reject) grew from just 233,249 to 411,935 in that same period, meaning adoption is outpacing enforcement by a wide margin.

What This Means for SPF Flattening

DMARC relies on SPF and DKIM to function. When DMARC evaluates an incoming email, it checks whether either SPF or DKIM passes and aligns with the From domain. If your SPF record exceeds the 10-lookup limit and returns a PermError, DMARC treats that as a failure. Your email does not just fail SPF, it fails DMARC as well.

This creates a cascading failure: a misconfigured SPF record does not merely cause a technical error in DNS resolution. It undermines your entire email authentication stack, which in turn affects your sender reputation, your deliverability, and your vulnerability to domain spoofing.

For organizations on the path to DMARC enforcement, SPF flattening is not an optimization. It is a prerequisite for organizations whose SPF records have outgrown the 10-lookup limit.

The Regulatory Shift: Why 2024-2025 Changed Everything

For years, email authentication was a best practice. Organizations that cared about security implemented SPF, DKIM, and DMARC. Those that did not faced no real consequences beyond slightly worse deliverability. That era is over.

The Google-Yahoo Mandate

In February 2024, Google and Yahoo began requiring all bulk senders, defined as those sending 5,000 or more messages per day to their platforms, to authenticate emails with both SPF and DKIM and to publish a DMARC record. This was not a suggestion. Non-compliant emails began receiving temporary errors, then partial rejections, and by late 2025, Gmail tightened enforcement to include permanent rejections.

The impact was immediate and measurable. According to Valimail, 265 billion fewer unauthenticated messages were sent in 2024 as a direct result of these requirements. Google’s announcement noted that Gmail’s AI-driven defenses now block nearly 15 billion unwanted emails daily, preventing over 99.9% of spam, phishing, and malware from reaching inboxes.

Microsoft Joins the Enforcement Wave

Microsoft followed suit on May 5, 2025, requiring SPF, DKIM, and DMARC for all domains sending over 5,000 emails per day to Outlook.com, Hotmail.com, and Live.com addresses. Crucially, Microsoft chose to reject non-compliant emails outright rather than routing them to junk folders. The error message is unambiguous: “550; 5.7.515 Access denied, sending domain does not meet the required authentication level.”

The PCI DSS Factor

Adding regulatory pressure, PCI DSS v4.0.1, effective March 31, 2025, mandates that organizations handling card payments implement DMARC policies set to quarantine or reject (Red Sift). This means every e-commerce company, payment processor, and financial services firm now faces a compliance requirement that depends on properly functioning SPF records.

What This Means Practically

Together, Google, Yahoo, and Microsoft account for roughly 90% of a typical business-to-consumer email list. If your SPF record exceeds the 10-lookup limit and triggers a PermError, your emails will fail authentication on all three platforms simultaneously. This is not a gradual degradation. It is an immediate, binary failure that results in bounced messages, damaged sender reputation, and broken business communication.

The convergence of Google, Yahoo, and Microsoft enforcement means that a single broken SPF record can now cut off email delivery to 90% of consumer inboxes overnight.

The Financial Case: What Broken Email Authentication Costs

The business case for fixing SPF records extends far beyond deliverability. Email authentication failures create a direct financial exposure to phishing and business email compromise attacks.

The Phishing Landscape by the Numbers

The FBI’s 2025 Internet Crime Report reveals that total U.S. cybercrime losses surged 26% over the prior year to reach $20.88 billion. Phishing and spoofing was the most commonly reported crime category, with 193,407 complaints in 2024. The Anti-Phishing Working Group recorded approximately 3.8 million unique phishing attack sites worldwide in 2025, with over 1 million detected in the first quarter alone.

Business Email Compromise remains the most financially devastating subset of phishing. According to Hoxhunt’s BEC analysis, BEC caused $2.77 billion in FBI-reported losses from 21,442 complaints in 2024, accounting for 73% of all reported cyber incidents. By 2025, BEC losses crossed $3 billion, representing 14.6% of all cybercrime losses. The FBI IC3 reports nearly $8.5 billion in cumulative BEC losses between 2022 and 2024 alone.

How SPF Failures Enable These Attacks

Here is the connection that many organizations miss: when your SPF record is broken, your domain loses the ability to prove that emails claiming to come from it are actually authorized. This is precisely the vulnerability that phishing and BEC attacks exploit.

A particularly alarming statistic from the Egress Phishing Threat Trends Report found that 84.2% of phishing attacks in 2024 passed DMARC authentication. This means attackers are increasingly using domains that have DMARC records but lack proper enforcement. They are exploiting the gap between having authentication and actually enforcing it, the same gap that a PermError from an over-limit SPF record creates.

When your SPF fails with a PermError, receiving servers cannot distinguish your legitimate emails from spoofed ones. You lose the authentication signal that separates you from attackers. And in a world where DMARC enforcement is now required by every major mailbox provider, that signal is no longer optional.

84.2% of phishing attacks now pass DMARC authentication. The problem is not adoption; it is enforcement. A broken SPF record prevents enforcement entirely. (Source: Egress Phishing Threat Trends Report, 2024)

How SPF Flattening Actually Works

SPF flattening resolves all domain-based mechanisms in your SPF record, such as include, a, mx, and redirect, into their underlying IP addresses. Instead of your SPF record telling a receiving server to look up what IP addresses Salesforce uses, a flattened record lists those actual IP addresses directly.

This works because ip4 and ip6 mechanisms do not count against the 10-lookup limit, as defined in RFC 7208. They require no DNS resolution. So a record that previously needed 15 DNS lookups through nested includes can be reduced to a single lookup for the SPF record itself, with all sending IPs listed directly.

A Practical Example

Consider a mid-sized company using Google Workspace for employee email, Salesforce for CRM, Mailchimp for marketing, SendGrid for transactional email, and Zendesk for customer support. According to Valimail, adding Google Workspace alone requires 4 DNS lookups through nested includes. Their SPF record might look like this:

v=spf1 include:_spf.google.com include:_spf.salesforce.com include:servers.mcsv.net include:sendgrid.net include:mail.zendesk.com -all

Google Workspace alone consumes 4 lookups through its nested includes. Salesforce, Mailchimp, SendGrid, and Zendesk each add 1 to 3 more. The total easily reaches 12 to 15 lookups, well past the limit. The 11th lookup is never evaluated. Any email service listed after that point silently loses authorization, and emails from those services start failing authentication.

After flattening, the same record becomes a list of IP ranges:

v=spf1 ip4:209.85.128.0/17 ip4:172.217.0.0/16 ip4:13.111.0.0/16 ip4:198.2.128.0/18 ip4:167.89.0.0/17 ... -all

The DNS lookup count drops to 1 (just the SPF record itself), and all services are properly authorized.

The Risks: Why dmarcian Says “Don’t”

SPF flattening is not without controversy. In fact, dmarcian, the company whose CTO co-authored the DMARC specification, developed SPF flattening as an experiment and now officially discourages the practice.

Their core argument deserves serious consideration: when you flatten an SPF record, you replace dynamic domain references with static IP addresses. Those IP addresses change. Google, Microsoft, SendGrid, and other providers regularly add, remove, and rotate their sending infrastructure. When they do, your flattened record becomes instantly outdated. Emails sent from the new IP addresses fail SPF authentication because those addresses are not in your record.

dmarcian also raises a subtler but equally important point: most organizations that need SPF flattening have SPF records that are too bloated in the first place. As their best practices guide explains, records often contain include statements for vendors that are no longer in use, services that do not actually send email from the organization’s domain, or entries that authorize far more of the internet than necessary. The result is an increased attack surface where bad actors can gain access to wrongly authorized IP ranges and send email from your domain.

The Better-Than-Flattening Checklist

Before flattening, dmarcian and other experts recommend these steps, which often eliminate the need for flattening entirely:

Audit your SPF record and remove entries for services you no longer use. This is the single most effective step. Many organizations carry include statements for vendors they discontinued years ago.
Remove a and mx mechanisms. These are often included by default by hosting providers but rarely serve a legitimate purpose. MX records are for receiving email, not sending it.
Move vendor traffic to subdomains. Instead of authorizing Mailchimp to send from yourdomain.com, configure it to send from marketing.yourdomain.com with its own dedicated SPF record. This is a best practice that completely sidesteps the lookup limit for your primary domain.
Check for duplicate netblock authorizations. Sometimes multiple include statements resolve to overlapping IP ranges. Removing redundancies can recover precious lookups.
Use DKIM as the primary DMARC alignment method for services where SPF alignment is difficult or impossible. DMARC only requires one of SPF or DKIM to pass and align. For some vendors, DKIM is simpler and more reliable.

If after completing all of these steps your SPF record still exceeds 10 lookups, then and only then is flattening the appropriate solution.

If You Must Flatten: A Decision Framework

For organizations that genuinely need SPF flattening after exhausting the alternatives above, the choice is between manual flattening and automated (dynamic) flattening. The differences in risk profile are significant.

Manual Flattening

Manual flattening involves querying each include domain for its current IP ranges, then replacing the include statements with those IPs in your SPF record. It is free, requires no third-party tools, and gives you complete control.

The downside is maintenance. You must monitor every provider for IP changes and update your record promptly. Miss a change and your emails from that provider fail authentication. For organizations using multiple dynamic email services, this is an ongoing, high-stakes maintenance task that demands constant vigilance.

Automated (Dynamic) Flattening

Automated tools continuously resolve your include statements, detect IP changes, and update your flattened record automatically. Some, like AutoSPF, rescan every 15 minutes. Others use SPF macros rather than traditional flattening, which allows an unlimited number of includes without running into the lookup limit at all.

The tradeoff is vendor dependency. Your email authentication now depends on a third-party service maintaining uptime and accuracy. If their service goes down or their DNS infrastructure fails, your SPF record becomes unresolvable.

A Practical Hybrid Approach

Consider partial flattening: flatten only the services with stable, rarely-changing IP ranges (such as your own infrastructure), while keeping dynamic services like Google Workspace and Microsoft 365 as includes. This reduces lookups while maintaining the automatic IP updates for the most dynamic providers.

v=spf1 include:_spf.google.com ip4:167.89.0.0/17 ip4:208.117.48.0/20 -all

In this example, Google stays as an include (they manage their own IPs and change them frequently), while SendGrid’s relatively stable IP ranges are flattened directly. This preserves the dynamic updating where it matters most while reducing the overall lookup count.

The Global Adoption Picture: Where We Stand

The push toward proper email authentication is uneven across geographies and sectors. Understanding where your industry and region stand can help benchmark your own posture.

Country-Level SPF Adoption

SPF adoption rates vary considerably by country. According to AutoSPF’s 2024 risk analysis, the USA leads with a 92% adoption rate among surveyed domains, followed by the UK at 87%, Canada at 85%, and Germany at 83%. However, a critical nuance is that these figures reflect the presence of an SPF record, not whether that record is correctly configured or within the 10-lookup limit.

Among the top 1 million domains globally, DMARC Checker’s 2024 analysis found that 39% lack an SPF record entirely. The adoption rate improves significantly with domain prominence: 77% of the top 1,000 domains have valid SPF records, but this percentage declines steadily as domain ranking decreases.

The National Policy Effect

The EasyDMARC 2025 report found a dramatic correlation between national DMARC mandates and phishing outcomes. The United States, which has mandatory DMARC requirements, reduced successful phishing delivery from 69% to 14%. By contrast, the Netherlands, which lacks enforcement mandates, saw phishing vulnerability increase to 97%.

This data suggests that regulatory mandates are the single most effective driver of authentication adoption, and by extension, the strongest motivator for organizations to get their SPF records in order, including through flattening when necessary.

Sector-Specific Patterns

The PowerDMARC Norway 2025 report offers a useful sector-level view: Healthcare leads with 92.1% correct SPF implementation, followed by Government at 90.0%. The Education sector trails at 79.1%. In financial services, 44.7% enforce the strictest DMARC reject policy, compared to just 9.1% in the transport sector.

The Openprovider Global Domain Name Report 2025 corroborates this trend: in 2024, 75% of businesses faced domain-based phishing attempts, pushing the industry to respond with faster takedowns and tighter collaboration between registrars, registries, and agencies.

These patterns are consistent globally: regulated industries (healthcare, finance, government) lead adoption, while less regulated sectors lag. If your organization is in a regulated industry, proper SPF management is increasingly a compliance requirement, not just a security best practice.

Your Action Plan: A Phased Approach

Based on the data and expert guidance compiled in this research, here is a practical roadmap for addressing SPF complexity in your organization.

Phase 1: Assess (Week 1)

Run your domain through an SPF lookup tool (MxToolbox, dmarcian SPF Surveyor, or EasyDMARC SPF checker) to count your current DNS lookups.
Document every include statement and trace it to the service or vendor it belongs to.
Identify which services are actively sending email from your primary domain versus subdomains.
Check whether each service actually requires SPF authorization or if it only uses DKIM for authentication.

Phase 2: Clean (Weeks 2-3)

Remove include statements for vendors you no longer use.
Eliminate unnecessary a and mx mechanisms.
Remove duplicate netblock authorizations.
Migrate vendor traffic to subdomains where possible. This is the highest-impact long-term solution.
For remaining services, verify whether DKIM alignment alone can satisfy DMARC, allowing you to remove the SPF include entirely.

Phase 3: Flatten If Necessary (Week 4)

If your SPF record still exceeds 10 lookups after cleaning, implement flattening.
Start with partial flattening: keep dynamic providers (Google, Microsoft) as includes, flatten stable ones.
If using manual flattening, set calendar reminders for monthly IP range reviews.
If using automated tools, ensure you understand the vendor’s SLA and failover behavior.
Test your flattened record in a staging environment before updating production DNS.

Phase 4: Monitor and Enforce (Ongoing)

Publish a DMARC record at p=none if you have not already and begin collecting aggregate reports.
Analyze DMARC reports to verify that all legitimate email sources pass authentication.
Gradually move to p=quarantine and then p=reject as confidence grows.
Set up SPF monitoring alerts for record changes, lookup count increases, and provider IP changes.
Review and audit your SPF record quarterly as part of your domain maintenance routine.

Key Takeaways

The data tells a clear story:

SPF flattening is a necessary workaround for a real architectural limitation. The 10-DNS-lookup limit was designed in 2006 when organizations used one or two email services, not ten.
The stakes have never been higher. Google, Yahoo, and Microsoft now reject non-compliant emails outright. PCI DSS requires DMARC enforcement. The cost of broken email authentication is measured in billions of dollars of fraud losses annually.
Flattening is not the first solution. Cleaning your SPF record and migrating vendor traffic to subdomains should always be attempted first. Many organizations can eliminate the need for flattening entirely through proper hygiene.
If you flatten, do it safely. Automated tools are strongly preferred over manual flattening for any organization using dynamic email providers. Partial flattening offers a balanced approach for most use cases.
SPF is not a standalone solution. It is one layer in an authentication stack that includes DKIM and DMARC. A perfectly configured SPF record is meaningless without DMARC enforcement to act on its results.

Sources and Further Reading

This article draws on data from the following primary sources. All statistics were verified as of April 2026. Each source is linked below with its full URL for reference.

SPF Flattening: The Hidden Email Infrastructure Problem Costing Businesses Billions