STARTTLS
STARTTLS is the SMTP command that upgrades a plain connection to an encrypted one. The receiving server advertises support, the sender asks to upgrade, and the rest of the session runs over TLS. Because the offer travels in the clear and the fallback is to continue unencrypted, an attacker in the path can strip it, which is the problem MTA-STS was designed to solve.
At a glance
- Category
- Transport security
- Upgrades
- An existing plain SMTP connection to TLS
- Advertised in
- The receiving server's reply to EHLO
- Opportunistic
- Yes — the default behaviour is to continue without it
- Weakness
- The offer can be stripped by anyone in the path
- Specified in
- RFC 3207
How it works
The sending server opens a plain connection and greets the receiver, which lists the extensions it supports. If STARTTLS is among them, the sender issues the command, the two negotiate TLS, and the session restarts inside the encrypted channel — the earlier greeting is discarded and re-sent. Everything from that point, including the envelope and the message, is encrypted in transit. If the extension is not offered, the default behaviour for server-to-server mail is to carry on in the clear.
Why it matters
Almost all mail between large providers is now encrypted this way, which is a genuine improvement over the protocol's original design. The weakness is structural rather than cryptographic: because the offer is made over a plain connection, anyone in the path can remove it from the reply and both ends will quietly fall back. That is why declaring the requirement out of band, through MTA-STS or DANE, is what turns opportunistic encryption into a guarantee. Without one of those, a domain can only say that its mail is usually encrypted, which is a weaker claim than most people assume they are making.
Example
A sending server connects to a receiving host and sees STARTTLS in the advertised extensions. It upgrades, verifies the certificate, and delivers the message inside the encrypted session. On a different route, an intermediary strips the extension from the reply. Without a published policy the sender simply delivers in the clear; with a policy in enforce mode it refuses to deliver at all, and the failure is visible rather than silent.
Common mistakes
- 01Assuming a delivered message was encrypted, when the connection may have fallen back without either side objecting.
- 02Serving an expired or mismatched certificate, which makes strict senders refuse rather than downgrade.
- 03Turning on strict transport requirements without first confirming every receiving host presents a valid certificate.
- 04Confusing this with encrypting the message itself, which is a different problem solved by end-to-end encryption.
Related terms
Frequently asked questions
Is STARTTLS the same as end-to-end encryption?
No. It protects the message while it moves between two servers, and each server sees the plain content. End-to-end encryption keeps the content unreadable to every intermediate system.
How do I know whether my mail was sent over TLS?
Most mail clients show a transport indicator on a message, and TLS reporting gives a domain operator aggregate figures. A single delivery event does not tell you on its own.
Should I require TLS for all outbound mail?
Requiring it unconditionally will lose mail to the minority of hosts that still do not support it. Publishing MTA-STS for inbound and honouring other domains' policies for outbound is the practical position.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.