SPF Is Nearly Universal—Until You Change the Sample

Executive takeaway

SPF adoption has no single reliable headline rate. The research ranges from 56.0% in a large ranked-domain scan to 88–96% in an EU assessment, while a curated email dataset reports almost universal SPF passing. Those results measure different things. For email-security teams, the useful questions are which domains were counted, what counted as adoption, and whether published records work in practice.

Benchmark against a comparable population, then look beyond record presence to configuration quality, sending-provider dependencies, and DMARC policy. High adoption is encouraging, but it is not a guarantee of protection or inbox placement.

Nearly Universal for Whom?

SPF adoption looks very different depending on where you look. A March 2026 scan of 5.5 million domains from the Tranco Top Sites list found that 56.0% published a valid SPF record—a substantial share, but hardly “nearly universal.”

The European Commission’s Joint Research Centre, meanwhile, reported 88–96% SPF adoption across EU member states in its email communication security assessment. Read without context, those figures might look like competing answers to the same question: how much of the internet has adopted SPF?

They are better understood as answers to different questions. A broad, popularity-ranked collection of domains and the domains covered by an EU assessment are not interchangeable populations, even when both results carry the label “SPF adoption.”

That makes the most important word in an adoption claim not “universal,” but “among.” Adoption among which domains, selected how, measured when, and counted according to what definition?

Before unpacking those questions, it helps to understand what SPF actually does. As explained in NIST’s Trustworthy Email guidance, Sender Policy Framework lets a domain publish a record in DNS—the internet’s directory system—identifying the servers authorized to send mail on its behalf.

A receiving mail system can then check whether the server delivering a message has that authorization. In everyday terms, SPF is a published permission list for sending infrastructure, not a seal of approval for everything inside an email.

That distinction matters when interpreting the percentages. Publishing a record and achieving effective protection are separate questions: the first concerns what a domain has configured; the second concerns whether the setup works as intended and contributes to handling suspicious mail safely.

Even “has SPF” needs care. A measurement that counts records merely being present is not necessarily measuring the same outcome as one that checks whether those records are valid, and neither alone proves that legitimate messages consistently pass authentication.

The denominator—the full group being counted—deserves just as much attention as the success criterion. A large sample can provide a useful benchmark for the population it covers without becoming a census of every domain that sends email.

Likewise, the EU’s high figures are worth examining as a strong-adoption case study. They should not automatically become a global benchmark, and the percentages alone do not establish that regulation caused the result.

A useful way to approach any adoption headline is to ask three questions:

• Who was counted? Identify the population before comparing its percentage with another study.
• What counted as adoption? Separate record presence from validity and successful authentication.
• What does the result establish? Treat configuration measurements as evidence about configuration, not a complete verdict on protection.

The goal here is not to declare one study the winner. It is to build a practical way to evaluate adoption claims, choose a defensible comparison for your own domains, and turn a published SPF record into part of a maintained email-authentication setup.

Four Studies, Four Views of SPF

SPF adoption looks different depending on which domains enter the count—and what qualifies as adoption. The four measurements below are best read as four views of different populations, not competing attempts to establish one internet-wide percentage.

SPF lets a domain publish a DNS record identifying servers authorized to send email on its behalf. That makes a DNS scan a useful starting point, but finding a record is not necessarily the same as finding a valid configuration, observing successful authentication, or demonstrating protection against impersonation.

• Tranco-wide scan: 56.0%. DMARCguard’s SPF supply-chain research reports that 56.0% of 5.5 million domains drawn from the Tranco Top Sites list published a valid SPF record in a March 2026 scan. The population is a large popularity-ranked domain set; the outcome is valid-record presence, not the percentage of messages passing SPF.
• Academic configuration study: a comparable band. The 12-million-domain study examined SPF configuration in the wild, putting broad-sample prevalence in a comparable band to the ranked-domain findings while investigating configuration quality. It should not be converted into a fourth precise adoption estimate here: its broader configuration focus and sampling context matter alongside its scale.
• Top-million tracker: 62.8%. The 2026 authentication review reports SPF publication for 62.8% of resolvable top-million domains—domains for which DNS resolution succeeded. That wording matters: the denominator is not automatically every entry in the original million-domain list, and “published SPF” should not silently become “fully valid and effective SPF.”
• EU MECSA assessment: 88–96%. The European Commission Joint Research Centre’s email security assessment reports SPF presence of 88–96% across the assessed domains in EU member states. This is a high-adoption result within the MECSA assessment population, not a measurement of every domain worldwide—or evidence that every assessed domain’s email consistently authenticates.

The two ranked-domain results are separated by 6.8 percentage points, or roughly seven points. That is the difference between 62.8% and 56.0%, not a seven-percent relative increase, and it does not by itself establish that either measurement is wrong.

Their labels already reveal important differences: one covers 5.5 million domains and counts valid records, while the other covers resolvable domains within a top-million population and reports publication. A narrower popularity tier, different ranking inputs, crawl timing, DNS-resolution rules, and record-validation criteria can all contribute to the gap; the supplied findings do not isolate how much each factor explains.

The top-million estimate also reportedly agrees with the independent OpenINTEL measurement series to within roughly 1.5 percentage points, according to the authentication review. That is useful cross-validation: a separate measurement series provides reassurance that the result is not simply an isolated scanner artifact.

