How Many Mail Servers Actually Require TLS?

A small research project posted on r/DMARC asked a simple question: how many MX servers actually enforce TLS? The answer, based on scanning roughly 200 mail servers: 22% require TLS, and 78% do not.

That is the headline. Here is the context.

What the survey actually measured

The methodology was straightforward. Someone scanned MX hosts across a range of domains and tested whether each one would accept mail without a TLS connection. The result: about 1 in 5 mail servers in the sample reject plaintext connections outright.

The sample is not large enough to represent the entire internet, but it aligns with broader observations from email security practitioners. Large providers (Gmail, Microsoft, Yahoo) enforce TLS. Many smaller and mid-size organizations do not, either because their mail server software is configured conservatively or because they have not updated their default settings in years.

Why most mail servers do not require TLS yet

Three reasons explain why TLS enforcement is not universal:

Legacy compatibility. Some older mail server configurations expect plaintext fallbacks. Enforcing TLS means those systems may stop receiving mail if their operators have not tested TLS-only delivery.
Operational caution. If a mail server operator is not sure whether their counterparties support TLS, dropping non-TLS mail feels risky. The safe default has historically been to accept everything and sort out any problems later.
Misconfiguration that looks like policy. Some servers are configured to prefer TLS but still accept plaintext, not because they made an intentional choice but because that is the default in their software.

The third point is worth dwelling on. A server that accepts plaintext is not necessarily making a statement. It may simply never have been locked down.

What this means for your TLS enforcement policy

If you are considering a reject policy (dropping mail that cannot be delivered over TLS), the 22% figure tells you something concrete: roughly 1 in 5 mail servers you communicate with would fail that check on first pass.

That does not mean you should not enforce TLS. It means you should do it deliberately. Here is a practical sequence:

Start with monitor. Before switching to reject, collect TLS failure data for a few weeks. Most modern mail servers log TLS negotiation outcomes. You want to know which of your correspondents cannot receive TLS mail before you block them.

Identify the gaps. If you see failures concentrated around specific domains, contact those organizations and give them notice. A forwarded mail with notice is better than silent bounce.

Enforce on a schedule. Once you have resolved the monitor-phase failures, switch to reject. Give the affected parties 30 days notice if possible. The 22% who cannot receive TLS mail are mostly systems that have never been asked to upgrade.

How to check TLS requirements for a specific domain

If you want to check whether a particular domain requires TLS, you can test it manually with openssl:

openssl s_client -connect mail.example.com:25 -starttls smtp

Look for a line that says Verify return code: 0 (ok). If the connection succeeds and you see a certificate, TLS is working. If the server immediately drops the connection or returns an error before offering STARTTLS, that server may not support TLS at all.

This is where DMARCFlow earns its place. Instead of relying on scattered openssl checks, DMARCFlow monitors TLS failure rates across all your domains and correspondent relationships in one view. When a previously TLS-capable server starts failing, you get an alert before that failure becomes a bounce problem. Running TLS monitoring manually works for one or two servers; it does not scale to an organization with dozens of domains and hundreds of counterparties.

FAQ

What percentage of email servers require TLS?
Based on a survey of roughly 200 MX hosts, approximately 22% strictly require TLS. The remaining 78% accept plaintext connections or have not been configured to enforce TLS.

Is it safe to reject non-TLS mail?
It depends on who you communicate with. If your primary correspondents are on large consumer mail platforms (Gmail, Microsoft, Yahoo), enforcing reject is safe because those providers require TLS. If you communicate frequently with smaller organizations, government agencies, or older infrastructure, rejecting non-TLS mail may cause legitimate messages to bounce until those servers are updated.

How do I test if a mail server requires TLS?
Use an SMTP test with STARTTLS: openssl s_client -connect mail.example.com:25 -starttls smtp. If the connection succeeds and completes a TLS handshake, the server supports TLS. To test whether it enforces TLS (rejects plaintext), try connecting on port 25 without STARTTLS and see if the server accepts mail anyway.

Bottom line

22% of mail servers in this sample require TLS. That number is high enough to matter and low enough to mean that a blanket reject policy will break some legitimate mail unless you clean up the TLS failures first.

Start with monitoring. Fix what you can. Then enforce. That is the sequence that works, not the one that sounds most secure on paper.