Email marketers get pitched a steady stream of "next-generation" standards: BIMI will put your logo in the inbox, MTA-STS will secure your transport, TLS-RPT will tell you when encryption fails, DANE will do what MTA-STS does but with DNSSEC. Each pitch implies everyone else is already on board. Are they?
This is a question public DNS can answer, because every one of these standards is deployed as a DNS record. Our daily OpenINTEL-based scan of the Tranco top-1M tracks them alongside the basics — and the basics set the scale: as of the 2026-07-05 snapshot, 664,715 domains publish MX, 623,370 publish SPF, and 459,124 publish DMARC. Every next-generation standard is a small fraction of those figures. The current per-standard counts live in sections 7 and 10 of the daily email infrastructure report, updated daily; here we focus on what each standard actually buys you and the order in which to deploy them.
The four standards in one table
| Standard | What it does | Hard prerequisite | Who benefits most |
|---|---|---|---|
| BIMI | Displays your verified logo next to messages in supporting inboxes | Enforced DMARC; VMC certificate for major providers | Consumer brands with recognizable logos |
| MTA-STS | Tells sending servers to require TLS when delivering to you | HTTPS-hosted policy file + DNS record | Any domain that receives sensitive mail |
| TLS-RPT | Daily reports on TLS negotiation failures to your domain | One TXT record and a reporting address | Everyone — it is pure telemetry |
| DANE | Pins TLS certificates for SMTP via DNSSEC-signed TLSA records | DNSSEC on your zone | Infrastructure operators, mail hosts |
BIMI: the marketing favorite with the strictest gate
BIMI is the only standard in the list that marketing teams ask for by name, because its payoff is visible: a brand logo beside the From line. The catch is that BIMI is deliberately built as a reward for finished authentication work. Supporting mailbox providers only display the logo when the domain's DMARC policy is at enforcement — and the major ones additionally require a Verified Mark Certificate, which means a trademarked logo and a paid vetting process.
That gate explains more about BIMI adoption than any awareness campaign. In our dataset, 51% of DMARC-publishing domains still sit at p=none, and only 47.16% enforce. Most senders are not eligible for BIMI even if they published the record tomorrow. If you want the logo, the project plan is really a DMARC-enforcement project — see the state of DMARC 2026 for where the population stands — with a BIMI record as the final ten minutes of work.
MTA-STS and TLS-RPT: transport security, observable in DNS
MTA-STS
SMTP's original sin is that transport encryption is opportunistic: a sending server tries TLS, and silently falls back to plaintext if the negotiation fails — which is exactly what an active attacker wants. MTA-STS (RFC 8461) fixes this by letting a receiving domain publish a policy — a DNS record pointing to an HTTPS-hosted file — that tells senders to require TLS and verified certificates, or not deliver at all. It protects mail coming to you, which makes it a receiving-side standard: your ESP choice does not deploy it for you.
TLS-RPT
TLS-RPT (RFC 8460) is MTA-STS's reporting companion: a single TXT record that asks large senders to email you daily summaries of TLS failures when delivering to your domain. It changes nothing about mail flow, costs nothing beyond a mailbox or reporting service, and gives you the telemetry to deploy MTA-STS enforcement safely — the same monitor-then-enforce pattern DMARC uses with rua= reports.
DANE
DANE solves the same problem as MTA-STS by pinning certificates in DNSSEC-signed TLSA records — cryptographically stronger, but it requires DNSSEC on your zone, which keeps it concentrated among mail hosts and infrastructure operators rather than individual brands. For most marketing teams, MTA-STS is the practical path and DANE is something your mailbox provider does for you.
Across the top-1M, all four standards remain minority deployments concentrated in the most mature senders — large consumer brands, major mailbox providers and security-forward enterprises — while the long tail has not started. TLS-RPT tends to accompany MTA-STS wherever the latter appears, consistent with the monitor-then-enforce playbook. We publish the daily counts rather than quoting them here, because they move: see sections 7 and 10 of the live report.
The deployment order that works
The standards are independent on paper but sequential in practice, because each one either gates or de-risks the next:
- Finish DMARC first. Get SPF and DKIM aligned, then move from
p=noneto enforcement with stagedpct=values — and mind the subdomain policy, the sp= gap, while you are in there. Nothing else on this list matters until this is done. - Publish TLS-RPT. One TXT record, zero risk, immediate visibility into transport failures. There is no reason any domain with a DMARC program should skip it.
- Deploy MTA-STS in testing mode, then enforce. Use the TLS-RPT data to confirm your mail hosts present valid certificates before flipping the policy to enforce.
- Add BIMI last. Once DMARC is enforced, the record itself is trivial; budget the real time for the trademark and VMC process if you want display at the major providers.
Treat the acronyms as a maturity ladder rather than a shopping list, and each rung pays for the next: DMARC data justifies enforcement, TLS-RPT data justifies MTA-STS, and the finished stack makes the logo — the part your CMO actually asked about — a formality.