Infrastructure

STARTTLS

Definition

STARTTLS is an SMTP extension, defined in RFC 3207, that upgrades a connection from plain text to encrypted TLS in the middle of the session. The connection starts unencrypted; if the receiver advertises STARTTLS in its EHLO reply, the sender issues the command and both sides negotiate TLS before any message is sent. It is the dominant way server-to-server email is encrypted in transit.

  • Upgrades an existing plain-text SMTP connection to encrypted TLS mid-session
  • Advertised as an EHLO capability; the client then issues STARTTLS
  • Usually opportunistic, so it quietly falls back to plain text if TLS is unavailable
  • Vulnerable to downgrade (stripping) attacks unless backed by MTA-STS or DANE
At a glance
Type SMTP extension
EHLO keyword STARTTLS
Defined in RFC 3207 (2002)
Ready reply 220 Ready to start TLS
Common ports 25 (relay) · 587 (submission)
Upgrades to TLS

How STARTTLS works

STARTTLS is not an encryption protocol; it is the SMTP command that switches on encryption. The connection opens in plain text on the usual ports. When the sender greets the receiver with EHLO and sees 250-STARTTLS in the reply, it knows the receiver can encrypt. The sender then issues the bare STARTTLS command, the server answers 220 Ready to start TLS, and both sides run a TLS handshake to set up an encrypted channel.

After the handshake the SMTP session resets to its initial state, so the client reissues EHLO over the now-encrypted connection and continues with MAIL FROM and the message. If the server cannot start TLS right then it replies 454, and a syntactically wrong command gets 501. This is why STARTTLS is called opportunistic encryption: it protects the session when both sides can, but the conversation begins in the clear.

A STARTTLS upgrade, line by line

The whole upgrade happens in three commands before the TLS handshake itself begins:

The client requests STARTTLS, the server accepts, and TLS begins 
C: EHLO mail.example.com
S: 250-mx.receiver.net at your service
S: 250 STARTTLS
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   ... TLS handshake negotiates the cipher and keys ...
C: EHLO mail.example.com        (reissued over the encrypted channel)

The downgrade-attack problem

Because the session opens in plain text, the STARTTLS capability is announced before anything is encrypted. A network attacker sitting in the middle can simply strip the 250-STARTTLS line from the EHLO reply, and the sender, seeing no TLS on offer, falls back to delivering the message unencrypted. Neither side gets an error. This stripping (or downgrade) attack is the core weakness of opportunistic STARTTLS.

Two standards close the gap by letting a domain require TLS. MTA-STS (RFC 8461) publishes a policy over HTTPS that tells senders to refuse plain-text delivery to your servers. DANE (RFC 7672) does the same through a DNSSEC-signed TLSA record. Either one turns opportunistic encryption into enforced encryption.

The STARTTLS upgrade handshake

The sender connects in plain text and sends EHLO
The receiver advertises 250-STARTTLS in its capability list
No STARTTLS line: stays plain text
The sender issues STARTTLS and the server replies 220 Ready to start TLS
Both sides run the TLS handshake and the channel is now encrypted
The sender reissues EHLO over TLS, then delivers the message

STARTTLS vs implicit TLS

STARTTLS (explicit) Implicit TLS
How it starts Plain text, then upgrades Encrypted from the first byte
Typical ports 25, 587 465 (submission)
Defined in RFC 3207 RFC 8314
Strippable? Yes, unless enforced No, no plain-text phase
Main use Server-to-server relay Client mail submission

By the numbers

220
The SMTP reply that means “Ready to start TLS” after the client issues the STARTTLS command.
454
The reply when the server cannot start TLS at that moment; 501 signals a malformed command.
RFC 8461
MTA-STS, the policy standard that lets a domain require TLS and defeat STARTTLS stripping.

Common mistakes

Assuming STARTTLS guarantees encryption
Opportunistic STARTTLS silently falls back to plain text when the capability is missing or stripped. If encryption is non-negotiable, layer on MTA-STS or DANE so delivery is refused rather than downgraded.
Confusing STARTTLS with a port
STARTTLS is a command, not a port. It commonly runs on 25 and 587, while port 465 uses implicit TLS that is encrypted from the start. Picking a port does not by itself decide whether or how encryption happens.
Presenting an invalid or expired certificate
Opportunistic senders often accept any certificate, but enforced setups validate it. An expired, self-signed, or mismatched certificate can cause MTA-STS or DANE senders to reject your inbound mail outright.
Leaving deprecated TLS versions enabled
STARTTLS is only as strong as the TLS it negotiates. Allowing TLS 1.0 or 1.1, deprecated by RFC 8996, weakens the channel. Require TLS 1.2 or 1.3.

Frequently asked questions

Is STARTTLS the same as TLS?
No. TLS is the encryption protocol; STARTTLS is the SMTP command that asks an existing plain-text connection to upgrade to TLS. STARTTLS triggers a TLS handshake but is not encryption in itself. The alternative is implicit TLS, where the connection is encrypted from the first byte with no plain-text phase.
Why is STARTTLS considered insecure?
On its own it is opportunistic: the session starts in plain text and advertises the STARTTLS option before anything is encrypted, so a network attacker can strip that advertisement and force the message through unencrypted, with no error on either side. MTA-STS (RFC 8461) and DANE (RFC 7672) fix this by letting a domain require TLS and refuse plain-text delivery.
What port does STARTTLS use?
STARTTLS is a command rather than a port, but it is most commonly used on port 25 for server-to-server relay and port 587 for mail submission. Port 465 is reserved for implicit TLS, which is encrypted from the start and does not use the STARTTLS upgrade.
What happens if STARTTLS fails?
If the server replies 454 (TLS temporarily unavailable) or the handshake fails, an opportunistic sender normally falls back to delivering in plain text. A sender bound by an MTA-STS or DANE policy instead defers or rejects the delivery rather than sending unencrypted.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← Back to glossary