RFC 3207 – SMTP STARTTLS Extension

Proposed Standard Transport Security Obsoletes RFC 2487 Published February 2002

ELI5: Imagine you’re having a conversation in a crowded room. Anyone can listen in. STARTTLS is like saying “let’s step into a private room” mid-conversation. You start the SMTP session in plaintext, then both sides agree to switch to encrypted communication before any sensitive content is exchanged. After that, nobody can eavesdrop on the email being transferred.

Why This RFC Exists

When SMTP was designed in 1982, encryption wasn't a consideration. Messages traveled across the internet in plaintext, and anyone with access to the network path could read them. As the internet became more hostile, encrypting email in transit became essential.

RFC 3207 defines the STARTTLS extension for SMTP, allowing a plaintext SMTP connection to be upgraded to an encrypted TLS connection. Published in 2002, it replaced RFC 2487 with clarifications on security considerations and server behavior.

STARTTLS is the dominant mechanism for encrypting server-to-server (MTA-to-MTA) email traffic on port 25. For client-to-server submission, RFC 8314 now recommends implicit TLS on port 465, but STARTTLS on port 587 remains widely used.

How It Works

STARTTLS works as an SMTP extension, negotiated during the EHLO exchange:

The client connects to the server on port 25 (or 587) in plaintext.
The client sends EHLO. The server responds with its capabilities, including 250-STARTTLS if it supports encryption.
The client sends STARTTLS.
The server responds with 220 Ready to start TLS.
Both sides perform a TLS handshake, establishing an encrypted channel.
The client sends a new EHLO over the encrypted connection. The server's capability list may change (e.g., AUTH is now advertised).
The SMTP session continues normally, but all traffic is now encrypted.

SMTP Example

STARTTLS negotiation during a server-to-server transfer:

# Plaintext connection established on port 25 S: 220 mx.example.com ESMTP C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-STARTTLS S: 250 ENHANCEDSTATUSCODES # Client sees STARTTLS is available, requests upgrade C: STARTTLS S: 220 2.0.0 Ready to start TLS # --- TLS handshake occurs here --- # All subsequent traffic is encrypted # Client MUST re-issue EHLO after TLS C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-AUTH PLAIN LOGIN S: 250 ENHANCEDSTATUSCODES # Note: STARTTLS no longer advertised (already active) # Note: AUTH now advertised (only available after TLS) C: MAIL FROM:<alice@sender.example.net> S: 250 2.1.0 OK C: RCPT TO:<bob@example.com> S: 250 2.1.5 OK C: DATA S: 354 Start mail input C: [message content...] C: . S: 250 2.0.0 OK

Key Technical Details

Opportunistic vs. Mandatory TLS

The critical limitation of STARTTLS as defined in RFC 3207 is that it's opportunistic by default:

Opportunistic TLS: The client attempts STARTTLS if the server advertises it, but falls back to plaintext if it's not available or if the TLS handshake fails. This is the default behavior for MTA-to-MTA connections.
Mandatory TLS: The client refuses to send the message unless TLS can be established. This can be configured per-domain or enforced using MTA-STS (RFC 8461) or DANE (RFC 7672).

Opportunistic TLS is vulnerable to downgrade attacks: a network attacker can strip the STARTTLS capability from the EHLO response, forcing the connection to remain in plaintext. The client has no way to know the server supports TLS because the initial negotiation happens in plaintext.

Certificate Verification

RFC 3207 does not require strict certificate verification for MTA-to-MTA connections. In practice, many servers use self-signed certificates or certificates that don't match the MX hostname. The rationale: opportunistic encryption with no verification is still better than no encryption at all. It protects against passive surveillance even if it doesn't prevent active man-in-the-middle attacks.

For stronger guarantees, use:

DANE (RFC 7672) — publishes the server's TLS certificate in DNS via TLSA records, secured by DNSSEC.
MTA-STS (RFC 8461) — publishes a policy requiring TLS with certificate validation, cached by sending servers.

Re-EHLO After STARTTLS

After the TLS handshake completes, the client MUST issue a new EHLO command. The server's capability list from before TLS must be discarded. This is important because:

The server may advertise different capabilities after encryption is established (e.g., AUTH).
The server should no longer advertise STARTTLS since encryption is already active.
An attacker could have modified the pre-TLS EHLO response.

STARTTLS on Different Ports

Port	Protocol	TLS Behavior
25	SMTP relay	STARTTLS (opportunistic for MTA-to-MTA)
587	Submission	STARTTLS (effectively mandatory — AUTH requires it)
465	Submission	Implicit TLS (TLS handshake before any SMTP commands)

TLS Reporting

RFC 8460 defines SMTP TLS Reporting (TLSRPT), which allows domain owners to receive reports about TLS connection failures. This is the STARTTLS equivalent of DMARC aggregate reports — it tells you when connections to your servers are failing TLS negotiation.

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Common Mistakes

Assuming STARTTLS means the message is encrypted end-to-end. STARTTLS only encrypts the connection between two adjacent servers. If a message passes through multiple hops, each hop negotiates TLS independently. A message could be encrypted for one hop and plaintext for the next.
Not re-issuing EHLO after STARTTLS. Failing to send a new EHLO after the TLS handshake is a protocol violation. You'll be working with stale capability data and may miss newly available features like AUTH.
Treating STARTTLS failure as a permanent error. If STARTTLS negotiation fails, the connection is in an undefined state. Close the connection and start a new one. Don't try to continue with plaintext on the same connection.
Advertising STARTTLS but using an expired or misconfigured certificate. While many clients will proceed despite certificate errors, some increasingly strict clients (and MTA-STS/DANE policies) will refuse. Keep your TLS certificates valid and properly configured.
Relying solely on STARTTLS for security. Because STARTTLS is opportunistic and vulnerable to downgrade attacks, it should be complemented with MTA-STS or DANE for domains where encryption is critical.
Forgetting STARTTLS on port 587. For submission, clients should always STARTTLS before authenticating. Sending AUTH credentials in plaintext exposes your SMTP password to anyone monitoring the connection.

Deliverability Impact

Google and major providers flag unencrypted mail. Gmail displays a red open-lock icon for messages received without TLS encryption. This signals to recipients that the message may have been intercepted in transit, reducing trust.
TLS adoption is nearly universal. As of 2025, over 95% of email sent to Gmail is encrypted with TLS. Not supporting STARTTLS on your sending infrastructure makes you an outlier and can negatively affect your sender reputation.
MTA-STS enforcement is growing. Major providers publish MTA-STS policies that require TLS with certificate validation. If your sending server can't successfully negotiate TLS with a valid certificate, delivery to these domains will fail.
TLS reporting exposes issues. If you publish a TLSRPT record and your server has TLS issues, you'll receive reports. If you don't publish TLSRPT, you're flying blind about connection failures.
Compliance requirements. HIPAA, GDPR, PCI-DSS, and other regulations increasingly require encryption in transit for email. STARTTLS is the baseline mechanism that satisfies this requirement for server-to-server email.