The SPF Lookup Ceiling: Why Publishing a Record Is Not Enough

Executive takeaway

Publishing SPF does not guarantee that receivers can evaluate it successfully. A February 2026 scan reported 148,655 SPF-publishing domains above the lookup ceiling—roughly one in 21. Another large scan found substantial exposure, but different populations and denominators prevent direct comparison. Neither establishes confirmed attacks or a rising failure rate. Teams should inspect nested sender dependencies, evaluate lookup requirements, and verify aligned authentication before tightening DMARC enforcement. Treat SPF as a maintained dependency, not a one-time installation.

The limit hiding inside your SPF record

Can receiving mail servers evaluate the SPF record your team already publishes? Publishing SPF and maintaining evaluable SPF are different operational tasks. A record can exist in DNS yet exceed the protocol’s evaluation limit.

Sender Policy Framework, or SPF, lets a domain identify servers authorized to send mail on its behalf. Receivers retrieve that policy through DNS, the system that publishes domain information. SPF checks sender authorization; it does not establish whether a message is harmless.

The constraint is SPF’s ten-lookup ceiling, a protocol requirement rather than an administrator’s preference. The supplied summary of DMARCguard’s SPF research identifies configurations that cross this boundary. Such configurations can produce permerror, a permanent SPF evaluation error.

“Ten lookups” does not mean ten vendors, ten visible include entries, or ten network queries. The limit concerns DNS-lookup-causing SPF terms encountered during evaluation, including nested dependencies. Counting visible names or measuring record length cannot establish compliance.

An include refers to another SPF policy, often maintained by an email provider. That policy can introduce further dependencies, making a short record more demanding than it appears. Administrators therefore need to examine evaluation requirements beyond their own published text.

An authentication result is not a delivery decision. A permerror alone does not establish whether a receiver rejected, quarantined, or delivered a message. Nor does an over-limit configuration prove exploitation. The operational question is narrower: can the published policy perform its authorization check within the protocol’s constraints?

One in 21 SPF domains crossed the ceiling

DMARCguard’s February 2026 scan reported 148,655 SPF-publishing domains exceeding the ten-lookup ceiling. This identifies a configuration problem among deployed records, rather than simply missing authentication.

According to the supplied summary, the DMARCguard study covered the complete Tranco Top Sites list: 5,499,028 domains. Of these, 3,077,219 published SPF, representing 56.0% of the scanned population. The 148,655 over-limit domains represented 4.8% of SPF publishers, not all scanned domains.

Source: DMARCguard, February 2026 scan

“One in 21” is a rounded calculation, not a separate observation. Dividing 3,077,219 publishers by 148,655 over-limit domains gives approximately 20.7. The shorthand retains the publisher-only denominator.

The scan measured configurations in February 2026; the source appeared in March 2026. These dates distinguish observation from publication. The snapshot does not establish whether individual records subsequently changed or whether overflow prevalence was rising.

The domain count also does not measure email failures. The supplied findings do not establish message volumes, receiver-specific evaluations, or delivery outcomes. A domain-level configuration assessment cannot supply those missing message-level observations.

Domain prominence provides adoption context, but not an overflow ranking. DMARCguard reports SPF publication among 77.1% of the top 1,000 domains and 74.0% across the next 9,000. Both exceed the complete-list adoption rate of 56.0%. Without overflow rates for those same groups, however, higher adoption cannot establish greater lookup-limit exposure.

A 10x10 grid representing SPF-enabled domains, shaded to show the share exceeding RFC 7208’s ten-lookup limit. Method: Value taken directly from DMARCguard’s Feb 2026 Tranco scan: 148,655 of 3,077,219 SPF-enabled domains exceed the limit, equal to 4.8%.

Why 4.8% and 1.1% are not competing answers

The 4.8% and 1.1% figures use different denominators. DMARCguard reports overflow among SPF publishers; Fortra reports it across all scanned domains. Neither percentage should replace the other without specifying the question being answered.

As a 2025 comparison with the February 2026 scan, Fortra’s Q2 2025 benchmark covered 10 million domains. It identified 110,732 exceeding the lookup ceiling, approximately 1.1% of the full sample. The supplied summary divides that sample into three categories:

• 3,666,641 domains, or 36.7%: syntactically valid SPF records.
• 140,843 domains, or 1.4%: records categorized as erroneous through syntax errors or excessive lookups.
• 6,192,516 domains, or 61.9%: no SPF record.

