Email Auth Trends: DANE Falls, MTA-STS Growing

Someone measures DMARC, MTA-STS, DANE, and BIMI across the top 1 million domains every month. Month two's result: DANE adoption fell. That is a signal worth understanding, because it tells you which protocols are practical to operate at scale and which ones are quietly being abandoned.

This post breaks down what the trends mean, why DANE keeps slipping despite being technically superior, and what you should actually prioritize for your domain.

The four protocols and what they protect against

DMARC ties SPF and DKIM together with a policy telling receivers what to do with unauthenticated email. It also generates aggregate reports so you can see who is sending mail from your domain. Most large domains and virtually all major brands have a DMARC record.

MTA-STS (Mail Transfer Agent Strict Transport Security) forces incoming mail servers to use TLS encryption and validates their certificates. It prevents downgrade attacks where an attacker intercepts a mail connection and strips STARTTLS to read or modify email in transit.

DANE (DNS-based Authentication of Named Entities) goes further than MTA-STS by binding a TLS certificate directly to the domain's DNS records via a TLSA record. If the certificate presented during an SMTP handshake does not match what DNS says it should be, the connection is rejected. This is more secure than MTA-STS but operationally heavier.

BIMI (Brand Indicators for Message Identification) displays your logo in supporting email clients. It requires a VMC (Verified Mark Certificate) or CMC (Certified Mail Certificate) from a certificate authority, which has become its main adoption bottleneck.

What month two's measurements show

MTA-STS is growing. Google and Yahoo's bulk sender requirements pushed many senders to publish MTA-STS policies. Microsoft Exchange Online supports it natively. Hosting providers increasingly enable it by default. The operational overhead is low: publish a policy TXT record, set a max_age, done.

DANE is declining. The reason is operational, not security-related. DANE requires your TLSA record in DNS to be updated every time you rotate your TLS certificate. If the DNS update is late, mail defers or bounces. For organizations with automated certificate rotation, this is manageable but non-trivial. For teams where certificate rotation is manual or handled by a vendor, DANE becomes a reliability risk. Most practitioners find MTA-STS delivers sufficient protection without the coordination overhead.

BIMI remains rare. The VMC requirement is the bottleneck. Certificate authorities charge hundreds to over a thousand dollars annually for a VMC, and the trademark validation process takes time. Without a certified logo, BIMI cannot be displayed even if your BIMI DNS record is perfectly configured. Currently only large consumer brands with established trademarks and budget to spend on a certificate are adopting BIMI.

DMARC remains the most widely deployed of the four, and p=reject adoption is growing as organizations mature their email security programs.

Why DANE keeps slipping despite being technically superior

DANE is the stronger protocol from a security standpoint. MTA-STS accepts any valid certificate from a trusted CA. DANE accepts only the specific certificate or CA you have pinned in DNS. If an attacker compromises a trusted CA and gets a fraudulent certificate for your domain, MTA-STS would accept it; DANE would not.

But security and practicality do not always align at scale.

Certificate rotation is a fact of life. Modern TLS certificates from Let's Encrypt rotate every 60 to 90 days automatically. For MTA-STS, this is irrelevant. For DANE, every rotation requires a matching update to your TLSA record, which must propagate before the new certificate goes live or your mail queue starts building.

The failure mode for DANE is silent. Mail just stops delivering with a cryptic TLS negotiation error. There is no dashboard alert unless you have monitoring in place. Many organizations discover the problem only when someone reports that emails are not arriving.

Month two's DANE decline almost certainly reflects this. Teams that deployed DANE hit a rotation issue, switched back to MTA-STS, and removed the TLSA record. Providers that planned to support DANE delayed or abandoned the rollout when they calculated the operational cost.

DANE is not wrong. It is the right choice for organizations with dedicated certificate management and threat models that justify the overhead. For most practitioners, MTA-STS is the pragmatic default.

Why MTA-STS keeps growing

MTA-STS occupies a sweet spot: meaningful security improvement, minimal operational overhead.

It prevents STARTTLS stripping attacks, which are a real threat. An attacker in a network position to intercept traffic can downgrade an SMTP connection to plaintext, allowing them to read or modify email in transit. MTA-STS makes that downgrade impossible by requiring TLS and validating the certificate.

The main thing MTA-STS does not do is verify the specific certificate. Any valid certificate from a trusted CA passes MTA-STS validation. For most organizations, this is fine. The threat model MTA-STS addresses is the man-in-the-middle stripping TLS, not a CA being compromised.

Google and Yahoo's 2024 bulk sender requirements accelerated MTA-STS adoption significantly. If you send more than 5,000 emails per day to Gmail or Yahoo addresses, MTA-STS is now effectively mandatory for reliable delivery.

The BIMI certificate problem in plain terms

BIMI looks appealing: your logo appears in email clients, increasing brand recognition and open rates. The reality is that BIMI currently requires a VMC from a certificate authority such as Comodo, DigiCert, or Entrust.

