SPF Is Not a Checkbox: What Published Records Really Protect

Executive takeaway

Publishing SPF is a starting point, not proof of reliable sender authorization. The studies measure different populations, years, and outcomes, so their headline rates are not interchangeable. Records can contain syntax errors, exceed lookup limits, or authorize senders too broadly. Domain owners should review validity, external dependencies, authorization settings, and DMARC policy alongside DKIM.

They should also distinguish published policies from observed receiver handling. Commercial forecasts indicate expected demand for authentication services, not demonstrated improvements in protection.

Why three SPF studies give three different answers

56.0%, 62.8%, and 36.7% appear to give conflicting answers to a simple question: how many domains use SPF? Yet the studies count different populations, cover different years, and apply different definitions of adoption.

SPF, or Sender Policy Framework, identifies infrastructure authorized to send mail for a domain. This analysis asks a narrower question than whether domains publish records: what evidence demonstrates usable sender authorization? It compares supplied research summaries rather than conducting an independent DNS scan.

The DMARCguard February 2026 scan found SPF records on 56.0% of 5,499,028 domains in its Tranco sample. That measures record presence, not successful evaluation or appropriate authorization.

SpamCipher’s 2026 study reported 62.8% presence among resolvable domains from a top-million sample. Its DNS-resolvability restriction and different sampling frame mean the percentages describe different populations.

Fortra provides a 2025 historical comparison with those 2026 measurements. Its 10-million-domain study found 36.7% published syntactically valid SPF records. This stricter threshold measures compliance with formatting rules, rather than publication alone.

Figure discussion: Three scans, three numbers, one paradox. The comparison combines two 2026 presence estimates with a 2025 validity estimate. It should display each study’s year, population, and outcome alongside its percentage. These are not interchangeable estimates of protection.

Fortra’s remaining 63.3% is not a missing-record rate. Its 2025 findings distinguish 61.9% without SPF from 1.4% with syntax errors. Combining them describes failure to meet the syntax-validity threshold, but conceals different remediation needs.

The two 2026 presence estimates differ by 6.8 percentage points, calculated as 62.8 minus 56.0. That difference alone establishes neither measurement error nor growth. A trend requires comparable populations and methods measured over time.

Source: DMARCguard, 2026; SpamCipher, 2026; Fortra, 2025 historical comparison

SpamCipher reports a 95% confidence interval of 62.2–63.4% and an independent OpenINTEL cross-check within 1.5 percentage points. These describe reported uncertainty and measurement agreement. Without the full methods, neither establishes representativeness across all internet domains.

Fortra’s lower result also cannot be attributed entirely to its stricter definition. Syntax errors account for only 1.4 percentage points within its dataset; sample selection and year also differ. A matched comparison would be needed to separate those effects.

The studies therefore offer different starting points, not competing verdicts on universal protection. Their practical value depends on separating publication from validity, operational evaluation, and policy.

DMARCguard, SpamCipher, and Fortra report SPF adoption between 36.7% and 62.8%, but each samples a different population and validity standard. Method: Values compiled directly from each publisher’s stated methodology and results; ‘headline risk figure’ rows for DMARCguard and SpamCipher are calculated as 100% minus their reported adoption rate, while Fortra’s 63.3% is quoted directly from its own combined calculation.

What SPF tells you—and what it does not

SPF describes sender authorization, not message trustworthiness or guaranteed delivery. Understanding that boundary requires separating the published record from its evaluation and the receiver’s response.

Presence means a domain publishes an SPF record, normally as DNS TXT text beginning with v=spf1. Finding that text establishes that instructions exist, not that they authorize only appropriate senders.

Syntax validity means the instructions follow SPF’s formatting rules. A valid record can still express an excessively permissive authorization policy. For example, Fortra’s analysis identifies +all records, which authorize any sending server. Correct formatting and selective authorization are separate properties.

Operational evaluation asks whether a receiver can complete the check. Some SPF mechanisms and modifiers require DNS lookups, including through referenced policies. SPF limits these lookup-triggering operations to ten during evaluation; this is not simply a count of visible record entries or every DNS packet.