But agreement is strongest evidence within the context being compared. Two measurements can closely agree about a particular domain population without showing that the same rate applies to less popular domains, domains outside that sampling frame, or domains that actively send mail.

Timing needs the same care as population. March 2026 is the reported crawl date for the Tranco-wide result, whereas a report’s publication year tells readers when an analysis appeared, not necessarily when its DNS observations were collected.

The academic paper’s linked first version dates to February 2025, so it should not be described as a fresh 2026 crawl merely because it appears beside 2026 research. Likewise, the top-million result is described here as a 2026 snapshot; more specific collection dates should not be inferred where they are not supplied.

The EU range adds another valuable comparison, but it cannot bridge those methodological differences on its own. A government-operated assessment is not automatically a representative global sample, and a high observed adoption rate does not establish that regulation alone caused it.

The defensible comparison therefore keeps three labels attached to every finding: which domains, measured when, and counted how. On that basis, these studies show substantial SPF deployment across several populations—with notably higher reported presence in the EU assessment—without supporting a single “nearly universal” benchmark.

Four 2026-era SPF adoption studies used different sample frames and produced different headline percentages, illustrating why ‘SPF is nearly universal’ depends on which population is measured. Method: Rows compile sample size, measurement year, primary method, and policy-strength notes as reported in each source; cells are drawn directly from published figures with no independent reconciliation across studies.

Why the Domains You Count Change the Result

A domain’s chance of appearing in a study depends on how researchers build their list. A popular retailer, a parked registration, and a small business’s website may all have domain names, but a web-popularity ranking does not give them equal representation.

That is why the denominator—the population being counted—is part of the finding, not just a methodological detail. A percentage describing highly visible organizational domains answers a different question from one describing all registered domains, including those with little traffic or no active website.

Popularity-ranked samples tend to favor established organizations with the resources to maintain their email systems. A parked domain held for resale, an abandoned brand-protection registration, or a neighborhood business’s rarely visited site may fall outside the sample altogether.

These examples make the selection problem tangible, but they do not establish an adoption rate for excluded domains. A plausible reason to expect differences is not a measurement of those differences: without scanning that broader population, we cannot say exactly how much it would change the result.

The 5.5-million-domain SPF scan illustrates why scale and representativeness are separate issues. It found 56.0% valid SPF among domains drawn from a popularity-ranked list—a substantial measurement, but not a census of every registered domain.

Adding millions of entries makes a ranked sample larger; it does not remove the ranking-based selection rule. Domains outside the list remain outside the study, and “valid SPF” remains a specific outcome rather than a synonym for every possible definition of adoption.

A separate top-million estimate reported 62.8% SPF adoption among resolvable domains. Subtracting that from 100 gives 37.2% without SPF under that estimate’s definitions and inclusion rules.

A separately reported statistic puts the share of top-million domains lacking SPF at 39%. Those figures are in approximate agreement, but they are not interchangeable findings: 37.2% is a calculated complement of one estimate, while 39% is a separately reported result.

The roughly seven-percentage-point difference between 62.8% adoption and 56.0% valid SPF likewise should not become a simple claim that one study contradicts another. Different ranking lists, scan dates, resolution criteria, and definitions can affect the comparison; the supplied figures do not isolate how much each factor contributes.

Now change the unit being counted from domains to messages. A privacy-research dataset covering 150 popular services and apps found that 99.96% of post-signup emails passed SPF checks.

That near-perfect result describes received messages from selected senders in a particular workflow. It does not mean that 99.96% of domains publish SPF, or even that the same percentage of all email sent by those services would pass in every circumstance.

SPF checks whether the sending server is authorized for the domain used in the relevant email identity. Looking for a published DNS record and observing a message pass that check are therefore different measurements, even though both are often summarized casually as “SPF adoption.”

The distinction becomes clearer when each result is translated into its actual question:

• Ranked-domain scan: How many domains on this selected list have the measured SPF configuration?
• Resolvable top-million estimate: How common is SPF within the domains that meet this tracker’s inclusion rules?
• Post-signup message dataset: How often did the collected messages from these selected services pass SPF?
• Full-registry census: What is the rate across the broader registered-domain population—a question these ranked-list figures do not settle?

For a reader choosing a benchmark, the closest-looking percentage is not necessarily the most useful one. The useful comparison matches the population, the unit counted, and the outcome measured; otherwise, a change in the sample can masquerade as a change in email security.

Source: SpamCipher, 2026; A Framework to Audit Email Address Privacy and Analyze…, 2024

Read the Fine Print Before Sharing the Percentage

Before sharing an SPF adoption percentage, turn it into a sentence about a defined group of domains at a defined time. The denominator—the domains included in the calculation—is part of the finding, not a technical detail to omit for readability.

That matters because “SPF adoption” can describe anything from finding a published DNS record to validating its configuration. Neither result, by itself, tells you whether a particular message passed authentication or whether a receiver blocked an impersonation attempt.

A repeatable reading method starts with five questions:

