Why Email Transit Security Lags Sender Authentication

What the Numbers Say: The Current State of Email Security Adoption

A researcher has now run unfiltered DNS queries against the top million domains for two consecutive months, tracking DMARC, MTA-STS, DANE, and BIMI adoption at scale. The headline finding is consistent: sender authentication is running years ahead of transit security.

DMARC, which verifies that a sending domain is authorized to use an IP address and DKIM key, is the only standard where adoption is visibly accelerating toward broad coverage. MTA-STS, which lets a receiving mail server authenticate that the sending server is authorized to receive mail for a domain, and DANE, which binds TLS certificates to DNSSEC, are both progressing at a fraction of the pace.

The reason is structural, not technical.

The Adoption Gap: Why Transit Security Lags Sender Authentication by Over a Decade

DMARC is a unilateral publish-and-forget standard. A domain owner adds a TXT record to their DNS, and every receiving mail server on the internet can check it immediately. MTA-STS and DANE require both sides of the connection to participate.

You can publish an MTA-STS policy for your domain. But if the receiving mail server does not also advertise an MTA-STS policy that your server can fetch, nothing happens. The same is true for DANE. These standards only protect connections where both sides have opted in.

This is not a minor logistical difference. It fundamentally limits how fast these standards can spread. DMARC compounds security with every new adopter. MTA-STS and DANE only protect the specific pairs of domains where both endpoints are enrolled. The growth curve for bilateral standards flattens much faster than for unilateral ones.

One practical consequence: aggregate report monitoring is the only way to see where your own mail is failing authentication. The adoption gap this research describes is not abstract. If your alignment rate is lower than expected, you need to find out why before you move to p=reject. That requires reading your own DMARC aggregate reports.

Provider-Sized Blocks: How One Decision From an Email Host Moves Thousands of Domains

The second month of measurement surfaced something the first month could not: month-over-month deltas. And the deltas revealed something important.

Email security adoption does not happen domain by domain. It happens in provider-sized blocks.

When a large email host or DNS provider enables a standard by default for all customers, thousands of domains move at once. When that same provider removes a standard for operational reasons, those same thousands move backward simultaneously.

This is why the second month showed DANE going backward overall. One provider removed TLSA records for its entire customer base. That single decision dominated the global DANE delta for the month, swamping the growth from hundreds of other domains that had added DANE records independently.

Remove that outlier and DANE grew. The standard is not dead. It is sensitive to provider decisions in a way that DMARC, which requires no DNSSEC and no receiver cooperation, simply is not.

What this means for your domain: your email security posture depends partly on who hosts your email. If your provider enables MTA-STS by default, you get the benefit without doing any work. If they remove DANE records, your outbound mail loses that protection. These are not always choices you make.

DANE Stepped Backward and Why That Tells You Something Important

The DANE regression is a useful signal for anyone building email security strategy.

DANE is the only standards-track method to verify that the TLS certificate presented by a receiving mail server is actually authorized for that domain. SPF and DKIM verify the sender. DANE verifies the receiver. It closes the last mile where a man-in-the-middle could impersonate a receiving mail server and intercept mail in transit.

But DANE requires DNSSEC, and DNSSEC requires active management. Unlike a DMARC TXT record, a DNSSEC-signed zone requires ongoing key rollovers, careful TTL management, and resolver support that is still not universal. When a provider removes DANE records for operational reasons, it is usually because the complexity of managing DNSSEC at scale outweighed the benefit for their customer base.

DANE is worth implementing for your outbound mail if your DNS infrastructure supports DNSSEC and you have the operational capacity to maintain it. Do not treat it as a first priority. Get DMARC right first. Add MTA-STS for your mail submission and inbound routes. Then evaluate DANE.

BIMI and Brand Trust: Who Is Actually Moving Forward

BIMI, the standard that displays a brand logo next to verified emails in supporting mail clients, requires DMARC at p=reject, a CA-certified logo, and a Mark Checking certificate in most implementations. It is the furthest along the implementation chain of any of these standards.

The measurement data shows BIMI growing, but slowly and unevenly. Large consumer mail providers support it. Enterprise mail systems mostly do not yet. The certificate chain and logo requirements create enough friction that most domains have not moved past the planning stage.

What the BIMI numbers show is that reaching p=reject on DMARC is increasingly tied to brand trust features beyond pure security. Several major inbox providers display BIMI logos for domains that meet the requirements. Getting to p=reject is no longer only a security goal. For organizations that care about email brand presence, it is also a deliverability goal.

What the Adoption Gap Means for Your Domain

The adoption numbers are a benchmark. Here is what to do with them.

First, do not wait for the ecosystem to adopt MTA-STS before you implement it. Publishing an MTA-STS policy for your mail servers protects the delivery of your mail to receivers that support it. When you send mail to a domain that has MTA-STS enforced, that domain can verify your server is authorized. MTA-STS works in both directions.

Second, track your own DMARC alignment rate over time. Aggregate reports tell you what percentage of your legitimate mail is passing SPF, DKIM, both, or neither. Most organizations discover that a significant fraction of their transactional mail is not aligned and would fail DMARC if they moved to p=reject.

Third, use aggregate reporting to catch alignment failures before they become incidents. A vendor that changes their sending infrastructure without updating your SPF record, a marketing platform that switches IPs without notice, a legacy system that still sends on port 25 without authentication: these are the things that break DMARC alignment in production. Aggregate reports are the only reliable way to see them.

DMARCFlow collects and parses DMARC aggregate reports, tracks alignment rates over time, and alerts when your pass rate drops below expected thresholds. Understanding where your mail stands relative to the industry benchmarks in this research requires seeing your own data first.

FAQ

Q: Why is MTA-STS adoption so much lower than DMARC adoption?

DMARC authenticates the sender. One domain publishing a DMARC policy works for every receiving mail server that checks DMARC. MTA-STS and DANE require bilateral agreement: a sender can publish MTA-STS, but if the receiving mail server does not enforce it, the security benefit is zero. This creates a chicken-and-egg problem that slows adoption significantly.

Q: Is DANE still worth implementing?

DANE remains the only standards-track method to authenticate the TLS certificate of a receiving mail server. It is worth implementing for your outbound mail if you have stable DNSSEC infrastructure. Do not treat it as a first priority: get DMARC right first, add MTA-STS, then evaluate DANE.

Q: Should I wait for the ecosystem to adopt MTA-STS before implementing it?

No. Implementing MTA-STS for your outbound mail protects delivery to receivers that support it and lets those receivers verify your server is authorized. The standard benefits you as soon as even one major receiver enforces it for their inbound mail.

Q: What does "email security moves in provider-sized blocks" mean for my organization?

Most domains do not actively choose email security standards. Their email provider or DNS host does it for them when services are provisioned or changed. This means adoption accelerates in chunks when a large provider enables a standard by default. Your email security posture depends partly on who hosts your email.

Q: How does this research measure adoption across the top million domains?

Researchers run unfiltered DNS resolvers in multiple regions and query authoritative DNS records for each protocol directly. They count only domains present in the top million in both the current and previous month, which eliminates noise from domain churn and gives a cleaner month-over-month signal.