Exceeding that limit produces a permanent evaluation error, or permerror. The DMARCguard supply-chain study reports such overruns among domains that already publish SPF. Publication and syntactic correctness therefore cannot establish successful evaluation.

An authentication result describes what the check determined. It can indicate authorization, a negative result, or an evaluation error. That result does not itself establish where the receiver ultimately placed the message.

Within SPF, ~all specifies softfail for otherwise unmatched senders; -all specifies fail, often called hardfail. Hardfail does not automatically mean rejection, and softfail does not guarantee delivery. Receiver handling remains a separate decision.

DKIM and DMARC address related questions. DKIM uses cryptographic signatures to support message authentication. DMARC checks whether a successful SPF or DKIM result aligns with the domain in the visible From address. It also lets domain owners publish requested handling for failures.

That distinction explains why Stripo’s secondary review reports DMARC validity and enforcement separately. Usable instructions, a restrictive published policy, and observed receiver handling are different outcomes. None alone demonstrates comprehensive protection against phishing.

How a published record can still go wrong

Published SPF records can fail in several distinct ways. Syntax errors obstruct interpretation, lookup overruns interrupt evaluation, and unrestricted authorization removes sender selectivity. Softfail belongs in a different category: it is a policy choice, not inherently a broken record.

As a 2025 historical comparison, Fortra’s Q2 analysis reported syntax errors in 1.4% of its all-domain sample. It also reported lookup-limit overruns in 1.1% and +all in 0.045%. These figures describe separate conditions; the supplied evidence does not establish whether their affected populations overlap.

The distinction matters for remediation. Malformed instructions need correction, while lookup overruns require examining the evaluation path and its dependencies. Replacing +all requires deciding which senders should actually be authorized.

DMARCguard’s 2026 analysis found 148,655 domains exceeding the lookup limit, or 4.8% of 3,077,219 SPF-enabled domains. Unlike Fortra’s rate, this percentage counts only domains publishing SPF in its denominator.

Source: DMARCguard SPF Supply Chain, 2026

Those percentages do not establish deterioration between 2025 and 2026. Different samples, denominators, and potentially different evaluation methods prevent a direct trend comparison. They establish that both datasets contain lookup overruns, not that overruns became more prevalent.

An overrun returns permerror, rather than a successful authorization decision. It does not automatically instruct every receiver to reject the message. Conversely, +all can produce a successful SPF result while providing no meaningful sender restriction. Neither measurement establishes how often affected domains experienced abuse or how other controls handled their mail.

DMARCguard also reports ~all on 53.5% of SPF-enabled domains. Softfail communicates a weaker negative signal than hardfail for unmatched senders. A valid record can intentionally use it while remaining within the lookup limit.

That percentage measures configuration, not accepted messages, rejected messages, or successful spoofing. The evidence does not establish administrators’ reasons for choosing softfail. Treating all such records as defective would confuse policy strength with technical failure.

Your SPF record depends on other organizations

An SPF record can depend on authorization information maintained by another organization. An include mechanism references another domain’s SPF policy during evaluation. The owner chooses the dependency but does not necessarily control its contents.

In DMARCguard’s Tranco scan, Microsoft 365 appeared in 19.6% of SPF-enabled domains, and Google Workspace appeared in 13.6%. These percentages describe provider presence, not shares of email traffic or successful delivery.

Their arithmetic sum is 33.2%, but that is not a verified unique-domain share. Some domains may authorize both providers, and the supplied evidence does not quantify overlap. Describing the providers as serving one-third of distinct SPF-enabled domains would therefore overstate the finding.

External policies can change without an edit to the domain owner’s record. Such changes may alter authorization or the work required during evaluation. This follows from the dependency mechanism; it is not a documented incident in the scan.

The operational implication is to track both local configuration and referenced policies. Teams should know which sending service requires each dependency and who owns that relationship. When results change, inspecting only the local record may leave part of the evaluation unexplained.