1. Which population was sampled? Identify whether the study covers a popularity-ranked list, a registry, national domains, or another selected group. A large sample is not automatically representative of every domain that sends email.
2. What is the denominator? Look for whether the percentage includes all selected domains, only domains that resolved successfully, or only a mail-related subset. Excluding unreachable domains changes the question the measurement answers.
3. When were the observations collected? Record the DNS collection date or window, not just the article’s publication year. A recently published report can describe older observations, and a continuously updated page may contain figures from different periods.
4. How were DNS failures handled? Check whether timeouts were retried and whether missing records, failed queries, and malformed answers were counted separately. “No SPF found” should not silently become interchangeable with “the scanner could not complete its query.”
5. What counted as adoption? Ask whether the scanner merely detected an SPF record, checked its syntax, evaluated its dependencies, or observed actual message authentication. Those are different tests with different evidentiary limits.

For example, the Tranco-wide scan reports 56.0% valid SPF across 5.5 million domains drawn from a popularity-ranked list. That supports a claim about that scan’s population and validation method—not a claim that precisely 56.0% of the internet’s email senders are protected.

A compact headline qualification could read: “A scan reported in 2026 found valid SPF on 56.0% of 5.5 million Tranco-listed domains.” Add the actual collection window when verified; “reported in 2026” does not establish when the DNS queries ran.

Next, separate four outcomes that adoption headlines often compress into one:

• Published record: The domain has an SPF declaration in DNS, the system that publishes domain information.
• Valid record: The declaration meets the study’s stated validity tests; check what those tests include.
• Stronger policy: An ending such as -all declares unlisted senders unauthorized more firmly than ~all, which produces a softfail result.
• Passing message: A receiver evaluates a particular message and finds its sending infrastructure authorized for the domain SPF checks.

Even the third outcome needs careful wording. As NIST’s email-security guidance helps explain, authentication results inform handling decisions: SPF hardfail is not a guarantee of receiver rejection, and an SPF pass alone does not establish that the visible From address is authentic.

Time series need similarly precise attribution. The longitudinal tracker discussed in this review describes SPF adoption as remaining near 60% since 2022; that is a plateau in the cited tracking series, not proof that adoption across the whole internet has stopped changing.

An older SPF figure may therefore remain a useful comparison within that series, provided its population and method remain comparable. The review describes DMARC adoption as moving faster, so its figures may age differently; do not assume that two percentages published together have the same useful shelf life.

Finally, look for a preview of configuration quality: does validation check SPF’s limit of 10 DNS-query-causing terms during evaluation, including nested dependencies? Counting visible include entries alone is insufficient because a provider’s record can trigger further lookups.

That question connects the headline to operational reality without requiring a full configuration audit. A defensible percentage says who was counted, when, and under which rules; a maintained authentication setup must also keep working when its dependencies change.

A practical decision guide for checking what population an SPF adoption statistic actually describes before citing it. Method: Tree structure synthesizes the sample-frame distinctions documented across the cited 2026 and earlier studies into a reader-facing diagnostic flow; typical result ranges reflect the figures reported in each study.

Europe’s Strong Showing Needs Context

Europe provides a strong example of SPF uptake—but not a shortcut to an internet-wide adoption rate. The European Commission’s Joint Research Centre reports 88–96% SPF adoption across EU member states, compared with 74–92% for the assessed non-EU domains, in its email communication security assessment.

That comparison is useful because both groups were assessed using the same MECSA tools. It reduces the methodological mismatch involved in comparing unrelated studies, although it does not make the underlying populations identical or representative of every domain in their respective regions.

The ranges also overlap: the non-EU upper endpoint, 92%, exceeds the EU lower endpoint, 88%. The finding is therefore a higher reported EU band, not a clean divide in which every EU result outperforms every non-EU result.

Source: European Commission Joint Research Centre, 2023 and 2026 editions as described in the supplied research

Same tools, different denominator

MECSA’s country-oriented assessment answers a different question from a scan of domains selected through a popularity ranking. The Tranco-based SPF supply-chain study, for example, reports 56.0% valid SPF across 5.5 million domains—a different population and an explicitly validity-based measure.

Placing 56.0% beside 88–96% can illustrate how much the sample matters, but it cannot establish a comparable European lead. One result describes a large ranked-domain collection; the other reports a range across national populations assessed by MECSA.

Nor does the government operation of a scanning platform make its findings automatically more representative. Who runs the measurement, which domains enter it, and what counts as adoption are separate questions. A defensible comparison needs those questions answered before treating percentages as equivalent.

A higher floor, not a three-point average gain

The 2023 JRC assessment reported EU SPF adoption of 85–96%. Compared with the later report’s 88–96%, the change is straightforward but narrower than a claim that “EU adoption rose three points”:

• The lower endpoint rose three percentage points, from 85% to 88%.
• The upper endpoint remained at 96%.
• Those endpoints do not establish a three-point increase in an EU average.

A range describes the spread between reported extremes, not the distribution of results between them. Without the underlying country values and an explicit weighting method, it cannot tell us how much a typical member state—or an EU-wide domain-weighted average—changed.

Strong SPF uptake is not uniform security uptake

The same assessment offers a useful contrast with much lower reported DANE/DNSSEC adoption figures: 2–5%, compared with 1–4% in the 2023 report. These concern DANE and DNSSEC, mechanisms associated with publishing and validating authentication information through DNS; they are not measurements of SPF validity or successful message authentication.

That contrast shows why SPF’s high uptake should not stand in for adoption of every email-security standard. It also does not turn record adoption into evidence that every message is authenticated or protected.

Regulatory exposure belongs in the context, not in the causal conclusion. EU organisations operate within a particular policy environment, but these measurements alone do not isolate regulation’s effect from differences in providers, deployment practices, or sample composition.

