MTA-STS, DANE, BIMI Adoption: What Data Shows

After you have enforced DMARC at p=reject, the natural next question is: what else matters? Three protocols come up in the same conversation. They have very different prerequisites, very different adoption curves, and very different operational complexity. The measurement data on the top million domains shows this clearly: MTA-STS adoption sits in the single-digit to low-double-digit percent range, DANE for SMTP is much smaller because it requires DNSSEC, and BIMI is lower still and uneven across mailbox providers.

This article explains what each protocol actually requires, what the public measurement programs report, why each protocol is stuck where it is, and the order to deploy each one based on what gives you the best return.

What the three protocols do in plain English

| Protocol | What it solves | Hard prerequisite |
|----------|----------------|-------------------|
| MTA-STS (RFC 8461, 2018) | Stops opportunistic TLS downgrade on inbound mail | HTTPS endpoint with a trusted certificate |
| TLS-RPT (RFC 8460, 2018) | Reports TLS negotiation failures on inbound mail | None beyond DNS |
| DANE for SMTP (RFC 7672) | Verifies the recipient MX server certificate via DNSSEC | The domain's parent zone must be DNSSEC-signed and the resolver must validate |
| BIMI (working draft) | Brand logo in the inbox next to authenticated mail | DMARC at p=quarantine or p=reject, plus an SVG Tiny PS logo |

The key insight: DANE is the only one of the three that depends on DNSSEC. MTA-STS does not need DNSSEC. BIMI does not need DNSSEC, but it does need DMARC enforcement plus, in the Gmail case, a Verified Mark Certificate.

MTA-STS in depth

MTA-STS lets a recipient domain publish a DNS TXT record at _mta-sts and an HTTPS-served policy file at https://mta-sts.example.com/.well-known/mta-sts.txt. The policy file says either mode: enforce or mode: testing, lists which MX hosts are valid, and how long the policy is valid for. When a sending MTA looks up the recipient domain and finds both the DNS record and the policy file, it refuses to deliver mail over an unauthenticated TLS connection. That is the whole mechanism.

The thing that silently breaks MTA-STS in production is the HTTPS-served policy file. The DNS record is easy. The policy file has to be served from a real HTTPS endpoint with a trusted certificate, and small teams forget the policy file when they change hosting providers or move domains. The DNS record is still there, but the sending MTA cannot fetch the policy, and behavior reverts to opportunistic TLS. A working MTA-STS deployment is one where the policy file is reachable and matches the DNS record. The failure mode is silent: nothing rejects the mail, the TLS handshake just falls back to opportunistic encryption, and the operator does not find out until someone investigates a deliverability issue.

DANE for SMTP in depth

DANE binds MX server certificates to the domain using TLSA records in DNS. The sender looks up the MX record, then the TLSA record, and validates the server certificate against the TLSA hash. The whole security model rests on DNSSEC, which means the parent zone of the recipient domain must be DNSSEC-signed, and the recursive resolver chain used by the sender must actually validate DNSSEC.

This is the reason DANE for SMTP adoption stays tiny. DNSSEC is operationally heavier than most teams want to take on for a marginal security benefit on top of MTA-STS. Modern MTAs use TLS 1.2 or 1.3 by default, and modern CA hierarchies are reasonably trustworthy. DANE adds protection against rogue CAs, but most operators judge that protection to be incremental rather than decisive.

DNSSEC adoption at the recursive resolver level is climbing but uneven. Internet Society Pulse and APNIC measurement blog posts put DNSSEC validation rates in the high single digits to low double digits for many country-level resolvers, with much higher rates in a few countries (notably the Czech Republic, Sweden, and the Netherlands). Until DNSSEC validation is the default rather than the exception, DANE for SMTP will stay niche.

BIMI in depth

BIMI is a different kind of protocol. It does not protect mail transit. It does not protect mail authentication. It lets a brand publish a logo that participating mailbox providers will display next to authenticated mail.

The hard prerequisite is DMARC at p=quarantine or p=reject. Without DMARC enforcement, BIMI does not display. The next requirement is an SVG Tiny PS logo. The optional but practically important third requirement is a Verified Mark Certificate from one of the two certificate authorities that issue them. Google Mail requires a VMC. Apple Mail accepts self-asserted BIMI without a VMC. Yahoo accepts both.

This explains why BIMI adoption is uneven. A brand that has a registered trademark and a budget for a VMC can ship BIMI for Gmail. A brand without a registered trademark gets Apple Mail and Yahoo but not Gmail. A brand without DMARC enforcement gets nothing. Adoption is small in absolute terms but concentrated in the brands that have already done the brand-side work.

The adoption data

| Protocol | Typical top 1M adoption | Why |
|----------|--------------------------|-----|
| DMARC | 60-70 percent | Years of Gmail, Yahoo, and Microsoft bulk-sender pressure |
| MTA-STS | Single-digit to low-double-digit percent | Easy to publish, easy to silently break |
| DANE for SMTP | Low single-digit percent | Requires DNSSEC at parent zone and resolver |
| BIMI | Well under 10 percent | Requires DMARC enforcement plus brand assets plus optional VMC |

The numbers above are approximate and depend on the dataset and measurement window. Cloudflare Radar's email security section publishes percent for DMARC, SPF, DKIM, and MTA-STS in the top domains. Internet Society Pulse tracks DNSSEC adoption and routing security. APNIC's measurement blog publishes regular deep dives. None of these is the single source of truth, and the exact percentages move quarter to quarter. The order of magnitude is stable: MTA-STS is much smaller than DMARC, DANE is much smaller than MTA-STS, BIMI is much smaller than DANE.

