Blog · Dmarc
What DMARC, MTA-STS, DANE, and BIMI Adoption Actually Looks Like Across the Top Million Domains
Every year or two, a new study lands with a headline like "only 30% of domains have DMARC" or "DMARC adoption crosses a critical threshold." Numbers like these get quoted in blog posts, conference talks, and vendor pitch decks. What they almost never explain is which domains, which definitions, and which methodology produced that figure.
A recent ongoing measurement project that has been tracking DMARC, MTA-STS, DANE, and BIMI across the top million domains month by month offers something more useful: consistent methodology, longitudinal data, and the important distinction between a protocol being published and a protocol being enforced.
Here is what the data actually shows.
What the measurements actually cover
The project scans the Alexa (or equivalent) top million domain list each month and checks for the presence of relevant DNS records: DMARC TXT records at _dmarc.domain, MTA-STS policy records at mta-sts.domain, TLSA records for DANE at _25._tcp.domain, and BIMI records at default._bimi.domain.
The critical caveat is that the top million domain list skews toward larger, more technically sophisticated organizations. The numbers you see here describe how the biggest, most-visible domains perform. Small business and government agency adoption rates are almost certainly lower.
DMARC: published versus enforced
DMARC adoption is the most commonly cited number, and also the most frequently misunderstood.
The raw figure - what percentage of domains have a DMARC record at all - typically runs somewhere between 15% and 25% for the top million domains. But that number flatters the reality.
A DMARC record at p=none tells receivers to collect reports but take no action. A record at p=quarantine tells receivers to treat non-aligned mail as suspicious. A record at p=reject tells receivers to discard non-aligned mail entirely.
The measurement project consistently finds that the majority of domains with DMARC records are still at p=none. Domains at p=reject - the only policy that actually prevents spoofing - represent a substantially smaller subset, often under 5% of the total with DMARC published.
The practical implication: if you are building an email security roadmap, the relevant benchmark is not how many domains have DMARC, but how many have moved past p=none. Tracking that progression across your own domains is where DMARCFlow provides ongoing visibility - showing whether your policy is still at p=none, whether third-party senders have been mapped, and whether your alignment rate is improving before you move to enforcement.
This distinction matters when organizations benchmark themselves. Saying "we have DMARC" when your record is set to p=none is like saying you have a fire extinguisher while leaving it locked in a cabinet.
The practical implication: if you are building an email security roadmap, the relevant benchmark is not how many domains have DMARC, but how many have moved past p=none.
MTA-STS: the protocol that should be simpler but lags
MTA-STS is a relative newcomer compared to DMARC. It instructs receiving mail servers to require TLS encryption for incoming SMTP connections and to validate certificates against the domain's published policy.
Where DMARC requires only a TXT record, MTA-STS requires both a policy record and a mechanism for receivers to discover it - either via DNS or via a IETF-standard mechanism. In practice, most deployments use the DNS discovery method (mta-sts.domain subdomain).
Despite being technically simpler to implement than DMARC - no alignment engine, no rua reporting, no third-party sending source discovery - MTA-STS adoption consistently lags. The current measurement places it at roughly 5% to 10% of the top million domains.
Why the lag? A few reasons tend to surface in practitioner discussions:
The interesting asymmetry: organizations that care enough about email security to deploy DMARC often also deploy MTA-STS. The adoption curve skews toward larger, more mature operators. And there is a counterintuitive reality worth naming: MTA-STS is technically simpler to deploy than DMARC, yet has lower adoption. The reason is not complexity - it is operational overhead. Certificate expiry breaks MTA-STS enforcement silently, with no native reporting mechanism to alert you when TLS connections are no longer being enforced.
That reporting gap is where DMARCFlow helps. While MTA-STS itself has no aggregate report equivalent, monitoring SMTP TLS delivery outcomes across your inbound mail streams gives you visibility into whether enforcement is actually working - the kind of signal you would otherwise have to build custom tooling to collect.
DANE: DNSSEC required, and that is the problem
DANE uses TLSA records in DNS to bind a TLS certificate directly to the domain via DNSSEC. When DANE is deployed, a receiving mail server can verify the certificate is legitimate even if a certificate authority has been compromised or misissued a certificate.
It is the strongest form of SMTP-layer certificate verification available. It is also the least deployed.
Current estimates put DANE adoption well under 1% of the top million domains. The reason is almost entirely DNSSEC.
DANE only works when both the sending and receiving domain have DNSSEC properly configured. DNSSEC adoption has crawled forward over the past decade but remains low - estimates suggest under 10% of registrable domains have valid DNSSEC chains. Until DNSSEC is widespread, DANE's effective addressable market is tiny.
For organizations that do have DNSSEC deployed, DANE is worth serious consideration, particularly for high-security communication channels. For everyone else, it remains a future-looking protocol that depends on infrastructure changes outside the email team's control.
BIMI: brand logos with a certificate prerequisite
BIMI lets domains publish a logo that supported mail clients display next to authenticated messages in the inbox. It is the most visible of these protocols - it shows up as a small brand mark, not a technical configuration.
BIMI adoption remains very low, consistently measured under 1% of domains even among the top million.
The reason is not indifference. BIMI requires a Verified Mark Certificate (VMC), which is a validated identity certificate issued by an authorized certificate authority. VMCs cost money - typically hundreds to thousands of dollars per domain per year - and the validation process takes time.
The practical reality: only brands with enough marketing budget and enough legal clarity around their trademark to obtain a VMC can deploy BIMI. For most organizations, it remains aspirational.
Gmail's adoption of BIMI in 2023 was a meaningful push forward for the protocol, and Apple Mail's support has added another segment of clients that render marks. But without a path to VMC-free BIMI (currently being discussed in IETF working groups), broad adoption will remain limited to well-funded brand teams.
What these numbers mean for your roadmap
The top-million-domain numbers are benchmarks, not targets. The organizations that own the domains in that list are systematically more likely to have email security expertise, dedicated infrastructure teams, and budget for certificate management.
If you run a mid-size organization's email security, you are probably performing below these benchmarks on MTA-STS and above them on DMARC enforcement, depending on how mature your policy is.
The more useful framing is to ask three questions about your own domains:
The data across these protocols tells a consistent story: most domains are years behind where the email security community would like them to be. The number that matters is not "domains with DMARC" but "domains with DMARC at p-reject." By that measure, the industry has a long road ahead.
Measure your own domains
If you want to see where your own domains stand on these protocols - and track how your enforcement posture changes over time - DMARCFlow provides ongoing monitoring for DMARC, MTA-STS, and BIMI publication status, with alerts when configurations change or expire.
For organizations moving toward enforcement, that kind of continuous visibility is more useful than a once-a-year benchmark report.
FAQ
What percentage of domains have DMARC at p-reject? The measurement data from the top million domains consistently shows that p-reject domains represent a small fraction of total DMARC-published domains - typically under 5% of all domains with a DMARC record. Most domains with DMARC are still at p=none.
What percentage of domains have MTA-STS? Roughly 5% to 10% of the top million domains have an MTA-STS policy published, according to the same measurement project tracking DMARC. That makes MTA-STS adoption meaningfully lower than DMARC publication, despite being operationally simpler for most email operators.
Is MTA-STS necessary if I already have DMARC? Yes, with caveats. DMARC and MTA-STS operate at different layers. DMARC verifies that the sender is authorized to use the From domain; MTA-STS verifies that the connection itself is encrypted and authenticated. Both reduce different attack surfaces. They are complementary, not redundant.
Can I deploy DANE without DNSSEC? No. DANE requires valid DNSSEC on both the sender and receiver domain. If your registrar does not support DNSSEC delegation, DANE cannot work for your domain.
How much does a VMC for BIMI cost? Verified Mark Certificates typically cost between $200 and $1,000 per domain per year, depending on the CA and validation level required. Some CAs charge more for domains with multiple trademarks or complex legal structures.
What is the single most impactful email security improvement I can make? Moving DMARC from p=none to p-reject is the highest-plumb for change most organizations can make. It is the only configuration that actively blocks spoofed mail from reaching inboxes. MTA-STS is the next most impactful for securing the transport layer.