STARTTLS: how it works and how it differs from implicit TLS

STARTTLS is a command that upgrades an already-open, plaintext TCP connection to TLS. It applies to three mail protocols: SMTP (RFC 3207), IMAP (RFC 2595), and POP3 (RFC 2595, where the command is named STLS). The name means exactly what it says: "start TLS." The client and server perform a TLS handshake on top of the current connection, and everything after that travels over an encrypted channel.

STARTTLS is not a separate protocol. It is an extension to existing protocols that adds encryption without needing a dedicated port for it.

Step-by-step: SMTP on port 25

Here is what a server-to-server connection looks like:

1. The sending MTA opens a TCP connection to the receiving server. No encryption yet.
2. The receiving server sends its greeting: 220 mx.example.com ESMTP.
3. The sending MTA sends EHLO and gets back a list of supported extensions. One of them is 250-STARTTLS.
4. The sending MTA issues the STARTTLS command.
5. The server replies 220 Ready to start TLS.
6. Both sides do the TLS handshake: certificates are exchanged, a cipher suite is negotiated (e.g. TLS_AES_256_GCM_SHA384), and session keys are derived.
7. Once the handshake completes, the client sends EHLO again, this time over the encrypted channel. The rest of the session — MAIL FROM, RCPT TO, DATA — all travels encrypted.

STARTTLS in IMAP and POP3

For IMAP (port 143), the client sends a001 STARTTLS. The server responds a001 OK Begin TLS negotiation, then the handshake begins. Authentication via LOGIN or AUTHENTICATE happens only after the secure channel is up.

In POP3 (port 110) the command is STLS. The mechanics are the same: the server confirms readiness, the handshake runs, and then USER and PASS go over the encrypted channel.

STARTTLS vs implicit TLS

• STARTTLS (explicit TLS). The connection starts in plaintext on a standard port (25, 587, 143, or 110). Encryption kicks in after a few plaintext exchanges. There is a window between TCP establishment and the TLS handshake where data is unprotected.
• Implicit TLS. Encryption starts immediately when the connection opens, before any application data. Dedicated ports: 465 (SMTP submission), 993 (IMAPS), 995 (POP3S). The client knows up front that TLS is required on that port.

RFC 8314 (2018) recommends implicit TLS for client-to-server connections (MUA to MTA) — ports 465, 993, 995. For server-to-server delivery (MTA to MTA, port 25), STARTTLS is the only option because implicit TLS on port 25 is not standardized.

Opportunistic vs mandatory STARTTLS

Most MTAs use opportunistic STARTTLS: if the receiving server advertises it, the sender encrypts; if not, the message goes out in the clear. This maximizes deliverability but does not guarantee encryption.

In mandatory (enforced) mode the sending server refuses delivery if TLS cannot be established. Stricter, but it can block legitimate mail from senders running older servers. In practice, mandatory STARTTLS shows up in enterprise setups where both sides control their own MTAs.

Downgrade attacks: the main weakness

Because the session opens in plaintext, an attacker on an intermediate network node (an ISP, a Wi-Fi access point, a compromised router) can strip TLS support in two ways:

• Stripping the advertisement. The attacker modifies the EHLO response and removes the 250-STARTTLS line. The sending MTA assumes the receiver does not support TLS and delivers in plaintext.
• Faking an error. The attacker intercepts the STARTTLS command and returns a fabricated error code (for example, 502 Command not implemented). The client falls back to plaintext.

In both cases the message still arrives. The user sees nothing wrong. Implicit TLS does not have this problem: if the handshake fails, no connection is established and no data moves.

MTA-STS and DANE

Two mechanisms close the downgrade gap:

• MTA-STS (RFC 8461): a domain publishes a policy over HTTPS declaring that its MX servers require TLS. Sending MTAs cache the policy (for the duration specified in max_age) and refuse to fall back to plaintext. TLS-RPT (RFC 8460) gives you a reporting channel for failed TLS connections.
• DANE (RFC 7672): uses DNSSEC-signed TLSA records to pin a TLS certificate to a DNS name. The sending MTA verifies both that TLS is present and that the certificate is genuine, via DNS. More robust than MTA-STS, but it requires DNSSEC on the sending domain.

Google, Microsoft, and Yahoo support MTA-STS checking. DANE is more common among European providers — notably in the Netherlands, Germany, and the Czech Republic, where DNSSEC has been deployed at the infrastructure level.

Postfix configuration

For incoming connections (receiving side):

The value may is opportunistic: the server offers STARTTLS but does not require it. Set it to encrypt to make TLS mandatory.

For outgoing connections (sending side):

In Dovecot (IMAP/POP3), ssl = yes offers STARTTLS; ssl = required makes it mandatory. The latter is the right choice for any server exposed to the internet.

STARTTLS and deliverability

According to Google Transparency Report, over 96% of inbound Gmail traffic traveled over TLS as of 2026. Google and Yahoo added TLS to their bulk-sender requirements in 2024. Gmail shows a red broken-lock icon on messages delivered without TLS.

For any sender, running an MTA without STARTTLS is a deliverability liability and a negative signal for spam filters. The fix is straightforward: a Let's Encrypt certificate takes a minute to issue, and the Postfix config is four lines.