The practical reading is therefore specific: MECSA documents a high-adoption European case study within its assessed population. It offers a useful benchmark when its population and metric match the question—not a universal target against which every domain scan should be judged.

Four SPF adoption percentages shown as progress rings, visualizing the spread between global ranked-list estimates and the EU’s high-adoption measurement. Method: Values plotted directly from each source’s headline SPF adoption percentage; EU figures shown as both the low and high end of the reported 88-96% range.

The EU’s SPF adoption band has crept up slightly at the low end (85% to 88%) while plateauing at the high end (96%), per successive JRC assessments. Method: Low-end and high-end values of the reported EU SPF adoption range from the 2023 and 2026 JRC email communication security standards reports, plotted as before/after points per band edge.

Having SPF Is Not the Same as Getting It Right

53.6% of SPF-enabled domains in the Tranco scan use softfail (~all), according to A Large-Scale Study on SPF Configuration in the Wild. That finding changes the question from “Does this domain publish SPF?” to “What does its policy actually say about senders it has not authorized?”

SPF lets a domain publish rules identifying which servers may send mail using its identity in the SMTP transaction. A receiver evaluates the sending server against those rules; the presence of a DNS record alone does not establish that the rules are strict, complete, or operationally reliable.

The distinction between softfail and hardfail matters, but it is easy to overstate. These are different authentication results and policy signals, not commands that mechanically determine whether every receiving system accepts, quarantines, or rejects a message.

• Softfail (~all) expresses that a sender falling through to this rule is probably not authorized, without making the stronger assertion of failure.
• Hardfail (-all) expresses that a sender falling through to this rule is not authorized and produces an SPF fail result.
• Neither result guarantees a particular delivery outcome. Receivers apply their own handling policies and may consider other authentication results and signals.

Calling softfail “flag, not reject” is therefore too prescriptive, just as calling hardfail “automatic rejection” is too strong. NIST’s Trustworthy Email guidance provides the broader authentication context: a published sender policy supplies information for a receiving system to use, rather than controlling every receiver’s behavior.

The Tranco finding consequently measures something narrower than either broken SPF or ineffective protection. It shows that a majority of SPF-enabled domains in that sample use a less definitive policy for otherwise unmatched senders; it does not establish why each domain chose it or whether changing the final character would make its mail setup correct.

There is also a harder technical boundary: SPF evaluation permits at most 10 DNS-lookup-triggering terms. This is not simply a limit of 10 entries in the published record, nor a flat count of every DNS packet exchanged during a check.

The terms that count toward this limit are include, a, mx, ptr, exists, and redirect; mechanisms such as ip4, ip6, and all do not consume that budget. Crucially, the limit applies across the evaluation, including the terms encountered inside nested policies, as discussed in the large-scale configuration study.

An include asks the receiver to evaluate another domain’s SPF policy. If that policy includes additional policies, those evaluations can consume more of the same budget, so a short-looking record can conceal a much longer chain.

When an evaluation exceeds the limit, SPF returns PermError, meaning a permanent error, rather than completing with an ordinary pass, fail, or softfail result. “Permanent” describes the error category, not a claim that the configuration can never be repaired; it also does not mean that every possible sending path through the record necessarily reaches the same error.

This is why checking syntax is only a starting point. A record can be correctly written yet exceed the evaluation budget, and changing ~all to -all does nothing to repair that problem.

The management-focused research, SPF Beyond the Standard: Management and Operational Challenges, documents the ongoing administrative difficulty of maintaining SPF, including keeping policies within the lookup limit. Its relevance is practical: correctness is something administrators must preserve as sending arrangements change, not a status earned permanently when a record is first published.

For an operational review, several questions therefore deserve separate answers:

• Does the record parse correctly?
• Does it authorize the systems that actually send mail?
• Can relevant evaluations finish within the lookup budget?
• What result does it produce for unauthorized senders?
• Will changes to sending services trigger another review?

These checks should not be collapsed into a single “SPF present” label. A defensible configuration assessment distinguishes publication, evaluability, authorization accuracy, and policy strength—and recognizes that all four need maintenance.

Your SPF Record Has a Supply Chain

An SPF record can look like a small piece of DNS configuration, but it often points to infrastructure managed by other companies. When a domain delegates sending to a hosted mailbox service or another email provider, its record may use an include mechanism to incorporate that provider’s SPF policy.

That makes SPF more than a list of servers an organisation owns. It can also be a map of external services trusted to send on the domain’s behalf—and of dependencies that someone must keep under review.

The existing SPF sender market-share measurement puts Microsoft 365 at 19.6% and Google Workspace at 13.6% of SPF-enabled domains in the scan. These figures describe provider references found in domain-level SPF records, not the percentage of email messages those providers deliver or their share of provider revenue.

The denominator matters even within that narrower interpretation: these are percentages of SPF-enabled domains in the sample, not of all internet domains. A domain-level count also gives no indication of whether a domain sends a handful of messages or operates a busy email service.

Nor should the two percentages be added together and presented as a disjoint combined market share. A domain may reference multiple senders, so without an overlap measurement, the figures establish neither a unique combined share nor a “67% remainder” attributable to everyone else.

The operational significance lies in what an include does. Rather than copying a provider’s sending addresses into its own policy, a domain asks the SPF evaluator to consult the provider’s policy when checking whether a sending server is authorised.

