How Many Mail Servers Require TLS? MTA-STS and DANE Data

How Many Mail Servers Actually Require TLS in 2026?

Fewer than 1 in 500 mail servers that support STARTTLS actually refuse plaintext connections.

A measurement across the top 1 million internet domains and 366,215 unique MX hostnames found that only 593 mail servers (0.2%) refused to accept mail over a plaintext connection even when the sending server was capable of TLS. This is the TLS enforcement reality for email in 2026.

The finding matters because two protocols exist specifically to change this picture: MTA-STS and DANE. Both let a domain publish a policy saying "mail servers that contact this domain must use TLS." Both have been in use for years. Neither has moved the needle much.

This article breaks down what the data found, what MTA-STS actually achieves versus DANE, which providers enforce TLS and which do not, and what it means for your domain.

---

What the Measurement Found

The study probed MX hostnames across over 1 million domains using STARTTLS to determine what happens when a sending server tries to deliver mail without encryption. The results split into three groups.

Group 1: No STARTTLS support at all (3.8%)
These mail servers do not support encrypted delivery. There is nothing to enforce.

Group 2: Offers STARTTLS, accepts plaintext (96.0%)
The largest group. These servers announce STARTTLS capability but will happily accept an unencrypted connection if the sending server prefers it. This is opportunistic TLS: encryption works when both sides agree to use it, but either side can fall back to plaintext.

Group 3: Offers STARTTLS, refuses plaintext (0.2%)
Fewer than 600 mail servers out of 366,000 that support STARTTLS actually require it.

The per-domain picture is slightly worse. When you look at whether a domain enforces TLS across all of its MX hosts, the number drops to 0.096% -- 598 domains out of 620,240 measured. Most domains that enforce TLS on one MX host still accept plaintext on others.

---

MTA-STS: What Publishing a Policy Actually Achieves

MTA-STS (Mail Transfer Agent Strict Transport Security) lets a domain publish a policy via DNS that says: "mail servers contacting this domain must offer STARTTLS and must present a valid certificate." The policy can be in test mode (testing) or enforce mode (reject plaintext).

The data shows MTA-STS works, but narrowly.

Domains publishing an MTA-STS enforce policy are 8.5 times more likely to have TLS-enforcing MX hosts than the average domain. That is a real signal. Someone is reading the policy and acting on it.

But the gap between policy and reality is wide. Of the 0.82% of domains that publish MTA-STS at enforce, 99.18% still accept plaintext connections on at least one MX host. The policy says reject -- but the mail server still accepts the fallback.

Why? Because MTA-STS only applies to direct delivery. If a message passes through a mailing list, a forwarding service, or any third-party relay, MTA-STS does not cover that path. Sending servers also have to implement MTA-STS to respect it, and many do not. The policy is directional but not universally binding.

For operators, this means publishing MTA-STS at enforce is the right move and does improve your odds of receiving encrypted mail. It does not guarantee it.

---

DANE: The 1.2x Problem

DANE (DNS-Based Authentication of Named Entities) binds TLS certificates to DNS using DNSSEC. If MTA-STS says "this domain wants TLS" via a policy file, DANE says "this domain's certificate looks like this" via DNS records.

The measurement found something awkward for DANE advocates.

Domains publishing DANE TLSA records are only 1.2 times more likely to enforce TLS than the average domain. That is barely above baseline.

The reason is structural, not technical. DANE adoption has been driven almost entirely by hosting providers setting it as a default for their customers. When Strato, a German hosting provider, added DANE support, DANE adoption across the internet jumped. When you exclude that provider effect, DANE deployment is essentially flat.

This means DANE statistics mostly reflect what defaults providers chose, not what domain operators deliberately decided. A domain with DANE published is not necessarily a domain that thought carefully about TLS enforcement. It may just be hosted at a provider that turned it on by default.

DANE also requires DNSSEC, which has its own deployment friction. DNSSEC adoption remains low outside of certain regions and provider ecosystems.

---

Who Actually Enforces TLS?

The geographic concentration is striking. German-speaking Europe accounts for 15.4% of all TLS enforcers but represents only 3.8% of mail-eligible domains measured. German domains are 4.7 times over-represented among enforcers.

This is not a mystery. The German Federal Office for Information Security (BSI) published a technical guideline (TR-03108) that recommends TLS enforcement for government and regulated sector domains. GDPR also creates data-security obligations that incentivize encrypted transport. The combination has produced a cluster of enforcement in .de domains that does not exist elsewhere at comparable scale.

