SMTP STARTTLS is the mechanism that allows a plain text SMTP connection to be upgraded to an encrypted TLS connection on the fly.
Let’s watch it happen.
Imagine you’re sending an email from sender@example.com to recipient@example.org using a client like mutt or thunderbird.
# This is what you'd see if you ran `openssl s_client -connect smtp.example.com:25`
# and then typed `EHLO mail.sender.com`
220 smtp.example.com ESMTP Postfix
EHLO mail.sender.com
250-smtp.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
STARTTLS
220 2.0.0 Ready to start TLS
# Now, the client and server negotiate TLS.
# After successful negotiation, the EHLO command is sent again,
# and the server will list different capabilities, including those
# only available over TLS, like AUTH TLS-PLAINTEXT or AUTH LOGIN.
EHLO mail.sender.com
250-smtp.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:<sender@example.com>
250 2.1.0 Ok
RCPT TO:<recipient@example.org>
250 2.1.5 Ok
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Subject: Test Email
This is the body of the email.
.
250 2.0.0 Ok: queued as ABC123XYZ
QUIT
221 2.0.0 Bye
The magic is in that STARTTLS command. The client, upon seeing STARTTLS listed in the server’s EHLO response, sends the STARTTLS command. The server responds with 220 2.0.0 Ready to start TLS. At this point, the existing TCP connection is torn down and a new TLS handshake begins over the same TCP connection. Once the handshake is complete, the client sends EHLO again. This time, the server’s response might differ, indicating that TLS is now active and potentially enabling additional authentication mechanisms or features only available over a secure channel.
The problem STARTTLS solves is bridging the gap between the vast installed base of SMTP servers and clients that were designed without encryption in mind, and the modern necessity of securing email transport. Instead of requiring all servers to switch to a different port (like SMTPS on port 587 or 465), STARTTLS allows for a graceful upgrade path on the standard SMTP port (25 or 587). This means an older client that doesn’t support STARTTLS will still be able to connect and send mail (unencrypted), while a newer client can negotiate an encrypted session if the server supports it.
Internally, the STARTTLS command triggers a sequence of TLS handshake messages. The client initiates by sending ClientHello, followed by the server’s ServerHello, certificate exchange, key exchange, and finally a Finished message from both sides. After this, the communication channel is encrypted using the negotiated cipher suite. The critical part is that the SMTP protocol itself is not restarted; it’s merely layered over the established TLS tunnel. This is why the EHLO command is typically sent twice: once before the TLS handshake to discover capabilities, and again after to see the new set of capabilities available over the encrypted connection.
The exact levers you control are primarily in your SMTP server’s configuration and your client’s settings. For Postfix, you’d configure smtpd_tls_security_level = may (to advertise STARTTLS but not require it) or smtpd_tls_security_level = encrypt (to require STARTTLS). You also need to ensure you have a valid certificate and private key specified in smtpd_tls_cert_file and smtpd_tls_key_file. Client-side, most mail clients have a checkbox or setting for "Use TLS/SSL" or "StartTLS" when configuring an outgoing mail server, usually associated with a specific port.
The most surprising thing about STARTTLS is that it’s not a distinct protocol or a different port; it’s a command that transitions an existing, unencrypted SMTP connection into an encrypted one. This means that while the data transmitted after the STARTTLS command is encrypted, the initial EHLO negotiation, including the announcement of STARTTLS itself, is sent in plain text. This is a crucial detail for understanding potential vulnerabilities like downgrade attacks or passive eavesdropping on the initial handshake.
The next concept you’ll likely encounter is how to properly configure authentication mechanisms that are only enabled after a STARTTLS handshake, ensuring that users are not sending credentials over an unencrypted channel.