A VMC costs between $300 and $1,500 or more per year depending on the certificate authority, the number of domains, and the logo size validation requirements. You also need to prove trademark ownership for the logo you want to display, which adds time and complexity for organizations that do not already have a registered trademark.

As a result, BIMI adoption is concentrated among large consumer brands with marketing budgets and legal teams to navigate the validation process. For most organizations, BIMI is not a realistic near-term goal.

DMARCFlow's BIMI status checker can verify whether your BIMI record is correctly published and visible to supporting receivers. But until VMC pricing drops or the validation process simplifies, BIMI will remain an enterprise-tier feature.

Why continuous monitoring matters more than one-time measurements

The monthly top-1M scan is useful for understanding where the industry is heading. But it tells you about the internet in aggregate, not about your domain specifically.

Your domain's authentication configuration is not static. Here is what actually happens over time:

Third-party senders get added without aligned SPF

Subdomains get created for new services with no SPF record

Return paths change during email provider migrations

MTA-STS policies get accidentally deleted during DNS cleanup

Teams enable new sending infrastructure and forget to update DMARC

These changes happen continuously. A scan in January tells you nothing about your configuration in March.

DMARCFlow monitors your DMARC, MTA-STS, BIMI, and SPF/DKIM configuration continuously. When your MTA-STS policy disappears, when your BIMI record stops resolving, when a new subdomain starts sending mail without SPF, you get an alert. You do not have to wait for a mail flow failure to discover the problem.

This is the practical value of continuous monitoring that one-time measurements cannot provide. Industry trends tell you where the world is going. Your own domain's monitoring tells you where you actually stand.

What to prioritize today

Based on the adoption trends and operational reality of each protocol:

DMARC at p=reject if you have not already. This is the foundation. Aggregate reports give you visibility into who is sending from your domain. Enforcement prevents spoofing. If you are at p=none, plan your transition now.

MTA-STS if you have not already. The operational overhead is low, adoption is growing as a baseline expectation, and it protects against a real attack vector. If you send bulk mail to Gmail or Yahoo, it is effectively required.

BIMI only if you have a trademarked logo, budget for a VMC (expect $300 to over $1,000 per year), and want the marketing benefit of logo display. It is a nice-to-have, not a security control.

DANE only if you have dedicated certificate management that can handle coordinated DNS updates on every certificate rotation. For most organizations, MTA-STS is sufficient.

FAQ

What is MTA-STS and how is it different from DANE?

Both protocols prevent STARTTLS stripping attacks on incoming SMTP connections. MTA-STS requires a valid TLS certificate but does not verify a specific one. DANE verifies that the exact certificate or CA in your DNS TLSA record is presenting. DANE is more secure but harder to operate because any certificate rotation requires a matching DNS update. MTA-STS is the pragmatic choice for most organizations.

Why did DANE adoption decline in the measurements?

DANE declined likely because of operational complexity. Certificate rotation requires coordinated DNS updates to TLSA records. When rotation schedules and DNS TTLs are not perfectly aligned, mail silently fails. Organizations that ran into these issues either switched to MTA-STS or removed DANE entirely.

Do I need a VMC certificate for BIMI?

Yes. BIMI currently requires a Verified Mark Certificate (VMC) or Certified Mail Certificate (CMC) from an approved certificate authority. You must prove trademark ownership for your logo. Costs range from approximately $300 to over $1,000 per year depending on the certificate authority and logo validation scope.

How is DMARC enforcement different from DMARC publication?

Publishing DMARC means having a TXT record in DNS that describes your authentication policy. Enforcement means receivers are actually applying that policy to incoming mail. A domain with p=none published has published DMARC but not enforced it. Aggregate reports tell you whether your policy is being applied and what is passing or failing.

How can I monitor my own domain's authentication adoption over time?

DMARCFlow tracks DMARC, MTA-STS, BIMI, and SPF/DKIM configuration on your domain continuously. You receive alerts when configuration changes, can monitor aggregate report data, and verify that your MTA-STS policy remains published and correctly configured. This gives you the per-domain visibility that one-time scans cannot provide.

The bottom line

The monthly top-1M measurement tells you that MTA-STS is the protocol growing in practice, DANE is slipping despite being technically superior, and BIMI remains bottlenecked by certificate costs. These trends reflect real operational decisions by real organizations, not theoretical preferences.

For most practitioners, the roadmap is clear: get DMARC to p=reject, add MTA-STS, and monitor both continuously. DANE is worth revisiting as certificate automation matures. BIMI is worth tracking but not worth prioritizing until VMC pricing comes down.

DMARCFlow gives you the continuous visibility to track your own domain's authentication posture across all four protocols. Industry trends tell you what to watch. Your own monitoring tells you what to fix.

Start monitoring your domain's authentication posture at dmarcflow.com.