99.8% of Mail Servers Still Accept Unencrypted Email

Most email administrators assume that sending without TLS is basically impossible in 2026. The conventional wisdom goes: STARTTLS is everywhere, unencrypted SMTP is a relic, and any server still accepting plain-text connections is either broken or malicious.

A measurement study tested 366,215 MX servers. The result: 99.8% of them still accept unencrypted email. Only 0.2% refuse a connection that does not offer TLS.

That number is worth sitting with.

The Measurement: How 366,000+ MX Servers Were Tested

The study probed MX records for a large sample of domains, connecting to each reported mail exchanger and attempting to send without negotiating TLS. Servers that accepted the unencrypted connection were counted as accepting. Servers that responded with a TLS handshake requirement or refused the connection outright were counted as refusing.

Of 366,215 MX servers tested, roughly 730 refused non-TLS connections. The remaining 365,485 accepted them.

A server that accepts an unencrypted connection is not the same as one that prefers or recommends unencrypted delivery. But acceptance means the communication happens without encryption or authentication at the transport layer.

What the Data Actually Shows

Three things are worth separating:

1. Most mail servers implement STARTTLS but do not require it. They offer encryption, but they complete the delivery even if the connecting client never negotiates it. This is opportunistic TLS, defined in RFC 3207. The server advertises STARTTLS in its EHLO response, but a client that ignores the advertisement still gets through.

2. Very few servers enforce TLS. The 0.2% that refuse non-TLS connections are the exception. Most deployments of mandatory TLS require explicit configuration. In Exchange Online, this is enforced via a transport rule. In Postfix, it requires smtp_tls_policy_maps. It is not the default.

3. The unauthenticated man-in-the-middle risk is not theoretical. If a server accepts an unencrypted connection, any party positioned between the sending server and the receiving server can read, modify, or inject mail content. This includes network intercepts, compromised routers, and BGP hijacks. The risk exists on the 99.8% of paths that accept unencrypted delivery.

Why This Matters for Your Email Threat Model

Email security conversations focus heavily on SPF, DKIM, and DMARC. These protocols authenticate the sending domain. They tell the receiving server that a message purporting to be from example.com actually came from an authorized sender.

What they do not do is encrypt the transport.

A message can pass SPF, DKIM, and DMARC checks while traveling over an unencrypted channel. The authentication is about the domain, not the pipe. An attacker who cannot spoof your domain may still be able to read your messages if the destination server accepts unencrypted connections.

For threat models that account for sophisticated adversaries - state-sponsored espionage operators, well-positioned network attackers - transport encryption matters independently of authentication. You cannot rely on SPF and DKIM to protect message confidentiality.

For commodity threats - mass surveillance, ISP-level logging, accidental exposure on shared infrastructure - unencrypted transport means your emails are readable in plaintext at every hop.

What This Means for TLS Policy Decisions

If you are configuring your own mail server, the data suggests two distinct questions:

Should my server accept incoming connections without TLS?
Most practitioners answer no, but the data says the industry has not moved there yet. Requiring TLS for inbound delivery is a security hardening measure. It eliminates a class of interception risk. It is increasingly considered baseline practice for any organization with serious email security requirements.

Should my server connect to other servers without TLS?
This is harder to control. Your outbound mail may be delivered to a server that accepts unencrypted connections. You cannot force a remote server to upgrade its TLS settings. What you can do is monitor which destinations accept unencrypted connections and flag those that do not offer any encryption at all.

How to Monitor TLS Behavior Across Your Email Traffic

Standard SMTP logging captures TLS negotiation outcomes, but reviewing it manually across thousands of connections is impractical. This is where aggregate reporting helps.

DMARC aggregate reports include TLS connection data for messages received from your domains. Specifically, they show which sending servers connected with and without encryption, which servers offered STARTTLS but did not require it, and which destinations consistently deliver over unencrypted channels. This data is generated automatically as part of DMARC reporting infrastructure, which means organizations already receiving DMARC reports can access TLS monitoring without deploying new tooling.

For inbound monitoring, the relevant question is what percentage of sending servers reach you without TLS. For outbound monitoring, you want visibility into which destinations accept unencrypted deliveries from your mail server. Both questions are answerable with the right aggregate report data.

MTA-STS (RFC 8461) provides a complementary mechanism: it lets a domain publish a policy requiring TLS for mail delivered to that domain. DMARCFlow monitors compliance with MTA-STS policies across your sending domains, flagging destinations that deliver mail without encryption despite an active STS policy requiring it.

Key Takeaways

99.8% of MX servers accept unencrypted email. TLS enforcement is not the norm.
STARTTLS adoption is widespread. STARTTLS requirement is not.
Transport encryption and domain authentication are separate problems. Both matter independently.
Your threat model should account for unencrypted delivery paths even when SPF and DKIM pass.
Monitoring TLS behavior across your email traffic is practical using data already in your DMARC aggregate reports.

The assumption that TLS is everywhere is understandable. The campaign to encrypt email has been real and successful in terms of availability. But availability is not the same as enforcement, and the distinction matters for security decisions made on the basis of it.

FAQ

Does accepting unencrypted connections mean the server is insecure?
Not necessarily. A server may accept unencrypted connections while enforcing authentication and maintaining other security controls. What it means is that the transport layer offers no confidentiality or integrity protection for that particular delivery attempt.

Is it safe to send email to servers that accept unencrypted connections?
It depends on your threat model. For most organizations, the risk of an unencrypted delivery is acceptable for non-sensitive mail. For sensitive communications, requiring TLS for delivery is a meaningful hardening step, even if most destinations negotiate it opportunistically.

How is this different from MTA-STS?
MTA-STS lets a domain publish a policy requiring that mail be delivered over TLS. It is a mechanism for sender-side and receiver-side enforcement. A domain can require TLS for all incoming deliveries by publishing an MTA-STS policy and configuring its mail server accordingly. DMARCFlow monitors whether sending domains are meeting their MTA-STS requirements.

Does DMARC require TLS?
No. DMARC operates at the domain authentication level, checking SPF and DKIM alignment. It does not specify transport encryption requirements.