That delegation can simplify deployment because the provider manages its own underlying authorisations. It does not remove the customer’s responsibility to know which services are authorised or whether the complete policy remains usable.

SPF evaluation has a limited budget for DNS-querying mechanisms and modifiers. As explained in NIST’s trustworthy email guidance, the relevant limit is 10 during an SPF check; exceeding it produces a permanent error rather than a successful authentication result.

An include can lead to further includes, so counting only the entries visible in the domain’s top-level record is not enough. The budget is shared across the evaluated dependency chain, rather than reset for each provider.

This is why a provider reference is both a convenience and a configuration dependency. A policy that appears short can still require substantial evaluation, while adding another legitimate sender can introduce more work than its single visible include suggests.

Research on SPF management and operations documents administrative friction around keeping configurations within the lookup limit. The practical challenge is therefore not simply publishing the right text once, but maintaining authorisation across services whose configurations and business roles can change.

For administrators, that suggests a review process built around dependencies rather than provider popularity. The following are practical implications, not outcomes measured by the market-share scan:

• Inventory actual senders. Record which services send using your domains, including hosted mailboxes and separate business applications.
• Assign an owner to each dependency. Someone should be able to explain why an include exists and which workflow depends on it.
• Inspect the full evaluation chain. Check nested dependencies and the lookup budget, not just the length of the published record.
• Review changes before deployment. Adding or replacing a sending service should trigger a check of the resulting SPF configuration.
• Retire permissions deliberately. Confirm that a service is no longer needed before removing its authorisation, and avoid leaving obsolete dependencies indefinitely.

The provider figures help make this supply chain visible, but they do not measure how well individual organisations manage it. Their useful operational lesson is to treat an SPF record as a maintained set of delegated permissions—not as a one-time adoption checkbox.

Microsoft 365 and Google Workspace lead SPF include references, but together they account for only about a third of SPF-enabled domains, leaving the majority tied to smaller or unidentified providers. Method: Microsoft 365 and Google Workspace shares are taken directly from the SPF Supply Chain 2026 study; the ‘other/unidentified’ share is calculated as 100% minus the sum of the two named providers’ shares.

The Bigger Gap Is Between Authentication and Protection

A high SPF adoption rate answers a limited question: how many domains publish information about their authorized senders? It does not establish that messages claiming to come from those domains will pass authentication—or that impersonation attempts will be blocked.

The larger protection gap becomes clearer when SPF is placed alongside DKIM and DMARC. NIST’s Trustworthy Email guidance treats these as complementary mechanisms, not interchangeable badges of security.

SPF checks a sending system against an authorization policy for a particular domain. Crucially, that domain normally comes from the SMTP envelope—the behind-the-scenes return address used during delivery—not necessarily the address a reader sees in the message’s “From” field.

That distinction leaves room for a misleading message to pass SPF. An attacker can send through infrastructure authorized for a domain they control while displaying somebody else’s domain in the visible From address; an SPF pass alone does not connect those identities.

DKIM adds a different kind of evidence: a cryptographic signature associated with a signing domain. It lets a receiver verify that the signed parts of a message have not changed, but a valid signature from an unrelated domain does not, by itself, authenticate the visible sender.

DMARC supplies the missing connection through “alignment.” As NIST explains, DMARC connects authentication results to the visible From domain: a message passes when at least one qualifying SPF or DKIM result both succeeds and aligns with that domain.

DMARC also lets domain owners publish a policy for messages that fail that test and request reporting. Its three familiar policy settings represent materially different positions:

• p=none: request monitoring without asking receivers to quarantine or reject failures.
• p=quarantine: ask receivers to treat failing messages as suspicious.
• p=reject: ask receivers to reject failing messages.

These are published requests, not proof that every receiver handled every message identically. Nor does a DMARC pass certify that a message is harmless: authentication can establish a domain’s involvement without establishing the sender’s good intentions.

This is why DMARC adoption and DMARC enforcement need separate headlines. A domain publishing a monitoring policy has taken a useful deployment step, but it has not requested the same handling of impersonation attempts as a domain publishing p=reject.

The global figures illustrate the difference. DMARCguard’s February 2026 research reports 30.4% DMARC adoption and 12.8% enforcement in its measured population; those percentages describe different stages of deployment, not two names for the same outcome.

Here, enforcement as a share of all sampled domains must not be confused with enforcement as a share of DMARC-enabled domains. If the two figures use the same base population, dividing 12.8 by 30.4 yields roughly 42% of DMARC adopters enforcing—a derived proportion, not another internet-wide measurement.

A separate 2026 DuoCircle report puts global DMARC adoption at 52.1%. That estimate should sit beside the 30.4% result with its source attached, rather than being averaged with it into an apparently more authoritative global number.

Without establishing matching samples, dates, and definitions, the difference cannot be treated as disagreement about one precisely defined population. More importantly, neither adoption estimate independently tells us how many domains request enforcement, how many messages authenticate successfully, or how much spoofed mail receivers stop.

The company-cohort comparison makes the deployment gap more tangible. The same DuoCircle report pairs 95% DMARC adoption for Fortune 500 domains with a 62.7% p=reject figure, versus 76.2% adoption and 15.2% p=reject for Inc. 5000 domains.

