How Many MX Servers Actually Refuse Mail Without TLS?

The short answer: Out of 366,215 MX servers tested, only 0.2 percent refused mail that did not use TLS. That is roughly 732 servers out of every 100,000.

One practitioner ran the scan across the entire internet's publicly accessible mail server landscape and published the results on Reddit. The finding surprised many: enforcing TLS for email is far safer than the average admin assumes.

This article explains what that number means, what it means for your TLS enforcement policy, and how to check your own servers before you turn enforcement on.

What One Practitioner Found Scanning 366,215 MX Servers

The researcher tested every publicly accessible MX server they could enumerate -- 366,215 servers in total. They checked whether each server would accept a connection without TLS encryption. The result: about 0.2 percent refused non-TLS connections outright.

To put that in plain terms, if you enforced TLS on your mail server tomorrow, you would likely lose fewer than 1 in 500 legitimate sending servers. Most of those failures are ancient or misconfigured servers that rarely send legitimate mail.

Is 0.2 Percent a Lot?

No. At first glance, 0.2 percent sounds like a meaningful risk. But consider the scale.

Legitimate bulk senders -- major retailers, banks, government services, cloud platforms -- all support TLS. The servers that refuse non-TLS connections are mostly end-of-life mail systems, obscure appliances, and servers with deliberate security hardening that is too strict.

The real question is not "will this break something?" The real question is "will this break anything that matters?"

Based on this data, the answer is almost certainly no.

What Does It Mean to Refuse Mail in SMTP Terms?

SMTP has two modes for handling encryption requirements:

Hard fail (reject): The receiving server closes the connection if TLS is not offered. The sending server gets a permanent error and queues the message for retry or flags it as undeliverable.

Soft fail (temporary reject): The receiving server accepts the message but may report the lack of encryption. Many servers do this to avoid losing mail during brief TLS outages.

The 0.2 percent figure refers to hard fails. These are servers that will not accept unencrypted mail under any circumstances, or servers that fail because of misconfiguration.

Most legitimate mail uses servers that either require TLS or gracefully fall back to unencrypted delivery. Very few production mail systems would be affected by enforcing TLS on the receiving side.

Why Enforce TLS for Email?

TLS encryption prevents email traffic from being read or modified in transit. Without it, SMTP is plaintext. Anyone on the network path between two mail servers can read, log, or alter the message content.

Enforcing TLS means:

No one can read your email as it crosses the internet
No one can inject content into a message in transit
You have a verifiable chain of custody from sending server to receiving server

For any organization handling sensitive communications, TLS enforcement is not optional. It is baseline hygiene.

How to Check Your MX Servers Before Enforcing TLS

Before you turn on TLS enforcement, do these three things:

1. Review your DMARC aggregate reports. DMARC reports often include TLS failure flags. If you see TLS failures in your reports, investigate those sending domains before you lock enforcement down.

2. Test your own MX configuration. Use an SMTP test tool to verify that your server correctly advertises TLS and accepts properly authenticated connections.

3. Identify high-value senders. If you receive mail from government agencies, healthcare systems, or financial institutions, verify that their IT teams have TLS enabled on their outbound mail. These organizations almost always do, but it is worth confirming.

How DMARC Monitoring Helps You Make the Call

TLS failures surface in DMARC reports. If you are already collecting DMARC data, you already have visibility into which sending servers fail TLS when they deliver mail to you. That is the data you need before you decide whether enforcing TLS on your side will cause problems.

This is where DMARCFlow fits directly into the decision chain. DMARCFlow parses your aggregate reports and surfaces TLS failure patterns alongside your DMARC and SPF data. If you see a sending domain with frequent TLS failures, you have time to contact them before you lock enforcement in place. If you see no TLS failures from a given sender, enforcing TLS for their domain is a low-risk change.

Without this visibility, you are guessing. With DMARC reports, you are making enforcement decisions based on real delivery data.

FAQ

Q: Is 0.2 percent a lot?
A: No. Out of 100,000 servers, 200 would fail. Most of those are obscure or misconfigured servers that rarely send legitimate mail. For most organizations, enforcing TLS will cause no noticeable delivery problems.

Q: Should I enforce TLS for inbound, outbound, or both?
A: Both. Inbound enforcement ensures you only accept encrypted mail. Outbound enforcement ensures your mail is not intercepted in transit. The 0.2 percent failure rate applies to inbound enforcement on your receiving servers.

Q: What if a legitimate sender fails TLS after I enforce it?
A: You will see the failure in your DMARC reports. Contact the sender and ask them to fix their TLS configuration. In the meantime, you can temporarily relax enforcement for their specific domain while they update their servers.

Q: Does enforcing TLS affect spam filtering?
A: No. TLS is a transport security mechanism, not a content filtering mechanism. It has no direct effect on spam scores. It does, however, prevent man-in-the-middle attacks that could be used to bypass content filtering.

Bottom Line

Enforcing TLS for email is safer than most people assume. The data from scanning 366,215 MX servers shows that only 0.2 percent refuse non-TLS connections. If your sender list consists of mainstream mail systems, enforcing TLS is unlikely to cause any delivery problems.

Check your DMARC reports. Identify any senders with TLS failures. Contact them if needed. Then enforce TLS with confidence.

DMARCFlow helps you monitor TLS failure rates through your existing DMARC reports, so you can make enforcement decisions based on data, not guesswork.