Provider concentration does not establish a cascading outage or quantify its potential reach. The supplied evidence reports neither a shared incident nor comparative provider reliability. It therefore cannot show that large providers are less suitable than smaller alternatives.

The appropriate response is dependency awareness, not avoidance of popular platforms. Trace external authorization relationships during review and troubleshooting, rather than assuming an unchanged local record means unchanged behavior.

Microsoft 365 and Google Workspace together account for about a third of SPF-enabled domains’ sender includes, concentrating dependency risk. Method: Shares for Microsoft 365 and Google Workspace are taken directly from DMARCguard’s SPF Supply Chain 2026 report; the ‘other/self-hosted providers’ slice is calculated as the residual (100% minus the two named shares).

Which domains you count changes the story

The population being counted determines what an adoption rate can tell us. Website rankings, national samples, and enterprise classifications describe different populations. Their percentages cannot support a global ranking of email security.

DMARCguard’s Tranco study reports 77.1% SPF adoption among ranks 1–1,000 and 74.0% in the next reported tier. The supplied evidence labels that tier ranks 1,000–10,000; its boundary convention remains unverified. The reported rates differ by 3.1 percentage points, calculated by subtraction.

These two groups suggest higher publication among the most prominent domains. They do not establish better configuration, stronger enforcement, or a consistent decline across lower ranks. Website prominence also cannot substitute for organizational size without evidence linking the two.

National measurements require a separate interpretation. The supplied summary of the Joint Research Centre report describes country-code and government-linked domain populations. However, it does not establish the measurement year or enough detail about coverage for a defensible numerical comparison here. Apparent differences cannot confidently be attributed to geography, regulation, or time.

Source: MarketIntelo, published 2025; reported 2026 estimates

Enterprise figures introduce another distinction: they concern DMARC, not SPF. The commercial DMARC compliance report gives a historical comparison of 48.3% enterprise adoption in 2023 with an estimated 62.4% in 2026. Its listed publication date is in 2025, so the 2026 figure should not be treated as an observed scan result.

The same commercial report places adoption at 87.6% for large enterprises and 41.2% for small and midsize businesses. Their calculated difference is 46.4 percentage points. The supplied material does not clearly establish these figures’ measurement date or enough methodological detail to validate their comparability.

Budget and staffing differences could help explain that reported gap, but they remain hypotheses. The evidence does not test them or show whether adopters consistently publish restrictive policies.

Three questions keep these comparisons grounded:

• Who was counted? Ranked domains, national samples, and businesses are different populations.
• What was measured? SPF publication, DMARC adoption, and restrictive policy are different outcomes.
• How was the figure produced? Domain scans and commercial estimates carry different evidential limits.

A higher percentage may indicate broader deployment within one defined sample. It does not, by itself, demonstrate stronger protection than another sample.

Global enterprise DMARC adoption climbed from under half to nearly two-thirds between 2023 and 2026, even as enforcement policies lag behind. Method: Values taken directly from Marketintelo’s DMARC Compliance Market Research Report, which estimates global enterprise adoption at two points in time.

Authentication and enforcement are different decisions

Publishing authentication records and requesting enforcement are different decisions. A DMARC adoption count does not reveal whether a domain requests monitoring, quarantine, or rejection. Even a rejection policy describes requested handling, not observed receiver behavior.

The commercial DMARC compliance report states that 28.4% of enterprise DMARC adopters use p=reject. This policy requests rejection of messages that fail DMARC. Its denominator is enterprise adopters—not all enterprises or all domains.

The figure supports a narrow finding: fewer than three in ten adopters in that reported population request rejection. It does not show that every remaining adopter only monitors traffic. The supplied evidence does not disclose the complete policy distribution, including quarantine.

The estimate also has unresolved methodological limits. Sampling, policy classification, and the measurement date cannot be independently assessed from the supplied material. It should not be presented as a verified census of enterprise configurations.

Stripo’s review, published in 2026, reports 18.2% with valid DMARC records and 7.6% enforcing DMARC in a stated top-10-million-domain population. This secondary summary distinguishes validity from enforcement, but its publication year does not establish the underlying measurement year.