Those reported figures show why counting records alone misses an important distinction: strong adoption can coexist with substantially less use of the strictest policy. They do not, on their own, prove that company resources or regulatory pressure caused the difference.

The policy denominator also needs to travel with any reuse of those figures. “Percentage of all cohort domains at p=reject” and “percentage of DMARC-enabled cohort domains at p=reject” are different measures; the supplied figures should not be silently relabeled as one or the other without confirming the underlying definition.

Progress is not necessarily one-way, either. A 2024 tracking series discussed in Dark Reading found that the share of DMARC-enabled domains with an enforced policy declined from an 18% high to under 14%.

That is a finding from one series, not evidence of a universal decline. The practical lesson is narrower and more useful: track publication, aligned authentication, and enforcement separately, then maintain the legitimate sending paths that make stronger policy workable.

Source: DuoCircle, 2026

Forwarding Tests What a DNS Snapshot Cannot

A DNS scan can establish that a domain publishes an SPF record and whether that record meets the scan’s validity criteria. It cannot, by itself, establish that legitimate messages will authenticate after passing through a forwarding service or mailing list: the route a message takes matters as well as the records its sender publishes.

The operational analysis of email forwarding examines that gap between configuration and delivery. Forwarding and redistribution can disrupt authentication even when the participating domains have correctly configured records, because a receiver evaluates the message as it arrives—not necessarily as it originally left the sender.

A different route creates a different check

SPF checks whether the connecting server is authorized to send for the domain used in the message’s SMTP envelope—the delivery information exchanged between mail servers, which can differ from the sender address readers see. As NIST’s email guidance explains, this reliance on the sending server creates difficulties for indirect delivery.

Consider a message that passes SPF when delivered directly to its first destination. If that destination forwards it while retaining the original envelope sender, the next receiver sees the forwarding server’s IP address; that server may not be authorized by the original domain’s SPF record.

That does not mean every forwarded message fails authentication. The outcome depends on what the intermediary changes, which identities the receiver checks, and whether another authentication mechanism still succeeds.

DKIM provides a different kind of evidence: a cryptographic signature covering selected headers and message content. A change in the connecting server does not itself invalidate that signature, so DKIM can survive forwarding that leaves the signed material intact.

Mailing-list redistribution introduces another possibility: changes to signed content, such as a subject line or message body, can invalidate the original DKIM signature. The forwarding research therefore supports a path-specific explanation, not the claim that SPF and DKIM invariably fail together.

DMARC connects these checks to the domain in the visible From address through alignment, meaning the authenticated domain must match that visible domain under DMARC’s rules. A DMARC pass requires at least one successful, aligned authentication result—SPF or DKIM—not both, as described in NIST’s authentication guidance.

That distinction explains why a forwarded message can fail SPF yet still pass DMARC through an intact, aligned DKIM signature. Conversely, a successful authentication check for an intermediary’s own domain does not necessarily establish alignment with the original visible sender.

Maintenance follows the message

These interactions are not simply obscure protocol details that administrators have overlooked. Interview-based research on anti-spoofing adoption found that working email administrators were generally aware of technical weaknesses in SPF, DKIM, and DMARC; awareness, however, does not remove the work of accommodating legitimate mail flows.

The SPF management study documents ongoing administrative friction, including keeping authorization records within SPF’s DNS-lookup limit. Nested provider dependencies make maintenance more than a one-time syntax exercise: the evaluated authorization chain matters, not just the text an administrator initially publishes.

A research-grounded operational review should therefore ask questions that a publication count cannot answer:

• Which legitimate services send for us? Identify the envelope-sender domains, visible From domains, and DKIM signing domains they actually use.
• Which messages travel indirectly? Include forwarding addresses and mailing lists, and distinguish routes that preserve signed content from those that modify it.
• What passes at the destination? Examine SPF, DKIM, and DMARC separately, including alignment, rather than treating one successful check as proof of the entire chain.
• What changes require another check? Revisit affected paths when sending services, SPF dependencies, signing configurations, or redistribution behavior change.

These questions do not prescribe a universal forwarding fix. They establish a more defensible benchmark: a successful static scan describes a configuration; successful authentication describes a message on a particular path, and maintaining the latter requires evidence from actual mail handling.

Authentication Matters, but It Does Not Promise the Inbox

For a business, publishing an SPF record is not the finish line: customers still need to receive and notice the messages it sends. Authentication helps establish whether mail is authorised, but passing authentication does not promise inbox placement, let alone a sale, a response, or a completed password reset.

The DMARCReport discussion of Validity’s 2025 Email Deliverability Benchmark Report reports that global inbox placement declined from 84.8% in 2023 to 83.5% in 2024. That is a fall of 1.3 percentage points within that reported series—not evidence, by itself, that SPF deployment deteriorated or that authentication failures caused the decline.

The distinction matters when translating a headline into business risk. Lower inbox placement means fewer opportunities for recipients to encounter messages in their inboxes, but these aggregate figures do not establish a corresponding revenue loss or identify which organisations suffered most.

A separate benchmark, described in Sender’s email deliverability guide, reports a markedly different distribution: approximately 60% of messages reached a visible inbox location, 36% went to spam, and 4% were blocked outright. Those categories distinguish messages that remain accessible in a spam folder from messages that never reach the recipient’s mailbox.

