Send an email today and you can be fairly sure it travels encrypted. Between the large providers, practically all traffic runs over TLS. What tends to be overlooked: that encryption is a courtesy, not a condition. It can be switched off from the outside, and in the default configuration nobody notices.
Why SMTP encryption is allowed to give way
SMTP is older than the encryption it uses today. That was added afterwards, through a command called STARTTLS: on first contact the receiving server lists its capabilities, among them — perhaps — STARTTLS. The sender takes the offer up if it is there.
Two properties follow from that ordering, and together they are the whole problem:
- The negotiation happens in the clear. Whoever controls the connection can simply delete the line carrying the offer. The sender then sees a server that cannot do TLS — and delivers in plain text, because the alternative would be not delivering at all.
- Certificates are not validated by default. On the web a browser stops at a bad certificate. In server-to-server SMTP almost anything is accepted: expired, self-signed, issued to an entirely different name. The connection is encrypted, but nobody checked with whom.
This leniency was deliberate. When TLS was introduced most servers could not do it, and a strict rule would have taken delivery apart. The price is that the encryption disappears precisely when somebody has an active interest in it disappearing.
MTA-STS: the policy over HTTPS
MTA-STS closes the gap using something that is already everywhere: a web server with a valid certificate. The domain publishes two things.
A DNS record at _mta-sts.company.com, which only states that a policy exists and carries a version identifier:
_mta-sts.company.com. TXT "v=STSv1; id=20260903120000"The policy itself, retrievable at a fixed address, https://mta-sts.company.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.company.com
mx: mail2.company.com
max_age: 604800The sending server fetches this file over HTTPS — that is, over a connection with real certificate validation — and remembers it for the stated period. From then on the rule is: this recipient supports TLS, its certificate must carry one of the listed names, and if either fails, nothing is delivered.
The attacker in the diagram can still tamper with the SMTP connection. There is simply nothing left to gain by it, because the sender already knows what to expect.
The mode is the decisive part. testing only reports violations, enforce refuses. The route runs through testing until the reports are clean — otherwise you switch off your own inbound mail.
DANE: the policy in DNS
DANE solves the same problem differently. Instead of a file on a web server, the fingerprint of the expected certificate sits directly in DNS, as a TLSA record beside the MX name:
_25._tcp.mail.company.com. TLSA 3 1 1 <key fingerprint>That entry binds the connection to exactly this key. A different certificate, no matter which authority issued it, is refused.
This works under one condition only: the zone has to be signed with DNSSEC. Without it, the TLSA record could be forged the same way as anything else in DNS and the whole exercise would be pointless. There is no DANE without DNSSEC — that is not a recommendation but a prerequisite.
The two compared
| MTA-STS | DANE | |
|---|---|---|
| Trust anchor | certificate authorities, as in a browser | DNSSEC |
| Retrieved over | HTTPS, plus one DNS record | DNS only |
| Prerequisite | web server with a valid certificate | signed zone |
| First connection | unprotected until the policy is fetched | protected from the first connection |
| Caching | yes, until max_age expires | no, the DNS lifetime applies |
| Typical failure | expired web certificate, forgotten id | key rotation without a new TLSA record |
The two do not exclude each other. Publish both and you are covered by every sender that speaks either one — together considerably more than by each alone.
The unglamorous part: the reports
Both mechanisms fail silently. If a connection aborts because a certificate expired, the message stays in the sender's queue — you hear nothing about it until somebody asks why no mail is arriving.
The answer to that is TLS-RPT, one more DNS record:
_smtp._tls.company.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@company.com"Sending servers then deliver a daily summary: how many connections succeeded, how many failed and why. This is the part most likely to be left out and most likely to be needed. A policy without a feedback channel is a trap that eventually springs.
What this does not do
Both mechanisms secure the transport between two servers. At the destination the message lies unencrypted again, the operator of the destination server can read it, and neither says anything about the second and third hop. Anyone wanting to keep content from the provider needs encryption that covers the whole route — how those mechanisms differ, and why email is not end-to-end encrypted by default, is covered in a separate article.
MTA-STS and DANE solve a narrower problem, and they solve it well: they take away an attacker's ability to make encryption disappear by mere interference.