Those percentages cannot be directly compared with the enterprise estimate. Stripo’s denominator includes its full stated domain population, while the enterprise percentage starts with adopters. Its broader term “enforcement” also cannot automatically be equated with p=reject.

The reports support distinguishing four questions: whether a record exists, whether it is valid, what handling it requests, and what receivers actually do. Neither report establishes consistent receiver compliance or measures prevented impersonation. Authentication deployment should therefore remain separate from demonstrated enforcement—and neither should be described as a complete phishing defense.

What the spending forecasts actually tell us

Market forecasts describe expected commercial demand, not whether authentication controls work. They estimate revenue or spending in defined categories rather than measuring reliable sender authorization.

Two publishers provide different 2025 historical baselines for comparison with later forecasts:

• Marketintelo estimates a $2.1 billion authentication-monitoring market, with SPF accounting for 22.1%.
• Dataintelo estimates a $1.91 billion market, with SPF accounting for 28.7%.

These are publisher estimates, not audited totals. Different category boundaries or assumptions could explain the disagreement, but the supplied evidence does not verify either explanation.

Multiplying each market estimate by its SPF share implies approximately $464 million and $548 million, respectively. These are calculations from reported estimates, not independently observed revenues. The smaller total market produces the larger implied SPF segment, illustrating why headline market size alone is insufficient.

A broader email authentication and DMARC forecast projects growth from $2.1 billion in 2025 to $5.8 billion by 2034. This category should remain separate from the monitoring estimates because their boundaries are not established as equivalent.

Figure discussion: Authentication spending growth, not near-quadrupling. The supplied endpoints imply approximately 2.76 times the historical baseline, or 176% growth. Fourfold growth from $2.1 billion would reach $8.4 billion, not $5.8 billion. The figure should identify the market category, distinguish the 2025 baseline from the 2034 projection, and avoid implying an observed annual trajectory.

The monitoring and broader authentication estimates should not be added together. Their categories may overlap, and the evidence does not establish mutually exclusive coverage. Averaging conflicting estimates would likewise conceal unresolved methodological differences rather than resolve them.

The defensible conclusion is that these publishers expect substantial demand for authentication-related services. Their forecasts do not demonstrate valid configurations, strict enforcement, or improved protection from purchased tools. Procurement should instead ask what evidence a service provides about the organization’s actual controls.

Market researchers project the SPF/DKIM management and DMARC markets to grow roughly three- to four-fold within a decade. Method: Figures compiled directly from two market research reports’ stated current and projected market sizes for SPF/DKIM management and DMARC.

Four checks for a more trustworthy SPF setup

A useful SPF review needs four checks, not one “record found” result. The following recommendations synthesize the configuration issues above; they are not a tested management framework.

1. Confirm record presence and valid syntax. Check that the relevant sending domain publishes an SPF TXT record beginning with v=spf1. Validate the complete record rather than treating that prefix as proof of correctness. Presence confirms publication; syntax validation confirms formatting. Neither establishes appropriate authorization or successful evaluation. As a 2025 historical comparison, Fortra’s reported syntax errors affected 1.4% of its all-domain sample, illustrating why publication alone is insufficient.
2. Evaluate the complete lookup burden. Follow lookup-triggering mechanisms and modifiers, including nested provider dependencies. Counting only visible entries in the local record can miss operations required during evaluation. Exceeding SPF’s ten-lookup limit produces permerror, not a universal rejection instruction. DMARCguard’s 2026 analysis found overruns in 148,655 of 3,077,219 SPF-enabled domains, or 4.8%. Use diagnostics that explain the evaluation path and each dependency’s contribution. A successful check describes the evaluated configuration; it cannot guarantee that externally maintained policies remain unchanged.
3. Review authorized senders and the all mechanism. Compare authorizations with services that legitimately send mail for the organization. A valid, lookup-compliant record can still authorize unnecessary infrastructure. Inspect the qualifier attached to all, which determines the result for otherwise unmatched senders. +all grants unrestricted authorization, ~all returns softfail, and -all returns fail. Neither negative result guarantees a particular receiver action. Inventory and verify legitimate senders before removing authorizations or moving toward hardfail. This is an operational precaution against disrupting legitimate mail, not an outcome measured by the supplied studies.
4. Assess DMARC alongside SPF and DKIM. Review the domain’s DMARC policy and authentication results from legitimate sending services. Check whether successful SPF or DKIM authentication aligns with the visible From domain. Distinguish p=none, which requests no DMARC-specific delivery action, from p=quarantine and p=reject. Examine observed results rather than assuming the published policy establishes receiver behavior. This review can identify policy settings and whether sampled legitimate messages meet authentication requirements. It does not guarantee receiver compliance or eliminate phishing, including attacks that do not impersonate the organization’s exact domain.