That split should not be appended to the 83.5% figure as the next point on a global trend line. Different definitions, samples, and measurement approaches prevent the two benchmarks from forming one shared time series; their publication dates do not make their results directly comparable.

“Inbox placement” and “visible inbox location” may sound interchangeable to a busy executive, but they should not be treated that way without checking the underlying methods. The responsible reading is that each benchmark describes outcomes for its own measured population, not that worldwide inbox placement suddenly fell from roughly four-fifths to three-fifths.

Authentication statistics require the same discipline. The 2026 threat report discussed by SC World claims that 46% of emails fail DMARC validation; that is a source-attributed claim about message validation, not an SPF adoption rate.

It is also not a proven malicious-mail rate. A DMARC failure indicates that the message did not satisfy the relevant authentication and domain-alignment checks—the connection between an authenticated domain and the sender domain recipients see—but does not, on its own, establish malicious intent.

These measurements therefore answer three different questions: whether domains publish authentication records, whether messages pass authentication checks, and where messages ultimately land. Substituting one percentage for another turns a technical distinction into a potentially misleading business claim.

Authentication remains an important foundation for trustworthy email, as reflected in NIST’s guidance on trustworthy email. But the supplied evidence does not isolate authentication’s contribution to either the reported inbox-placement decline or the separate inbox, spam, and blocked split.

For managers, the useful response is to keep security and delivery outcomes connected without collapsing them into one score. A practical review can separate:

• Authentication health: Do legitimate messages pass the intended checks?
• Delivery outcomes: Are messages reaching inboxes, going to spam, or being blocked?
• Business outcomes: Are recipients seeing and acting on important communications?
• Comparability: Are changes measured with consistent definitions and a comparable sample?

That separation also makes troubleshooting more defensible. If authentication improves while inbox placement falls, neither result cancels the other; the organisation needs to investigate rather than assume that one metric explains the other.

The business case for authentication is therefore stronger when it avoids guarantees. Maintain it as a foundation for legitimate sending, measure delivery separately, and use external benchmarks as context—not as a forecast of your own inbox performance or proof of what caused a change.

Mailbox Rules and Compliance Raise the Stakes

Email authentication is increasingly a condition of doing business, not just a technical recommendation. But mailbox-provider rules, payment-card standards, and EU legislation create different obligations for different organizations—not one universal requirement to deploy SPF, DKIM, and DMARC in exactly the same way.

The reported sequence begins with Google and Yahoo’s February 2024 bulk-sender requirements. As described in Mailgun’s authentication overview, these changes made authentication a practical delivery requirement for affected senders: SPF identifies authorized sending systems, DKIM provides a cryptographic signature, and DMARC checks how authentication relates to the domain recipients see in the From address.

For administrators, the important distinction is between publishing records and satisfying a receiving provider’s rules. A bulk sender needs to establish which requirements apply to its traffic and confirm that its actual messages comply; the presence of an SPF record alone does not settle either question.

March 2025 brought a separate compliance milestone: the deadline for previously future-dated PCI DSS requirements to take effect. PCI DSS v4.0.1 includes protection against phishing within its applicable scope, but that should not be paraphrased as a blanket instruction that every organization must deploy the same authentication trio.

The email-authentication whitepaper places authentication within this expanding operational and compliance landscape. The defensible approach is to check the specific requirement, the systems in scope, and the evidence an assessor expects—not to turn a broad anti-phishing obligation into a more specific technical mandate than the standard supports.

Microsoft’s May 2025 rejection policy added another mailbox-provider enforcement point for affected high-volume senders. The DMARC adoption overview reports this alongside the earlier Google and Yahoo changes, illustrating how authentication failures can become an immediate delivery problem rather than merely a configuration warning.

DORA and NIS2 belong in the discussion, but as broader compliance context. DORA concerns digital operational resilience in the financial sector, while NIS2 establishes cybersecurity risk-management obligations for covered entities across specified sectors; neither should be presented as an identical, universal SPF/DKIM/DMARC mandate.

Before claiming compliance—or using regulation to explain an adoption percentage—organizations should verify:

• Applicability: whether the entity, service, and systems fall within the framework’s scope.
• The actual obligation: what the relevant provision, national implementation, or provider policy requires.
• Operational evidence: whether authentication works across legitimate sending services, rather than merely appearing in DNS.

Growing pressure also does not mean senders understand their current setup. In Mailgun’s survey, 66.2% report using both SPF and DKIM, while 25.7% remain unsure of their configuration.

Those are self-reported survey results, not a technical audit of all internet domains. They reveal a useful contrast: authentication can be widely reported while substantial uncertainty remains about what is actually configured, who maintains it, and whether changes introduce failures.

Commercial forecasts reflect expectations of demand for help managing that complexity. The email authentication monitoring market report estimates the market at $2.1 billion in 2025 and projects $6.8 billion by 2034.

The latter is a forecast, not an observed outcome or evidence of improved security. It should stand on its own—not be added to overlapping DMARC or email security market estimates—and says more about expected spending than whether authentication is correctly maintained.

Source: MarketIntelo, 2025 baseline and 2034 forecast; Mailgun, 2025

A Better SPF Scorecard Starts With Your Own Domains

A useful SPF benchmark begins with two questions: What did the study count, and what does your organization need to work? An industry percentage can provide context, but it cannot establish whether your payroll service, support platform, or primary mailbox provider sends authenticated mail correctly.

