The state of email authentication, June 2026
Our monthly measurement of DMARC, MTA-STS, DANE, and BIMI across the top 1M domains. June 2026 baseline: DMARC at 64% of mail-eligible domains, BIMI 2.4%, DANE 4.3%, MTA-STS 1.1%.
This is the first in a monthly series. Every month we measure deployment of the four standards-track email-security protocols across Cloudflare Radar’s top 1 million domains: DMARC, BIMI, DANE-for-SMTP, and MTA-STS. This is the June reading.
The headline: DMARC sits at 64% of mail-eligible domains, MTA-STS at 1.1%, DANE at 4.3%, and BIMI at 2.4%.
The shape of the ecosystem is clearly two-sided. The hyperscalers (Microsoft and Google) carry DMARC, BIMI, and MTA-STS. Cloudflare and the European hosting community carry DANE. The two halves barely overlap.
The rest of this post is the data behind those numbers and what it means for operators today. Starting next month we’ll begin publishing month-over-month deltas. For this first edition we wanted to share the baseline.
Where things stand
Of the 706,530 mail-eligible domains in the June top 1M:
| protocol | adopters | % of mail-eligible |
|---|---|---|
| DMARC valid record | 451,176 | 63.9% |
DMARC at p=reject (strictest) |
95,994 | 13.6% |
| DANE (≥1 MX has TLSA) | 30,261 | 4.3% |
| BIMI valid record | 16,943 | 2.4% |
| BIMI with Verified Mark Certificate | 6,103 | 0.9% |
| MTA-STS valid policy | 8,062 | 1.1% |
DMARC is in a different league from the others. Two-thirds of mail-eligible domains publish a record, though only about a fifth of those are at the strictest enforcement (p=reject). The other three protocols are still in the deployment minority.
DMARC
DMARC remains the easiest of the four to deploy and the most widely supported.
| metric | count |
|---|---|
Has _dmarc TXT (any kind) |
456,850 |
| Valid DMARC record | 451,176 |
→ p=none (monitoring only) |
243,465 (54.0% of valid) |
→ p=quarantine |
111,717 (24.8%) |
→ p=reject (strictest) |
95,994 (21.3%) |
A p=none record produces useful reporting telemetry for the domain owner. It does not protect downstream recipients. A forged sender will still arrive in the recipient’s inbox. The 46% of DMARC publishers who’ve moved past p=none are the population that’s actually protecting their recipients.
Top MX providers among p=reject adopters:
| provider | adopters |
|---|---|
Microsoft 365 (protection.outlook.com) |
23,466 |
| Google Workspace | 21,126 |
| Proofpoint | 7,050 |
| Mimecast | 4,388 |
| Cloudflare | 1,026 |
| Cisco ESA | 968 |
Microsoft 365 and Google Workspace together carry 46% of p=reject adopters. The pattern is consistent across the strict-mode protocols: operators on those two stacks get pushed toward stricter policies by the platforms.
BIMI
These are domains that publish a BIMI record (the sender side). BIMI is a brand signal that often lives on a company’s sending domain rather than its mailbox domain, so treat this as a publishing count. More on that at the end.
| metric | count |
|---|---|
Has default._bimi TXT (any) |
16,957 |
| Valid BIMI record | 16,943 |
| With logo URL | 16,776 (99.0% of valid) |
| With Verified Mark Certificate | 6,103 (36.0%) |
BIMI “decline” (empty l=) |
130 (0.8%) |
A Verified Mark Certificate (VMC) is the premium tier. A domain owner pays a certificate authority to attest that the logo URL belongs to the trademark holder. Without a VMC, Gmail and Yahoo won’t render the logo. About a third of BIMI publishers carry a VMC. The other two-thirds publish the record and get nothing in the inbox.
130 domains publish an explicit “decline” record: v=BIMI1; l= (empty l= tag). This is the operator telling BIMI-aware inboxes not to render any image for the domain. Some privacy ESPs (Proton among them) make this choice on behalf of their customers.
Top MX providers among BIMI adopters:
| provider | adopters |
|---|---|
| Google Workspace | 6,612 |
| Microsoft 365 | 3,953 |
| Proofpoint | 685 |
| Mimecast | 515 |
| Cisco ESA | 164 |
| Zoho | 159 |
Google Workspace is the largest BIMI presence. That makes sense: BIMI’s payoff is the logo rendered in Gmail, and Gmail is where most users see those logos in the first place. Operators on Google’s stack have direct visibility into whether BIMI is working for them.
DANE-for-SMTP
DANE is the protocol the EU community deploys and almost nobody else does.
| metric | count |
|---|---|
| Mail-eligible domains | 706,530 |
| Total MX hosts observed | 1,649,277 |
| MX hosts with a TLSA record | 72,936 (4.4% of all MX hosts) |
| Domains with ≥1 DANE-protected MX | 30,261 (4.3% of mail-eligible) |
| Domains with all MX DANE-protected | 29,282 (97% of DANE adopters) |
The 4.3% is measured against every mail-eligible domain, the same denominator as the headline. (97 of the 706,530 point their MX at the root, ., but with a non-zero preference like 10 .. That’s a malformed variant, not the RFC 7505 null-MX form 0 . we exclude in step 1, so it still counts as mail-eligible. There’s no host to query for DANE, so these are non-adopters, not gaps in the measurement.)
Those 72,936 hosts publish 180,350 TLSA records between them, about 2.5 per host. A host usually publishes more than one, to allow key rollover, so the counts below are per record, not per host:
| usage | meaning | records | share |
|---|---|---|---|
| 3 | DANE-EE (server cert, SPKI/SHA-256) | 129,111 | 71.6% |
| 2 | DANE-TA (trust-anchor cert) | 51,231 | 28.4% |
| 0/1 | PKIX-* | 8 | <0.01% |
DANE-EE (3 1 1) is the modern recommended profile and dominates. PKIX modes (chain into Web PKI) are essentially unused, which matches what operational guidance has said for years.
Top MX providers among DANE adopters:
| provider | adopters |
|---|---|
| Cloudflare Email Routing | 14,012 |
| Proton Mail | 2,193 |
| infomaniak | 912 |
Microsoft 365 (newer mx.microsoft) |
761 |
| one.com | 722 |
| Migadu | 656 |
Cloudflare Email Routing alone accounts for 14,012 of the 30,261 DANE adopters, almost half. Cloudflare publishes DANE by default for every customer zone that uses their email routing. The rest of the list is the European privacy-and-hosting cluster: Proton, infomaniak, mailbox.org, posteo, migadu, one.com.
Microsoft 365 appears only via the newer mx.microsoft MX scheme (761 domains). The legacy *.protection.outlook.com infrastructure that most M365 tenants are still on does not carry DANE. Google Workspace doesn’t appear at all.
MTA-STS
| metric | count |
|---|---|
Has _mta-sts TXT (any) |
35,924 |
Valid TXT (v=STSv1 + id=) |
9,753 |
| Policy reachable (HTTPS 200 + valid TLS) | 8,100 |
| Valid policy file | 8,062 |
→ enforce |
4,504 (55.9% of valid) |
→ testing |
3,432 (42.6%) |
→ none |
126 (1.6%) |
56% of MTA-STS adopters are in enforce mode. The remaining 43% are in testing mode, which logs TLS failures but still accepts the mail. Anyone who gets past the “is my mta-sts.<domain> host really fronted by a valid TLS cert?” deployment hurdle tends to move from testing to enforce within a few months once they’re confident the logs are clean.
Top MX providers among MTA-STS adopters:
| provider | adopters |
|---|---|
| Microsoft 365 | 2,499 |
| Google Workspace | 2,028 |
| Mimecast | 388 |
| Proofpoint | 159 |
| Tuta | 130 |
Microsoft 365 (newer mx.microsoft) |
124 |
Same concentration as DMARC p=reject. Microsoft 365 and Google Workspace and the gateway oligopoly. MTA-STS adoption is almost entirely a function of which inbox vendor a domain uses.
Two ecosystems, four protocols
The most striking finding from this dataset is that no single ESP carries all four protocols at scale.
| ecosystem | DMARC p=reject |
MTA-STS | BIMI | DANE |
|---|---|---|---|---|
| Microsoft 365 + Google Workspace | 45,050 | 4,651 | 10,565 | 761 |
| Cloudflare Email Routing | 1,026 | 30 | 115 | 14,012 |
| European registrars + privacy ESPs | ~3,500 | ~280 | ~50 | ~5,200 |
The hyperscaler stack ships DMARC, BIMI, MTA-STS. It does not ship DANE.
The Cloudflare-and-European-ESP stack ships DANE. It barely ships anything else.
This isn’t an accident. The two halves are anchored in different trust roots. MTA-STS and BIMI validate through the Web PKI. DMARC validates through DNS alignment. DANE validates through DNSSEC. An operator’s stack is mostly determined by which of those trust roots they’re already invested in.
Closing the gap requires one of two things: hyperscalers adopt each other’s tooling (Microsoft already started this on the mx.microsoft MX scheme), or operators demand both halves from their vendors. Neither is going to happen overnight.
What this means if you run mail
The protocol mix that actually protects your domain today is DMARC at p=quarantine or p=reject, plus MTA-STS in enforce mode. Both close meaningful attack surface, and they’re independent: you can deploy one without the other.
Add BIMI if you want the inbox visibility, and budget for the VMC. A BIMI record without a VMC is a record that nobody renders.
DANE is great if you’re on a stack that publishes it for you (Cloudflare Email Routing, Proton, infomaniak, mailbox.org). It’s skippable if you’re on Microsoft 365 or Google Workspace, because neither vendor ships DANE on its standard MX scheme.
How we measured this
For each domain in Cloudflare Radar’s top 1M:
- Query MX. Domains with no MX or null-MX (per RFC 7505) are excluded.
- For mail-eligible domains, query TXT at
_dmarc.<domain>,default._bimi.<domain>, and_mta-sts.<domain>. Parse each per its respective RFC. - For each MX host, query TLSA at
_25._tcp.<mx_host>(for DANE). - For domains with a valid MTA-STS TXT, fetch
https://mta-sts.<domain>/.well-known/mta-sts.txtand validate per RFC 8461 §3.2.
The queries run from a fleet of 30 small cloud VMs, one in each of 30 regions worldwide, covering every populated continent. Each VM runs a local recursive resolver and also reaches Cloudflare, Google, and its own provider’s resolver. Every resolver in the pool is unfiltered. We deliberately leave out content-filtering resolvers like Quad9, which return “no such domain” for blocklisted hosts and would quietly distort a census like this.
Every DNS lookup runs under a two-of-N quorum rule: a second confirming query, from a different region and a different DNS provider, must return the same answer before we record it. A single resolver returning an odd answer is outvoted, never counted. “No record” answers require the same confirmation, since a single-query negative can just be transient throttling. The whole run is paced over about two hours so we never lean hard enough on any public resolver to get rate-limited.
One honesty note on coverage: a query that times out can’t produce a wrong answer, only fail to confirm one, so it’s retried elsewhere. A domain only drops out if a lookup fails on every resolver, which means the domain’s own DNS was unreachable. In this run that happened to 1,286 domains (0.18%), all on the MTA-STS HTTPS fetch. The four DNS-based protocols had zero unresolvable domains. Those are excluded from the relevant denominator rather than counted as non-adopters: you don’t know a domain you couldn’t reach lacks a record.
We cross-checked the whole thing against a completely separate run (different cloud, different resolvers, a different day), and the two agreed to within 0.7% on every protocol (under 0.2% on four of five). When two setups that share almost nothing land on the same numbers, the numbers are real.
What we’re not claiming
A few honest limitations.
The top-1M is one population among several. Cloudflare Radar’s list differs from Tranco or Cisco Umbrella. Adoption rates against a different population would be different.
We don’t enforce DNSSEC validation when counting DANE. A measured DANE adopter that fails DNSSEC validation wouldn’t actually protect mail in practice. We count what’s published, not what’s enforced end-to-end.
BIMI isn’t quite the same kind of signal as the other three, and we measure it more narrowly than the headline suggests. You reach DMARC, MTA-STS, and DANE by following the DNS of the domain we measure. DMARC is a From-domain alignment and policy layer over SPF and DKIM. MTA-STS and DANE secure the inbound SMTP connection, and DANE’s TLSA records sit on the MX hosts the domain publishes. They do different jobs, but all three trace back to the domain itself. BIMI is the outlier: a sender and brand signal a company publishes on whatever domain it sends branded mail from, which often isn’t its mailbox or MX domain, and isn’t linked from it in DNS. Comcast is the clean example: comcast.net carries DMARC, MTA-STS, and DANE, but the BIMI logo lives on xfinity.com, the domain Comcast sends customer mail from. We measure BIMI per domain, so we catch any surveyed domain that publishes it (xfinity.com is in our count), but a per-domain measurement undercounts organizations whose brand-sending domain is separate or sits outside the top 1M.
We also measure publishing, not display. The BIMI figure is how many domains publish a record, the sender side. It says nothing about which inboxes render the logos, the receiver side, which is a small separate set of mailbox providers (Gmail, Apple, Yahoo, Comcast) and isn’t visible in DNS. None of this touches the central finding: the MTA-STS versus DANE split is between two inbound transport-security protocols, measured the same way, on the same domains.
Quorum diversity is geographic and resolver-vendor based. It doesn’t guarantee the receiving authoritative server uniformly answers the rest of the world. A server with broken GSLB could cause us to disagree with itself on the same domain. We don’t think this is common but we can’t rule it out.
What’s next
We’ll publish the July reading in early July, same methodology, same population basis. Month-over-month deltas are the interesting metric: a single month’s snapshot tells you where the ecosystem is. The rate of change tells you where it’s going.