Presence alone is not protection: syntax validity, the 10-lookup limit, and the hardfail setting each determine whether a published SPF record actually works. Method: Decision logic built from thresholds reported by Fortra and DMARCguard (syntax validity, RFC 7208’s 10-lookup limit, and softfail vs. hardfail mechanisms); the tree is an editorial synthesis for reader diagnosis, not a reproduction of either firm’s internal scoring system.

Measure working controls, not published records

Measure whether controls work as intended, not merely whether records exist. The evidence distinguishes publication, syntax validity, evaluation reliability, authorization scope, and requested handling. A single adoption percentage cannot represent all five.

Internal reporting should separate these properties. As an editorial synthesis—not a validated framework—the following categories provide a practical starting point:

• Inventory: Which domains belong in the reporting population, and which publish SPF?
• Validity: Which records pass syntax checks?
• Lookup errors: Which evaluated records exceed the limit, including through external dependencies?
• Authorization settings: Which senders are authorized, and what result applies to unmatched senders?
• DMARC policy: Which domains request no action, quarantine, or rejection?

Where available, report observed receiver handling separately from published policy. An SPF hardfail setting or DMARC rejection request does not itself demonstrate that failing messages were rejected.

Comparisons also require consistent populations, dates, and denominators. Fortra’s 2025 historical comparison counts lookup overruns across its full sample, while DMARCguard’s 2026 rate counts SPF-enabled domains. Their difference cannot establish a change in reliability without comparable measurement methods.

Likewise, the two cross-sectional 2026 presence estimates do not prove adoption is increasing.

• They describe different domain populations, not successive observations of a common population.
• Repeated, clearly defined checks would provide a stronger basis for measuring progress.

The practical priority is to investigate the gap between published instructions and intended behavior. Track configuration quality, understand dependencies, and gather operational evidence that SPF, DKIM, and DMARC work together. Neither a larger adoption headline nor a growing market forecast can substitute for that evidence.

Limitations

• This comparative desk analysis uses only supplied evidence summaries and source metadata. Full source texts, methods, and underlying datasets were not independently inspected or validated.
• Different populations, measurement years, and denominators prevent direct comparisons. The supplied scans do not establish a global SPF adoption trend.
• Commercial estimates and secondary summaries have unresolved methodological limits. Forecasts are not observed outcomes, and several reported figures lack clear measurement dates.
• Provider overlap is unspecified, so Microsoft 365 and Google Workspace percentages cannot establish their combined unique-domain coverage.
• The scan comparison includes a 2025 historical study. The spending forecast supports approximately 2.76-fold growth, not near-quadrupling.

References

1. Global DMARC Adoption Trends in Q2 2025
2. DMARC Compliance Market Research Report 2033
3. PDF Email Authentication at Scale: A Systematic Review and 2026 …
4. Email Authentication Monitoring Market Research Report 2034
5. Email Authentication Monitoring Market Size, Share & Forecast Report 2025 to 2034 | Dataintelo
6. SPF Supply Chain 2026: Email Sender Market Share Across …
7. Competitor Landscape
8. Top 10 email security statistics every business should know
9. Email communication security standards - JRC Publications