What Percentage of Mail Servers Refuse Email Without TLS?

The Question: Do MX Servers Really Refuse Mail Without TLS?

Yes. Some do. The question is not whether TLS matters, it is how many servers enforce it strictly.

The short answer: major consumer and enterprise providers (Google Workspace, Microsoft 365, Yahoo, Fastmail) all enforce TLS to some degree. Smaller and self-hosted mail servers vary widely. Some require it, some offer it but do not enforce it, and some will accept plaintext connections without complaint.

This article breaks down what is known, how to test for yourself, and what it means when you send email.

What the Data Shows: TLS Enforcement Rates

Exact TLS enforcement statistics are hard to pin down because they depend on who is measuring and how. Several studies and surveys give a consistent picture:

Google reported in its transparency report that over 90% of email sent to Gmail used TLS encryption in recent years.
Microsoft has similarly reported high TLS adoption for inbound M365 traffic.
Studies of MX servers across the public internet show a different picture: roughly 30-40% of externally visible mail servers do not advertise STARTTLS support at all, and of those that do, a meaningful fraction do not require it.

The more relevant question for most senders is not the global average but the enforcement rate among the domains you are trying to reach. If you are sending to Gmail, Microsoft 365, and Fastmail addresses, TLS is effectively required. If you are sending to legacy government or academic systems, the picture is more mixed.

Why STARTTLS Enforcement Matters for Email Deliverability

When a receiving server enforces TLS, it does not accept the message if the sending server cannot complete a STARTTLS handshake. The message is rejected outright, not deferred and retried. This means:

Unencrypted email to a strict server never arrives.
Retry logic does not help. The sender must support TLS to deliver at all.
Missing or misconfigured TLS looks identical to a connection refusal from the receiver's perspective.

For transactional email services and marketing platforms, this is a deliverability risk. If your sending infrastructure does not enforce TLS, you may be silently losing messages to strict receivers without knowing it.

For inbound email, TLS enforcement also matters: it prevents eavesdropping on email in transit, which is why security-conscious organizations increasingly require it.

Which Major Providers Enforce TLS

These providers enforce TLS for inbound email from external senders:

Google Workspace / Gmail: Enforces TLS for mail from external senders when both sides support it. Will reject connections from servers that advertise TLS but cannot complete the handshake.
Microsoft 365 / Outlook.com: Enforces TLS for inbound mail. M365 requires TLS 1.2 or higher.
Yahoo Mail: Enforces TLS for inbound email from external senders.
Fastmail: Enforces TLS and rejects unencrypted connections on port 25 for many configurations.
Apple iCloud: Enforces TLS for inbound mail.

This is not an exhaustive list, but it covers the providers that represent a large fraction of consumer and business email addresses. If your email reaches any of these, TLS is not optional.

How to Test Whether an MX Server Requires TLS

You can test MX TLS enforcement from the command line. These methods work on Linux and macOS.

Test with openssl:

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

If the server requires TLS, it will either close the connection immediately after you decline STARTTLS, or it will show a successful TLS handshake with a valid certificate. Look for the Verify return code line and a negotiated cipher. If you see a cipher listed, STARTTLS is working.

To test whether the server enforces TLS strictly (rejects non-TLS connections):

bash
# Try connecting without STARTTLS offer
openssl s_client -connect mail.example.com:25

If the server accepts the connection without complaining, it is permissive. If it closes the connection or behaves strangely, the server may be strict.

Check MX records and TLS advertising with dig:

bash
dig mx example.com +short
openssl s_client -connect $(dig +short mx example.com | head -1 | awk '{print $2}'):25 -starttls smtp 2>&1 | grep -i "cipher\|protocol\|verify"

This gives you the MX host, attempts STARTTLS, and shows which TLS version and cipher was negotiated.

Test with nmap:

bash
nmap --script smtp-starttls -p 25 mail.example.com

This runs the STARTTLS detection script against the target MX host.

What to look for:

Does the server advertise STARTTLS? (If not, it may not support TLS at all)
Does the server present a valid certificate?
What TLS version is negotiated? (TLS 1.2 or higher is current best practice)
Does the server close the connection without STARTTLS, or accept plaintext?

If the server closes the connection when you do not offer STARTTLS, it is enforcing TLS. If it accepts plaintext anyway, it is permissive rather than strict.

What Happens When You Send Email Without TLS to a Strict Server

A strict server that requires TLS does not send a special error message. It simply closes the TCP connection after the STARTTLS handshake fails or after it decides the client is not meeting its TLS requirements. From the sending side, the error looks like a network-level connection reset: the remote host cut the connection, no bounce message, no queued retry.

This is why TLS failures can be silent failures. A sender without proper monitoring may simply see messages that appear to send but never arrive, with no indication of why.

Some servers are stricter than others:

Strict servers: close the connection if TLS cannot be negotiated. Your message is gone.
Permissive servers: advertise TLS but still accept plaintext if the client does not upgrade. Your message arrives but is not encrypted.

How DMARC Works in the Context of TLS Requirements

DMARC builds on SPF and DKIM, not on TLS directly. It does not require TLS. However, TLS and DMARC are complementary:

TLS encrypts the transport layer, preventing eavesdropping in transit.
DMARC authenticates the sender domain, preventing spoofing.
Both are needed for complete email security.

TLS ensures no one can read your email as it crosses the internet. DMARC ensures the email actually came from the domain it claims to be from. They address different threats.

This is where DMARC monitoring becomes useful. A DMARC monitoring service like DMARCFlow aggregates your DMARC reports and surfaces which receiving servers accept your mail and whether they use TLS. If a domain that should be accepting your mail shows a spike in authentication failures, the DMARC report data can help you identify whether TLS mismatches are contributing to the problem.

For organizations that want visibility into whether their mail is being sent over TLS and whether their domain is being spoofed, DMARC reports are the primary tool. DMARCFlow can show you TLS-related information from aggregate reports, so you can correlate delivery issues with encryption status across your sending domain.

What Admins Should Do

1. Enforce TLS on your outbound mail server. Do not make it optional. Configure your mail server to require TLS 1.2 or higher and reject connections that cannot negotiate it.

2. Test your MX servers. Use the openssl or nmap commands above to check whether your inbound MX advertises and enforces STARTTLS. If it does not, update your configuration.

3. Monitor your DMARC reports. Your DMARC reports show which receiving servers accept your mail and whether they use TLS. If you see a high failure rate for a domain that should accept your mail, TLS issues may be part of the problem.

4. Do not assume plaintext is fine. Even if most of your mail arrives without TLS, the strict servers will silently drop messages that do not support it. The fraction of messages that fail silently is easy to miss without monitoring.

TLS enforcement is not universal, but it is common enough among the providers that matter that treating it as required is the safer configuration.