Why each protocol is stuck at its current level

DANE stays tiny because DNSSEC is operationally heavy and gives diminishing returns over MTA-STS once modern MTAs use TLS 1.2 or 1.3 by default. Most teams that care about TLS for SMTP have already gotten what they need from MTA-STS.
MTA-STS plateaus because the policy file silently breaks when teams change hosting. The DNS record is one TXT record. The HTTPS endpoint is another moving part.
BIMI is uneven because Gmail requires a VMC, which requires a registered trademark and a vetting process. It is a brand project, not an IT project. The brands that have done the brand work have shipped BIMI. The brands that have not, will not.

Decision framework: what to deploy, in what order

If you have already enforced DMARC at p=reject, the order that gives the most ROI per hour of work is roughly:

1. Publish MTA-STS. Single TXT record, single policy file. Highest security value for the smallest operational cost.
2. Enable TLS-RPT at the same time. One more TXT record. Without it, you do not get visibility into TLS negotiation failures on inbound mail.
3. Consider DANE only if your domain is on a registrar that makes DNSSEC easy, your parent zone is signed, and your resolvers validate. If any of those is not true, defer DANE.
4. Consider BIMI only if you already have DMARC enforcement, an SVG Tiny PS logo, and either a registered trademark (for the Gmail VMC path) or an Apple Mail audience that accepts self-asserted BIMI.

This is the order that maximizes benefit per unit of operational cost. The opposite order (DNSSEC and DANE first, MTA-STS second) is the order a security maximalist would choose, but it is not the order most teams have the operational bandwidth for.

A free MTA-STS Checker that validates both the DNS record and the HTTPS policy file in one go is the easiest way to confirm step 1 actually worked. Most silent breakage shows up there: the DNS resolves, but the policy file is unreachable, or the file lists a stale MX host, or the certificate on the policy endpoint has expired. Confirming this before declaring MTA-STS deployed saves a support ticket later. DMARCFlow publishes a free MTA-STS and TLS-RPT Checker that does exactly this, but any tool that fetches the policy file and parses it correctly will catch the same issues.

Practical checks before you trust any of it

For MTA-STS:

Confirm _mta-sts.<your-domain> TXT record resolves.

Confirm https://mta-sts.<your-domain>/.well-known/mta-sts.txt returns the policy file over a trusted HTTPS connection.

Confirm the policy file lists your real MX hosts.

For TLS-RPT:

Confirm _smtp._tls.<your-domain> TXT record resolves with a valid rua= URI.

For DANE:

Confirm your parent zone is DNSSEC-signed at the registrar.

Confirm _25._tcp.<mx-host> TLSA records exist if you have published them.

For BIMI:

Confirm default._bimi.<your-domain> TXT record resolves with the SVG URL.

Confirm the SVG is reachable over HTTPS and is valid SVG Tiny PS.

The fastest way to confirm MTA-STS and TLS-RPT are deployed end-to-end is to use a checker that validates both the DNS record and the HTTPS policy file. DMARCFlow publishes free MTA-STS and TLS-RPT checkers that do exactly that: they look up the TXT record, fetch the policy file, and confirm the certificate chain is valid. That is the operational step most people skip, and it is the one most likely to catch a silent breakage.

FAQ

Does MTA-STS require DNSSEC?
No. MTA-STS uses HTTPS for policy distribution, not DNSSEC. The two protocols are independent.

Is DANE for SMTP a replacement for MTA-STS?
No. DANE and MTA-STS solve overlapping but distinct problems. MTA-STS requires TLS for a given MX host. DANE pins the certificate for that MX host. You can deploy either, both, or neither.

Do I need a VMC for BIMI?
You need a VMC for Gmail. Apple Mail and Yahoo accept self-asserted BIMI without a VMC.

What is the realistic adoption order for a small B2B domain?
Enforce DMARC. Then publish MTA-STS and TLS-RPT at the same time. Then consider DANE if DNSSEC is easy for you. Then consider BIMI if you have a brand project to justify the VMC.

Where do Cloudflare Radar and Internet Society Pulse disagree?
They use different datasets and different measurement windows. Cloudflare Radar measures the top domains passing through Cloudflare's resolver and edge. Internet Society Pulse aggregates multiple vantage points. Both are useful. Treat any specific percentage as a point-in-time estimate, not a definitive number.

What does TLS-RPT actually report?
Aggregate reports sent daily to the URI you publish in the _smtp._tls TXT record. Each report lists the sending source, the receiving MX host, the TLS version negotiated, and whether the connection succeeded. If you see a lot of "starttls-not-supported" outcomes, a sender is falling back to plaintext because it does not offer STARTTLS or your MTA rejected their certificate. That is exactly the failure mode MTA-STS exists to prevent, and TLS-RPT is the only way to see it at scale.

DMARC enforcement: how to move from p=none to p=reject
MTA-STS policy file: how to publish one correctly
TLS-RPT: the reporting layer for MTA-STS
DNSSEC: what it gives you and what it costs you
Verified Mark Certificate: the brand-side work behind BIMI in Gmail

What the Measurement Data Shows About MTA-STS, DANE, and BIMI Adoption