How Many MX Servers Require TLS for Incoming Mail?

How Many MX Servers Actually Require TLS?

The short answer: not many.

When a practitioner asked on r/DMARC how many MX servers refuse mail without TLS, someone ran the numbers across 366,000 MX records. The result: roughly 0.2 percent of MX servers enforce TLS for incoming connections. That means 99.8 percent accept plain text.

What Does It Mean When an MX Server Requires TLS?

When an MX server requires TLS, it means the server will not accept an SMTP connection that starts unencrypted. The connection is either encrypted or it is refused.

This is different from SMTP transport TLS, which is opportunistic. Opportunistic TLS means a server advertises STARTTLS support, upgrades the connection if both sides support it, but falls back to plain text if TLS negotiation fails. Required TLS means the server breaks the connection rather than falling back.

The practical difference:

• Opportunistic TLS (most common): Connection upgrades to encryption if possible, but plaintext is acceptable if the other side cannot negotiate TLS.
• Required TLS (rare): The connection is dropped if TLS cannot be established. No fallback.

Why Do Most MX Servers Still Accept Plain Text?

Backwards compatibility is the main reason.

Email has been running on plain SMTP since the 1980s. Enforcing TLS requires both sides to support it. If even a small percentage of legitimate senders cannot do TLS, a strictly enforcing server will lose mail from those sources. Many postmasters choose opportunistic TLS to avoid that outcome.

Legacy mail systems, especially in healthcare, finance, and government environments, sometimes cannot do TLS 1.2 or 1.3. Forcing TLS would break those delivery paths.

A secondary reason is operational complexity. Enforcing TLS at the MX level requires certificate management, TLS version and cipher configuration, and ongoing maintenance. Opportunistic TLS is easier to run.

What the Rarity of Enforced TLS Actually Means for You

If you run an MX server, the data should not push you to immediately require TLS. It should push you to understand your current configuration.

Most of the internet still tolerates plaintext because the cost of blocking is higher than the risk of unencrypted delivery for most paths. Your risk profile determines whether enforced TLS makes sense, not the general adoption rate.

That said, there are cases where enforced TLS is correct:

• Internal mail systems where you control both endpoints
• Regulated environments where email must be encrypted in transit
• High-value communication paths where interception risk is real

For public-facing MX servers that receive mail from the open internet, opportunistic TLS with a strong cipher suite is the practical default.

How to Check Whether Your MX Server Enforces TLS

The easiest check is to try connecting with and without TLS:

# Test with TLS (should work everywhere) openssl s_client -connect mail.example.com:25 -starttls smtp /dev/null | grep "Verify return code" # Test what happens without TLS (if this succeeds, your server accepts plaintext) telnet mail.example.com 25

If the telnet connection produces an SMTP greeting without requiring a TLS handshake first, your server accepts plain text.

You can also check whether a server enforces TLS by watching what happens when you attempt delivery without TLS. A server that requires TLS will respond with something like:

454 TLS required but not negotiated

A server that accepts plaintext will give you the normal 220 greeting and let you issue MAIL FROM without any encryption.

How This Interacts With MTA-STS

MTA-STS is a different layer. It is a policy that senders can publish via DNS, telling receiving servers: I require TLS for mail delivered to this domain, and here is my valid certificate.

MX-level TLS enforcement is a receiving-side configuration. MTA-STS is a sender-side policy declaration. They can work together but they are independent.

MTA-STS says: "I am a sender, and I will only deliver to servers that support TLS with a valid certificate." MX-level TLS says: "I am a receiver, and I will only accept connections that negotiate TLS."

Most domains publish MTA-STS policies. Fewer receivers actually enforce TLS at the MX level. MTA-STS has grown faster than MX-level enforcement because it shifts the burden to senders rather than receivers.

Does This Affect DMARC or Email Delivery?

Not directly. DMARC operates on the message level, checking whether SPF, DKIM, and DMARC alignment pass. TLS operates one layer below, during the SMTP transport session, before DMARC checks run.

But there is an indirect connection. If you are sending email to a server that accepts plaintext, that traffic is visible to anyone watching the network path. In some configurations, forwarded mail or mailing list traffic could traverse such paths, potentially exposing content or metadata even when the final delivery is authenticated.

For high-sensitivity email flows, enforcing TLS is a reasonable additional layer even though DMARC does not require it.

What to Do If Your Server Does Not Enforce TLS

If your current configuration accepts plaintext, the decision to change depends on your sender profile:

1. If you receive mail from the open internet: keep opportunistic TLS, focus on enforcing TLS for your outbound delivery.
2. If you only receive from known senders: consider requiring TLS for those specific IP ranges or domains.
3. If you are in a regulated environment: review your compliance requirements for email encryption in transit.

Enforcing TLS everywhere is not practical for most public MX servers. The right move is understanding your current posture, then making a deliberate choice rather than leaving it as an accident.

FAQ

Does TLS at the MX mean my email is encrypted end to end?

No. TLS at the MX encrypts the connection between the sending server and your receiving server. The message may traverse other hops unencrypted before it arrives at your MX. End-to-end message encryption requires something like S/MIME or PGP at the message layer.

Can I send email to a server that does not support TLS if I require TLS on my side?

If you require TLS and the receiving server cannot negotiate it, your MTA will hold the message and retry. If the server never supports TLS, the message will eventually bounce or be held indefinitely depending on your MTA configuration. This is why requiring TLS for all outbound delivery is rarely practical for public-facing MX servers.

How is MX-level TLS different from MTA-STS?

MX-level TLS is a configuration on the receiving mail server that determines whether it accepts unencrypted connections. MTA-STS is a policy that senders publish via DNS, telling receivers: I require you to use TLS and present a valid certificate. MTA-STS policies do not force receivers to enforce TLS, they inform senders which receivers they should refuse to deliver to if TLS is not available.

Does requiring TLS affect deliverability?

It can. If you require TLS and a legitimate sender cannot negotiate it, their messages will not be delivered. For most public-facing MX servers, this means lower deliverability for mail from older systems. Enforcing TLS is appropriate when you control the sender landscape or operate in an environment where all legitimate senders support TLS.