What is TLS/STARTTLS in email?
SendStreak AcademyTransport Layer Security (TLS) is the encryption protocol that protects email as it travels between servers. When applied to SMTP, TLS ensures that the message content, headers, and authentication credentials cannot be read or tampered with by anyone intercepting the network traffic.
There are two ways TLS is used in email: implicit TLS (the connection starts encrypted) and STARTTLS (the connection starts in plaintext and upgrades to encrypted). Both achieve the same end result - an encrypted connection - but they work differently and use different ports.
STARTTLS: upgrading a plaintext connection
STARTTLS is an SMTP extension defined in RFC 3207 that allows a plaintext SMTP connection to be upgraded to an encrypted one. The process works like this:
- The client connects to the server on port 587 (the standard submission port). The connection is initially unencrypted.
- The server responds with a
220greeting. - The client sends
EHLO, and the server replies with its list of supported extensions - including250-STARTTLSif it supports the upgrade. - The client sends the
STARTTLScommand. - The server responds with
220 Ready to start TLS. - Both sides perform a TLS handshake, negotiating cipher suites and exchanging certificates.
- From this point on, the connection is encrypted. The client proceeds with
AUTH,MAIL FROM, and the rest of the SMTP conversation over the encrypted channel.
The key detail: credentials and message content are never sent before the TLS upgrade. A well-implemented client will refuse to authenticate if STARTTLS fails.
Implicit TLS: encrypted from the start
Implicit TLS (also called SMTPS) skips the upgrade step entirely. The client connects to the server on a port that requires TLS from the first byte - there is no plaintext phase.
- The client opens a TLS connection to port 465.
- The TLS handshake happens immediately, before any SMTP commands.
- Once the encrypted connection is established, the SMTP conversation proceeds normally (
EHLO,AUTH,MAIL FROM, etc.).
Port 465 was originally assigned for SMTPS in the 1990s, then deprecated in favor of STARTTLS on port 587, and later reintroduced as the recommended submission port in RFC 8314 (2018). Both approaches are widely supported today.
Which port and method to use
| Port | Method | When to use |
|---|---|---|
| 587 | STARTTLS | Most widely supported. The standard choice for application-to-server email submission. |
| 465 | Implicit TLS | Also widely supported. Avoids the STARTTLS upgrade step, which eliminates certain downgrade attacks. |
| 25 | STARTTLS (optional) | Server-to-server relay only. Not for application use - blocked by most cloud providers and ISPs. |
For applications sending transactional email, either port 587 or 465 works. Most SMTP libraries default to port 587 with STARTTLS. If your provider supports both, port 465 with implicit TLS is slightly more secure because there is no window where the connection is unencrypted.
STARTTLS vs. implicit TLS: security considerations
STARTTLS is vulnerable to downgrade attacks in its opportunistic form. If a man-in-the-middle attacker strips the STARTTLS capability from the server’s EHLO response, the client may proceed without encryption - sending credentials and message content in plaintext. This is called a STARTTLS stripping attack.
Implicit TLS does not have this vulnerability because the connection is encrypted before any SMTP data is exchanged. There is no plaintext phase to intercept.
In practice, the risk depends on context:
- Client-to-server (your app to your SMTP provider): The connection usually goes over the public internet, but you control which server you connect to and can enforce TLS in your code. Most SMTP libraries let you require TLS and reject unencrypted connections.
- Server-to-server (relay between mail servers): STARTTLS is the only option here (port 25), and it is often opportunistic. Protocols like MTA-STS and DANE add enforcement by letting the receiving domain declare that it requires TLS, but adoption is still limited.
TLS in SMTP libraries
Most SMTP libraries use a secure or tls parameter to control encryption. Here is how the two modes map to common libraries:
Port 587 with STARTTLS (Nodemailer):
const transporter = nodemailer.createTransport({
host: 'smtp.example.com',
port: 587,
secure: false, // STARTTLS - starts plaintext, then upgrades
auth: { user: '...', pass: '...' }
});
Port 465 with implicit TLS (Nodemailer):
const transporter = nodemailer.createTransport({
host: 'smtp.example.com',
port: 465,
secure: true, // Implicit TLS - encrypted from the start
auth: { user: '...', pass: '...' }
});
The secure: false setting in Nodemailer is counterintuitive - it does not mean the connection is unencrypted. It means the connection starts unencrypted and upgrades via STARTTLS. The final connection is fully encrypted either way.
TLS versions
Modern email servers support TLS 1.2 and TLS 1.3. Older versions (TLS 1.0, TLS 1.1, and SSL 3.0) have known vulnerabilities and are deprecated. Most major providers - including Gmail, Outlook, and Amazon SES - require TLS 1.2 or higher for SMTP connections.
If you encounter connection errors with a mail server, check that your SMTP library or runtime supports TLS 1.2. Older Node.js versions (before 12.x) default to TLS 1.0 as the minimum version. For Python, TLS version support depends on the underlying OpenSSL library - ensure your system has OpenSSL 1.0.1 or later.
How TLS relates to email authentication
TLS encrypts the transport layer - the connection between two servers. It does not authenticate the sender’s identity or verify that the message content is legitimate. That is the job of SPF, DKIM, and DMARC.
Think of it this way: TLS protects the message while it is in transit (like a sealed envelope), while SPF, DKIM, and DMARC verify who sent it and whether the content was tampered with (like a return address and a wax seal). You need both for secure and trustworthy email delivery.
TLS status is recorded in the email headers in the Received lines. Each hop shows whether the connection used TLS, which helps when debugging delivery issues.
Related reading
- What is SMTP? - The protocol that TLS encrypts during email transmission.
- SMTP, IMAP, and POP3 explained - How the three email protocols handle encryption differently.
- The anatomy of email headers - See how TLS status appears in Received headers.
- How to send transactional emails with Gmail - A practical example using STARTTLS on port 587 with Gmail’s SMTP server.