What Data Shows About MX Server TLS Enforcement Rates

How many MX servers actually require TLS?

Out of 366,000 MX servers measured in a community research project, approximately 0.2% refused to accept email over plaintext connections. That is roughly 1 in 500. The other 99.8% accepted connections with or without TLS.

This is the most direct answer to "how many MX servers require TLS" that the data supports. The numbers come from direct measurement, not surveys or self-reported configuration data.

For most senders, this means the probability that a given recipient MX will negotiate plaintext if offered is extremely high. TLS is available almost everywhere, but enforcement is rare.

What the measurement covers

The project scanned MX records for a large set of domains and attempted delivery with and without STARTTLS. It recorded how many MX servers supported TLS, how many successfully negotiated it, and how many required it and refused plaintext.

The 0.2% figure refers specifically to servers that required TLS and would not accept plaintext at all. This is different from servers that merely supported TLS. Most servers both support and accept plaintext.

The distinction matters. A server that "supports TLS" will accept a plaintext connection if the TLS handshake fails or if the sender does not offer TLS. A server that "requires TLS" will refuse the connection entirely if TLS is not offered or verified.

Understanding this gap is the key to knowing why the question matters.

MTA-STS and DANE: what they guarantee and what they do not

MTA-STS (Mail Transfer Agent Strict Transport Security) lets a domain owner publish a policy stating "my mail servers require TLS." Receiving mail servers can then enforce TLS connections based on that policy when they fetch mail from that domain.

The problem is adoption. MTA-STS policies are not yet widespread, and even where they exist, they require the receiving server to actively fetch and honor the policy. Many large email receivers do not implement MTA-STS fetching.

DANE (DNS-based Authentication of Named Entities) ties the TLS certificate to DNSSEC. If both the sender and receiver support DANE, it provides stronger assurance than MTA-STS alone. But DANE requires DNSSEC on both sides, which is not yet universal.

Neither MTA-STS nor DANE forces a receiver to require TLS for inbound connections. They help senders enforce TLS when communicating with receivers who also support these standards. But the sender cannot unilaterally require TLS for incoming mail.

Why DMARC aggregate reports cannot answer this question

DMARC aggregate reports tell you which mail servers sent you email and whether they passed SPF and DKIM. They can also show you whether TLS was used for a given delivery.

What they cannot show is whether the receiving MX server required TLS or simply accepted it because the sender offered it.

This is a meaningful gap. A sender monitoring their aggregate reports might see that 95% of their inbound mail arrived over TLS and conclude their email channel is secure. In reality, most of those TLS connections would have fallen back to plaintext without the message being rejected.

Aggregate reports show TLS connectivity. They do not show TLS enforcement.

How senders can monitor TLS enforcement from their side

Three practical steps for senders who want real TLS enforcement visibility:

1. Test MTA-STS support for key domains. Use a tool that publishes an MTA-STS policy and then checks whether it is actually fetched and honored by major receivers. This tells you which large email providers enforce MTA-STS policies when they receive mail.

2. Monitor your own outbound TLS negotiation. Track not just whether TLS was used but whether certificate verification passed, whether perfect forward secrecy was available, and what cipher suites were negotiated. TLS presence is not TLS quality.

3. Use a monitoring service that tracks MTA-STS policy availability for your inbound domain. DMARCFlow monitors your inbound aggregate reports for authentication results and TLS connectivity. The MTA-STS monitoring feature tracks whether receivers are fetching your MTA-STS policy, which tells you whether they are in a position to enforce TLS for your outbound mail. Combined, these give you a more complete picture of your email security than DMARC alone.

The key limitation is that senders cannot force receivers to require TLS. They can only enforce it on their side, publish policies that encourage receivers to enforce it, and monitor whether enforcement is actually happening.

---

FAQ

How can I check if a specific domain requires TLS for incoming mail?

There is no public registry. You can test by connecting to the MX server with and without STARTTLS and observing whether it refuses plaintext. For a complete picture across all your senders, you need to monitor MTA-STS fetch behavior from their mail servers.

Should I publish an MTA-STS policy?

Yes. It costs nothing to publish and signals to receivers that you require TLS. It only helps if receivers implement MTA-STS fetching, which is increasingly common among large email providers. Without it, you have no mechanism to request TLS enforcement from receivers.

Does DANE help if MTA-STS is not widely enforced?

DANE provides stronger certificate verification when both sides support it, because it is tied to DNSSEC rather than relying on certificate authorities. However, DNSSEC adoption is still incomplete for many domains, which limits DANE's effectiveness in practice.

How does DMARCFlow help with TLS monitoring?

DMARCFlow processes your aggregate reports to show TLS connectivity rates and authentication outcomes. The MTA-STS monitoring feature tracks whether receivers are fetching and enforcing your published MTA-STS policy, which aggregate reports alone cannot show. Together these give you a more complete picture of your inbound email security.