The following checklists are editorial recommendations drawn from the research, not a tested intervention. They separate the evidence needed to quote an adoption figure from the operational evidence needed to trust your own setup.

Checklist 1: Before quoting an industry statistic

• Record the sample. Name the population: a popularity-ranked domain list, resolvable top-million domains, or domains assessed across EU member states. Preserve geographic and selection limits instead of shortening every result to “internet-wide adoption.”
• Record the measurement date. Distinguish when the scan happened from when the report appeared. If the measurement date is unavailable, say so rather than treating publication year as a substitute.
• Record the denominator. Note the starting population, exclusions, and final number evaluated where available. “All sampled domains,” “resolvable domains,” and “SPF-enabled domains” are different bases for a percentage.
• Record the definition. Specify whether the result measures record publication, validity, policy choice, or authentication outcomes. Do not silently promote “has SPF” into “protected against spoofing.”
• Keep comparisons conditional. Compare results directly only when their populations and definitions are sufficiently similar. Otherwise, present them as different observations—not a league table or a trend.

For example, the SPF Supply Chain study reports both valid-record prevalence and policy choices among SPF-enabled domains. Those findings need separate labels because their denominators—and the questions they answer—differ.

Checklist 2: Review your organization’s authentication

Start with an inventory of domains and actual sending paths, including outsourced services. Give each item below its own status, evidence, review date, and owner; a single “SPF enabled” checkbox conceals too much.

• Record presence: Check whether each relevant sending domain publishes SPF. Keep this a discovery result, not a security verdict.
• Validity: Verify that the record is correctly formed and can be evaluated. Record errors separately from missing records so remediation addresses the actual problem.
• Policy: Document the ending policy, such as ~all or -all, and why it was chosen. Softfail and fail express different results, but neither policy string alone proves what a receiver will do.
• Lookup-budget health: Evaluate the complete dependency chain, including nested provider references. Check it against SPF’s limit of 10 DNS-lookup-causing terms rather than merely counting the visible include entries.
• Legitimate sending dependencies: Map every authorized service to its business purpose and owner. Confirm that active senders are covered, investigate obsolete authorizations, and reassess dependencies when providers or sending arrangements change.
• DMARC readiness: Check DKIM signing and whether SPF or DKIM aligns with the domain in the visible From address. Review authentication reports and representative mail paths—including forwarding—before tightening policy.

The distinction between a published configuration and successful authentication is central to NIST’s trustworthy email guidance. Alignment means that an authenticated domain matches the visible sender domain under DMARC’s rules; an SPF pass alone does not establish that relationship.

Treat this review as recurring maintenance rather than a launch task. The research on SPF management and operations supports paying attention to administrative complexity: a record can depend on services and DNS settings outside the organization’s direct control.

Closing figure: Three measurements, three population labels

Reported SPF measurement	Population and timing	What the percentage describes
56.00%	5.5 million domains across the Tranco Top Sites list, March 2026	Domains publishing a valid SPF record, in the SPF Supply Chain scan
62.80%	Resolvable top-million domains, 2026 snapshot	Domains publishing SPF, as reported in th authentication review
88–96%	Domains across EU member states assessed in the JRC study	Reported SPF presence across member states, in the JRC assessment

These are population-specific observations, not competing scores; the EU range is neither a global benchmark nor proof that regulation alone caused adoption. The meaningful target is maintained, functioning authentication for the domains and mail paths your organization actually uses—not matching an attractive global percentage.

The three most-cited 2026 SPF adoption figures, shown together to underscore how far apart they sit depending on sample. Method: Values are the headline SPF adoption percentages as published in each cited source, without adjustment.

Limitations

• The studies use different populations, dates, and definitions; their percentages cannot be combined into an internet-wide average.
• The supplied research describes the 12-million-domain study as broadly comparable, not as establishing a precise 56% result. Original publication and measurement dates need checking.
• Several statistics come through vendor summaries, surveys, or market forecasts rather than directly comparable primary measurements.
• The research does not establish that regulation caused the EU gap or that authentication alone caused changes in deliverability.

References

1. The State of DMARC Adoption in 2026:938,000 Domains Have …
2. DMARC, SPF, and DKIM in 2026: Why Email Authentication Is Now …
3. Email Authentication Monitoring Market Research Report 2034
4. Email Authentication
5. Email communication security standards - JRC Publications
6. SPF Supply Chain 2026: Email Sender Market Share Across …
7. Email Authentication at Scale: A Systematic Review and 2026 …
8. Email Auth Adoption Research - DMARCguard
9. Email Authentication Requirements in 2025 - Mailgun
10. 30 Email Authentication (DKIM/SPF) Statistics Every E-Commerce …
11. Email authentication in 2026: What every organization still …
12. Time to Get Strict With DMARC
13. Email Authentication and Deliverability: How SPF, DKIM, and …
14. Email Deliverability: What It Is and How to Fix It (2026) - Sender
15. A Large-Scale Study on SPF Configuration in the Wild - arXiv
16. A Framework to Audit Email Address Privacy and Analyze … - arXiv
17. SPF Beyond the Standard: Management and Operational …
18. cover_EUIS_Email_2023
19. Trustworthy Email - NIST
20. PDF arXiv:2302.07287v2 cs.CR 19 Apr 2023
21. Towards the Adoption of Anti-spoofing Protocols
22. nist.sp.800-177.pdf