- STARTTLS, defined
- STARTTLS is an SMTP command that upgrades an existing plain-text connection to an encrypted one, which is how nearly all mail between servers is protected in transit.
The receiving server advertises STARTTLS in its EHLO response. The sender issues the command, both negotiate TLS, and the conversation restarts inside the encrypted channel.
Its weakness is that failure is silent. Remove the advertisement in transit and a sender with no policy simply proceeds unencrypted, with nothing logged and nobody alerted.
MTA-STS and DANE both exist to close that hole, by letting a domain state out of band that encryption is required. The command itself stays the same; what changes is whether a sender may fall back.
Certificate validation is loose by default in mail transfer. Many servers accept self-signed certificates rather than bounce the message, which trades authentication for delivery on purpose.
How ZapBounce reports it
Our probes negotiate STARTTLS where the server offers it, though it makes no difference to the verdict since no message content is ever transmitted. The free TLS checker reports what a domain's MX hosts offer and whether their certificates validate.
Watching the upgrade happen with openssl
You can test any mail host from a terminal where port 25 is open. Run openssl s_client -starttls smtp -connect mx1.acme.example:25. The tool connects in plain text, sends EHLO, checks for 250-STARTTLS in the reply, issues the STARTTLS command, and waits for 220 2.0.0 Ready to start TLS before negotiating.
What prints next is the part you care about. Look for the protocol line, which should say TLSv1.2 or TLSv1.3. Then read the certificate's subject and its alternative names, and check that one of them matches the MX hostname you connected to. Note the expiry date, and the last line of the verification block, which reads Verify return code: 0 (ok) when the chain is trusted.
If the certificate is for server42.hostingco.example and your MX is mx1.acme.example, most senders will deliver to you anyway. A sender that enforces your MTA-STS policy will not.
Proof of encryption on mail you've already received
Every delivered message records how it traveled. Open the raw source and read the Received headers from the bottom up. Hops that used TLS usually say so, with text like (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384). A hop with no such note may have crossed the network unencrypted.
Gmail surfaces the same fact to ordinary users. A message that arrived without TLS shows a red open padlock beside the sender's name, and Google's sender requirements expect bulk mail to be sent over TLS.
For your own domain's inbound side, TLS reporting gives you ongoing visibility. Publish a TXT record at _smtp._tls.acme.example reading v=TLSRPTv1; rua=mailto:tlsreports@acme.example, and participating senders email you a daily JSON summary of successful and failed TLS sessions. That's defined in RFC 8460. It's the only practical way to learn that a sender tried to reach you securely and couldn't, because those failures happen on somebody else's server and never appear in your own logs.
STARTTLS: common questions
Is STARTTLS the same as TLS?
STARTTLS is the command that starts TLS on an existing plain connection. Implicit TLS, on port 465, is encrypted from the first byte.
Can STARTTLS be stripped?
Yes. An attacker in the path removes the advertisement and the sender proceeds unencrypted. MTA-STS and DANE prevent that fallback.
Do mail servers check certificates?
Often not strictly. Many accept self-signed certificates rather than reject the message, unless a policy requires otherwise.