The all-domain denominator includes nonpublishers, which cannot contribute published-record overflow cases. A publisher-only denominator instead measures overflow among domains that have deployed SPF. This distinction explains part of the apparent difference, but not necessarily all of it.

Calculation: dividing DMARCguard’s 148,655 over-limit domains by all 5,499,028 scanned domains gives approximately 2.7%. This expresses the same finding against a broader population. It is neither a new observation nor a correction to its publisher-based headline.

The supplied research proposes dividing Fortra’s 110,732 overflow cases by its 3,666,641 valid records, yielding approximately 3.0%. That is not a clean prevalence estimate if overflow cases belong to the separate erroneous-record category. A prevalence numerator must be contained within its denominator.

Conditional calculation: adding Fortra’s valid and erroneous categories gives a candidate publisher denominator of 3,807,484 domains. Dividing 110,732 by that total yields approximately 2.9%. This interpretation depends on those categories representing distinct publishing domains, which cannot be independently checked here.

Even that adjustment does not make the studies equivalent. They use different domain populations and observation periods; the supplied evidence does not establish identical evaluation procedures. Population selection, classification, or configuration changes could each contribute to the difference.

Both scans identify substantial numbers of domains with lookup-limit exposure. They do not establish a temporal trend. Presenting 1.1% followed by 4.8% as an increase would confuse differences in measurement with changes over time.

Side-by-side comparison of two large-scale SPF scans, showing how scan size, SPF adoption, and lookup-overflow rates differ. Method: Cells populated with figures reported directly by each source; no recalculation applied within the table itself.

How sender dependencies make records harder to evaluate

SPF dependencies explain why visible record size is an unreliable diagnostic. A direct include appears in the domain’s own policy; a nested include appears inside a referenced policy. The latter can add evaluation requirements without appearing in the administrator’s top-level record.

The supplied DMARCguard sender-market analysis reports Microsoft 365 includes in 19.6% of SPF-enabled domains, with Google Workspace at 13.6%. These figures illustrate reliance on externally maintained sender policies. They do not measure either platform’s overflow rate.

The populations can overlap, so adding the percentages would not establish the share using either service. Nor does platform prevalence demonstrate that Microsoft 365 or Google Workspace causes lookup overflow.

A provider’s internal dependencies must also be distinguished from a customer’s separate services. Marketing platforms, help desks, and customer relationship management systems may have their own authorizations. Their presence does not establish that a mailbox provider nests those vendors within its policy.

Consider a hypothetical organization that adds marketing and support services alongside its mailbox provider. Each authorization may introduce dependencies requiring inspection. This shows how vendor accumulation could increase lookup pressure; it is not a measured explanation for the reported overflows. Establishing that cause would require records of specific additions and their effects on evaluation.

Count evaluation requirements, not vendor names. One visible include can lead to additional includes, while explicit IP-address entries require no further DNS resolution. The evaluation path can also depend on the sending IP address and earlier matches. A useful assessment therefore considers relevant sending paths rather than treating every possible dependency as necessarily encountered.

Referenced policies can change without an edit to the customer’s own record. Those changes may alter evaluation requirements. External authorization consequently creates a maintenance obligation, not just an initial configuration task.

Source: DMARCguard, 2026

What independent measurement does—and does not—confirm

Corroborating adoption does not independently validate lookup compliance. Another dataset provides reassurance only about the property it actually measures.

The supplied summary of a systematic review reports SPF adoption of 62.8% among resolvable top-million domains in 2026. Its reported 95% confidence interval is 62.2–63.4%. An independent OpenINTEL snapshot, collected on separate infrastructure, reportedly came within about 1.5 percentage points of that adoption estimate.

This agreement supports the adoption measurement, but its strength depends on methodological details unavailable here. Similar domain lists, observation periods, or classification rules could influence agreement. Separate collection infrastructure alone does not resolve those questions.

The confidence interval likewise describes reported statistical uncertainty, not every potential source of error. It does not establish representativeness or exclude classification problems. Assessing its construction would require information about sampling, exclusions, and DNS failures.

The supplied review summary contains no independent overflow estimate directly comparable with DMARCguard’s 4.8%. Its OpenINTEL comparison therefore cannot confirm that figure. The defensible interpretation remains a dataset-specific estimate, not a universal rate.

European findings require similar restraint. The supplied summary of the Joint Research Centre report describes SPF adoption above 85%, alongside widespread strict policy settings. The measurement year, institutional coverage, and sampling boundaries are unclear in the available evidence. These findings cannot establish current adoption across every EU domain or compliance with the lookup ceiling.

