Blog · Dmarc
How Many MX Servers Actually Refuse Non-TLS Mail
Someone tested every MX server that accepts mail on the internet. The result: out of 366,215 servers, only 0.2% refuse to accept mail that arrives without TLS encryption. That works out to roughly 730 servers.
The question that follows is whether enforcing TLS is worth the setup effort.
What the data means
The measurement was straightforward. Someone connected to every publicly reachable MX server and tried to send mail without using STARTTLS. Most servers accepted the unencrypted connection. A small fraction closed the connection instead.
The 0.2% is a floor, not a ceiling. The measurement reflects what servers do right now. As MTA-STS adoption grows, servers that currently accept unencrypted mail may start rejecting it to comply with stricter sender policies.
For most domains, the practical risk is not that a large fraction of incoming mail will be rejected. The risk is that sensitive mail travels unencrypted when it does not have to. If you handle healthcare data, financial records, or authentication tokens over email, unencrypted transit is a genuine gap even if only a small percentage of servers enforce TLS today.
Why 0.2% still matters
730 servers sounds small. But consider what happens in a forwarding chain.
When an email is forwarded through intermediate mail servers, each hop can be treated differently by the receiving MTA. A server that enforces TLS will reject mail from a forwarder that delivers unencrypted. If your users forward mail to external addresses, you may already be hitting these servers without knowing it.
There is also a signaling effect. Domains that publish an MTA-STS policy telling senders "we require TLS" make a clear statement. Senders that care about deliverability notice. Over time, enforcement becomes the norm rather than the exception.
What MTA-STS is
MTA-STS (Mail Transfer Agent Strict Transport Security) is a protocol that lets a domain tell receiving mail servers: deliver mail to us only over an encrypted TLS connection.
It works in two parts. First, a DNS TXT record publishes the existence of an MTA-STS policy. Second, a policy file hosted at mta-sts.domain.com specifies the TLS requirements and how long to cache the policy.
When a sending MTA encounters your domain for the first time, it checks your DNS for the TXT record, fetches the policy file over HTTPS, and caches the result for the period you specify. From that point on, it will refuse to deliver mail over an unencrypted connection unless your policy allows testing mode.
MTA-STS also supports TLS-RPT (TLS Reporting). This is an optional add-on that sends you XML reports whenever a sending server fails to connect over TLS. You get visibility into who is trying to send you mail without encryption.
MTA-STS does not require DNSSEC. That is its main practical advantage. You can deploy it today without changing your DNS infrastructure beyond adding two records.
What DANE is
DANE (DNS-based Authentication of Named Entities) takes a different approach. Instead of telling senders "please use TLS," it uses DNSSEC to cryptographically bind your TLS certificate to your DNS records.
The sending MTA checks a TLSA record you publish in DNS. That record says which certificate or certificate authority is valid for your mail server. If the certificate presented during the SMTP handshake does not match what the TLSA record says it should be, the connection is rejected.
The difference from MTA-STS is important. MTA-STS lets senders decide whether to enforce TLS. DANE makes the decision for them by rejecting anything that does not match the TLSA record, even if a valid certificate authority issued it. This makes DANE stronger against certificate fraud but also more brittle when certificate rotation is not carefully managed.
DANE only works if your domain has DNSSEC signatures deployed. If a receiving server cannot verify your DNSSEC records, it cannot use DANE validation. In practice, DANE works best between domains where both parties have strong DNSSEC coverage, such as within government or research networks.
MTA-STS vs DANE
| Feature | MTA-STS | DANE |
|---|---|---|
| DNSSSEC required | No | Yes |
| Deployment complexity | Low | High |
| Sends failure reports | Yes (TLS-RPT) | No |
| Certificate validation | Optional | Mandatory |
| SMTP client support | Growing | Limited |
| Cache policy | Yes (max-age) | No |
| Rollback risk | Yes (testing mode available) | No |
For most organizations, MTA-STS is the practical choice. You can deploy it without DNSSSEC, get failure reports via TLS-RPT, and ease into enforcement with testing mode. DANE makes sense only if you run a high-security environment with full DNSSSEC control and want the stronger cryptographic guarantee.
Both protocols can run together without conflict.
Should you enforce TLS for your mail server
If you receive sensitive mail and want to reduce the risk of eavesdropping in transit, MTA-STS is worth deploying. The setup takes under an hour and does not require any changes to your mail flow.
The risk of enforcing TLS is low. You may see a small number of delivery failures initially, mostly from automated systems that still use unencrypted SMTP. TLS-RPT reports will show you exactly which senders are failing so you can investigate.
If you send transactional mail, publishing your own MTA-STS policy tells receivers you expect encrypted connections. Combined with SPF, DKIM, and DMARC, this completes a four-layer email authentication posture that covers identity verification, encryption, and policy enforcement.
How to check your current TLS enforcement status
If you want to test whether your domain is currently enforcing TLS for incoming mail, DMARCFlow offers a free MTA-STS checker at dmarcflow.com/mta-sts-checker. Enter your domain and the tool reports whether your MTA-STS policy is valid, whether TLS enforcement is active, and what mode it is running in.
This matters for your overall email authentication setup because TLS failures can cause silent mail drops that DMARC alone cannot detect. When a sending server cannot deliver over TLS and your domain does not have an MTA-STS policy, the sender may silently fall back to unencrypted delivery or give up entirely. The TLS-RPT reports tied to your MTA-STS policy give you visibility into these events.
You can also use the TLS-RPT checker at dmarcflow.com/tls-rpt-checker to verify your TLS reporting configuration is receiving failure reports correctly. Both tools are free and do not require an account.
FAQ
What percentage of mail servers enforce TLS?
Based on a measurement of 366,215 publicly accessible MX servers, approximately 0.2% actively refuse non-TLS connections. This number is a floor and is likely to grow as MTA-STS adoption increases.
Is MTA-STS better than DANE?
MTA-STS is easier to deploy and works without DNSSSEC. DANE is cryptographically stronger but requires full DNSSSEC deployment, which limits its practical usefulness outside high-security environments. For most organizations, MTA-STS is the better choice.
Does enforcing TLS break mail delivery?
Enforcing TLS may cause temporary delivery failures with senders that still use unencrypted SMTP. TLS-RPT reports show you which senders are failing so you can address the issue. In practice, the affected fraction is very small.
Can I use both MTA-STS and DANE?
Yes. Both protocols can coexist. MTA-STS covers most sending servers, and DANE adds cryptographic certificate validation for senders that support it.
What is the minimum TLS version MTA-STS requires?
MTA-STS does not mandate a minimum TLS version in the base specification, but best practice is to require TLS 1.2 or higher. You can set this in your MTA-STS policy file.