On the provider side, the findings are blunt.

Microsoft 365: 0 of 116,692 measured tenant hostnames enforce TLS. Google: 0. Cloudflare: 0. Zoho, Proton, Fastmail, Yandex: 0.

These are the providers that handle the majority of business email worldwide. Their tenants do not enforce TLS because the providers have not enabled it as a default and have not made it easy to turn on.

Cisco iphmx was the only major provider with non-zero enforcement: 22 of 2,546 measured hostnames.

AWS SES Mail Manager stands out differently. 71 of its 598 measured domains enforce TLS. But 13 of its 14 own hostnames enforce it -- one product default, not a series of customer decisions. The distinction matters: if enforcement is provider-default, it reflects the provider's choice rather than the operator's.

---

What This Means for Your Domain

If you publish MTA-STS at enforce, you are doing something meaningful. Domains with MTA-STS enforce policies are 8.5x more likely to receive encrypted mail than domains without one. That multiplier is real.

But you should also understand what it does not guarantee. Your MTA-STS policy covers direct delivery only. It does not protect mail that passes through forwarding services, mailing lists, or third-party relay chains. It only works if the sending mail server implements MTA-STS -- and many do not, especially older or smaller mail server software.

You should also know whether your policy is actually being respected. TLS enforcement failures are silent: a sending server that cannot complete TLS will typically queue the message or retry in plaintext without telling you. If you publish MTA-STS at enforce and do not monitor failure reports, you have no way to know whether your policy is working or which counterparties are silently falling back.

DMARCFlow aggregates MTA-STS failure reports, giving you visibility into which sending servers attempted plaintext delivery and why. That visibility is the difference between knowing your enforcement policy works and hoping it does.

If you publish DANE, the honest framing is that it currently reflects provider defaults more than deliberate operator decisions. Until DANE adoption is driven by domain operators rather than hosting providers, its statistics will be noisy. DANE is technically sound. Its deployment reality is that it mostly shows up where a provider turned it on.

---

The Outlook for 2026 and Beyond

Email authentication on the sender side is converging toward universal adoption. SPF, DKIM, and DMARC are increasingly standard for domains that care about deliverability. Within the next decade, most legitimate sending domains will have at least one of SPF or DKIM passing.

Transport security is a different curve. MTA-STS and DANE require action by receiving domains, not just sending domains. The measurement data shows that receiving domain enforcement is not keeping pace with sending domain authentication. Even in the most optimistic scenario, TLS enforcement for email is tracking toward the 2040s before reaching majority adoption.

The gap between these two curves is where email remains vulnerable during transit. A message can be perfectly authenticated at sending and completely unencrypted in transit to the receiving server.

Publishing MTA-STS at enforce, monitoring TLS failures, and pushing back when counterparties do not support encryption -- these actions move the numbers, even if slowly. Every domain that publishes a TLS enforcement policy adds to the incentive for sending servers to implement it.

---

Frequently Asked Questions

What percentage of mail servers require TLS in 2026?

Only 0.2% of MX servers that support STARTTLS actually refuse plaintext connections. On a per-domain basis, fewer than 0.1% of domains enforce TLS across all their mail hosts.

Does publishing MTA-STS at enforce mean my mail is protected?

It means your domain prefers encrypted delivery and receiving servers that implement MTA-STS will respect that preference. However, 99.18% of domains that publish MTA-STS at enforce still accept plaintext on at least one MX host. The policy does not guarantee enforcement, and it only applies to direct delivery, not relay chains.

Does DANE actually improve email security?

Technically, DANE provides a stronger certificate binding than Certificate Authorities alone. Practically, measured DANE adoption shows only 1.2x baseline enforcement -- meaning DANE publishers are barely more likely to enforce TLS than the average domain. This is because DANE adoption reflects hosting provider defaults more than deliberate operator decisions.

Why does Germany enforce TLS more than other countries?

German-speaking Europe accounts for 15.4% of TLS enforcers but only 3.8% of mail-eligible domains. The concentration is driven by BSI TR-03108 requirements and GDPR data security obligations in regulated sectors, particularly finance, healthcare, and government.

What can I do to increase TLS enforcement for my domain?

Publish an MTA-STS policy at enforce mode. Monitor MTA-STS failure reports to identify which sending servers are silently falling back to plaintext. Work with sending partners who fail TLS to upgrade their mail server configurations.