Three questions must remain separate:

• Deployment: Does the domain publish SPF?
• Evaluation: Can its policy be evaluated within the lookup limit?
• Enforcement: What action does its DMARC policy request when DMARC authentication fails?

Evidence answering one question should not silently answer the others. High adoption, strict policies, and evaluable SPF are distinct properties.

SPF trouble is not automatically DMARC failure

An SPF error does not automatically mean DMARC failure. DMARC can pass through either SPF or DKIM when the authenticated domain aligns with the visible From domain. Both mechanisms do not need to succeed.

SPF authenticates the sending server against the relevant envelope domain, which can differ from the visible sender. DKIM supplies a separate route through a digital signature associated with a signing domain. For either route to satisfy DMARC, its authenticated domain must align with the visible From domain.

Aligned DKIM can therefore preserve DMARC success when SPF returns permerror. Conversely, an SPF or DKIM pass for an unrelated domain does not suffice. This corrects the supplied research’s overbroad claim that DMARC always depends on evaluable SPF.

SPF errors still matter because they can remove one authentication route. If legitimate mail also lacks valid, aligned DKIM, neither mechanism can satisfy DMARC. A p=reject policy then creates a risk of legitimate-mail rejection, although receiver handling remains a separate question.

Deployment statistics cannot resolve these message-level outcomes. The supplied research attributes enterprise adoption figures to a commercial DMARC compliance report. As an explicit historical comparison, it reports 48.3% for 2023 against 62.4% for 2026. However, the source’s listed publication year is 2025, leaving the status of its 2026 figure uncertain.

The available evidence does not establish whether 62.4% is a forecast, estimate, or observation. It also does not demonstrate consistent sampling across years. These figures therefore cannot support a verified adoption trajectory.

The reported 28.4% reject-policy share among adopters has similarly unclear timing and methodology. Attribution is also uncertain: the raw narrative uses a DataIntelo hostname, while the source list identifies MarketIntelo. The available evidence does not establish that these reports are interchangeable.

Nothing supplied connects that reported enforcement gap specifically to SPF overflow. Before tightening policy, administrators should assess actual SPF results, DKIM validity, and alignment. The relevant question is whether legitimate messages retain a working, aligned authentication route.

Global enterprise DMARC adoption rose sharply from 2023 to 2026, even as strict reject-policy enforcement stayed a minority practice. Method: Two-point values taken directly from Dataintelo’s DMARC Compliance Market report.

Who should investigate first?

Prioritize dependency complexity and incomplete visibility, not organization size alone. Size may guide an initial inquiry, but the supplied evidence does not rank overflow incidence by company size.

A 2025 Dataintelo report estimates complete deployment at 67.3% for large enterprises and 42.1% for small and mid-size businesses. These commercial figures describe reported rollout coverage, not independently verified lookup compliance. Sampling methods, respondent definitions, and verification procedures are unavailable in the supplied evidence.

Deployment coverage and configuration validity require different checks. An organization may report completion while individual records remain unevaluable. Conversely, a domain with few dependencies may still lack SPF or authorize the wrong senders.

Larger sender inventories may create more opportunities for dependencies to accumulate. Yet organization size is only an indirect clue. The relevant evidence concerns the services a particular domain authorizes and the evaluation requirements those authorizations introduce.

As an operational inference, prioritize domains where complexity meets limited configuration visibility:

• Many sending platforms: inspect dependencies beyond the visible top-level entries.
• Unclear authorization ownership: establish which permissions remain necessary and who maintains them.
• Incomplete domain inventories: verify coverage before relying on organization-wide completion claims.
• No recent configuration assessment: check evaluation behavior rather than treating publication as validation.

This creates two investigation queues: domains needing deployment review and domains needing deeper dependency assessment. An organization can belong in both, regardless of size. These priorities identify uncertainty to investigate, not organizations proven to be compromised.

Source: Dataintelo, 2025

What the tooling market can tell us

Tooling revenue measures purchasing, not lookup compliance. Commercial market estimates can describe demand for management services, but cannot establish technical failure rates.

As historical context for the 2026 operational evidence, the supplied research reports a $1.34 billion SPF/DKIM management market in 2024. It attributes this estimate to a Dataintelo market report. The underlying methodology is unavailable here, and the category extends beyond preventing SPF lookup failures.

