How it works
After the client's EHLO, a mail server lists its capabilities. If STARTTLS is among them, the client can send the STARTTLS command to start a TLS handshake, and the rest of the session, including sender, recipients and content, is encrypted. This works between mail servers on port 25, for mail clients on port 587, and in the same way for IMAP and POP3.
Between mail servers, STARTTLS is opportunistic. If the receiving server doesn't offer it or the handshake fails, the sender usually delivers in plain text. It rarely validates the certificate either, because without a policy it has no idea which name to expect. Only MTA-STS or DANE make TLS mandatory and define which certificate counts as valid.
For mail clients there is also implicit TLS on port 465, where the connection is encrypted from the first byte; RFC 8314 recommends it for submission. Between mail servers, STARTTLS on port 25 remains the standard.
Why it matters
Because the capability list travels in plain text, an attacker on the network path can simply delete the STARTTLS line from the response. The sender concludes the receiver can't do TLS, and the message crosses the wire in readable form. Without MTA-STS or DANE, the sender has no way to detect this STARTTLS stripping.
If your mail server stops offering STARTTLS altogether, say after an update with a broken configuration, all inbound mail reaches you unencrypted. Senders using MTA-STS in enforce mode or DANE stop delivering entirely.
How to prevent it
- Enable STARTTLS on every MX host and install a valid certificate from a public CA whose names include the MX host name.
- Offer at least TLS 1.2 and disable TLS 1.0 and 1.1.
- For mail clients, offer port 465 with implicit TLS or port 587 with mandatory STARTTLS, and block logins without TLS.
- Set up MTA-STS or DANE so senders notice STARTTLS stripping instead of falling back to plain text.
- After updates and certificate changes, confirm that the server still advertises STARTTLS.
How DomainWarn detects it
The SMTP check connects to up to five MX hosts on port 25, sends EHLO, checks whether STARTTLS is offered and completes the handshake; it never submits a message. If STARTTLS is missing or the negotiation fails, DomainWarn opens a “Mail server without STARTTLS” incident. If a server that used to offer STARTTLS drops it, you also get the critical change “STARTTLS removed from mail server”. The SMTP check only runs if port 25 is enabled for the probe servers.
For submission, you can point the Certificate check at the mail server's host name on port 587, or at IMAP on port 143; it then connects via STARTTLS and checks the certificate and protocol. DomainWarn cannot observe STARTTLS stripping on someone else's network path; MTA-STS and DANE guard against that, and the checks of the same name verify their setup.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.