A LinkedIn-hosted SPF configuration-management analysis reportedly assigns approximately 45% of revenue to enterprise teams, 30% to cloud and hosting providers, and 15% to small businesses. Its unclear methodology makes it weaker evidence than a transparent operational measurement.

Those shares total approximately 90%. The supplied evidence neither explains the remainder nor establishes whether the categories overlap. Higher enterprise revenue could reflect larger contracts, broader product bundles, or more customers. It does not demonstrate higher overflow incidence.

The supplied commercial research also places SPF-specific tooling at 22.1% to 28.7% of authentication monitoring, depending on category definitions. The range is associated with reports including Marketintelo’s authentication-monitoring analysis. Without aligned definitions and measurement periods, these estimates cannot establish a change in configuration reliability or be combined into one market total.

For procurement, the useful question is what configuration evidence a tool produces. Price, popularity, and market growth cannot show whether a particular domain stays within SPF’s evaluation limit. Selection should focus on demonstrable dependency inspection and evaluation capabilities. Purchasing a tool supports validation only when its results establish something about the actual configuration.

SPF configuration-management market revenue concentrates in enterprise security teams, followed by cloud and hosting providers. Method: Segment shares taken directly from the LinkedIn Pulse market-share analysis of the SPF configuration management market.

A four-step check before you tighten enforcement

Before tightening DMARC enforcement, separate publication, authorization, lookup compliance, and message authentication. The following checks translate the configuration findings into a practical review without assuming every over-limit domain loses mail.

1. Confirm that the domain publishes SPF. Check the specific domain rather than assuming organization-wide deployment covers it. Record publication status separately from evaluation results. The supplied DMARCguard findings show why presence alone provides incomplete assurance.
2. Inventory direct and nested sender dependencies. Identify referenced sending services and inspect their nested policies. Establish which authorizations remain necessary for legitimate mail and who owns them. Treat unfamiliar entries as investigation targets, not automatic deletion candidates. An SPF flattening tool simplifies nested SPF records to help reduce DNS lookups and stay within the ten-lookup limit.
3. Evaluate lookup requirements against the ten-lookup ceiling. Assess relevant evaluation paths, including nested dependencies, rather than estimating from vendor count or record length. Exactly ten reaches the ceiling; more than ten exceeds it. A path requiring ten has no remaining headroom, but that alone is not a protocol violation. Additional requirements could push that path over the limit and produce permerror. Review zero-headroom configurations without mislabeling them as overflow. Repeat assessment when sender dependencies change.
4. Review aligned authentication before changing DMARC enforcement. Check legitimate sending paths before moving toward stricter policies, particularly p=reject. Examine SPF results alongside DKIM validity and alignment with the visible From domain. Either aligned mechanism can satisfy DMARC; an SPF error alone does not establish DMARC failure.

Keep the resulting claims proportionate to the evidence. Configuration scans identify lookup-limit exposure, while message-level observations are needed to assess authentication and delivery outcomes. Percentages require explicit denominators; the reported 4.8% and 1.1% do not establish growth.

The evidence supports ongoing SPF dependency review and authentication checks, not claims of confirmed exploitation or a demonstrated increase in failures. Publishing the record begins the work; maintaining evaluable authorization is the continuing task.

A practical diagnostic path for domain owners to check whether their SPF record risks exceeding the ten-lookup ceiling. Method: Decision logic constructed from the reliability mechanics and thresholds reported in the DMARCguard and Fortra scans.

Limitations

• This paper synthesizes supplied source summaries. Full source methods and underlying data were unavailable for independent verification; no new scanning was performed.
• Different domain populations, dates, and classifications prevent a clean overflow trend or directly comparable prevalence estimate.
• The scans measure configuration exposure, not message-level failures, confirmed attacks, or losses. No third dataset in the supplied evidence independently confirms the 4.8% overflow estimate.
• Commercial estimates have uncertain methods, dates, or attribution. The supplied research also oversimplifies SPF lookup counting and DMARC behavior; those simplifications are not adopted here.

References

1. PDF Email Authentication at Scale: A Systematic Review and 2026 …
2. Email Authentication Monitoring Market Research Report 2034
3. SPF Supply Chain 2026: Email Sender Market Share Across …
4. Email Authentication Monitoring Market Size, Share & Forecast Report 2025 to 2034 | Dataintelo
5. Global DMARC Adoption Trends in Q2 2025
6. DMARC Compliance Market Research Report 2033
7. SPF DKIM Management Market Research Report 2033
8. SPF Configuration Management Market Share Trends and Demand …
9. Email communication security standards - JRC Publications