SMTP TLS in Practice (STARTTLS, Implicit TLS, REQUIRETLS, version floors)

The KB's MTA-STS, DANE, and TLS-RPT articles cover the receiving-domain policy mechanisms. This article covers the layer underneath and the sender's side of it: how STARTTLS actually works on the wire, why mail defaults to opportunistic (unauthenticated, downgrade-tolerant) TLS, which ports and TLS versions apply where, and the mechanisms for making TLS mandatory per message (REQUIRETLS) or per protocol version (the TLS 1.0/1.1 deprecation).

STARTTLS mechanics (RFC 3207)

STARTTLS upgrades a cleartext SMTP session to TLS on the same port (25 for MTA-to-MTA relay, 587 for submission).

Wire sequence:

1. Client connects, server greets 220, client sends EHLO.
2. A TLS-capable server advertises the STARTTLS keyword (no parameters) in its EHLO response.
3. Client issues the bare command STARTTLS (no parameters allowed).
4. Server replies, then both sides begin the TLS handshake immediately after a 220.

Reply code	Meaning
220	Ready to start TLS — client MUST begin TLS negotiation immediately
501	Syntax error (parameters were supplied — none are allowed)
454	TLS not available due to temporary reason (retryable)
530	"Must issue a STARTTLS command first" — server requires TLS before other commands
554	Server refuses further SMTP commands because achieved security is insufficient

Post-handshake rules:

• The SMTP session resets to initial state (as if just after the 220 greeting). The server MUST discard all knowledge gained from the client pre-TLS (e.g., the EHLO argument); the client MUST discard the pre-TLS server capability list.
• The client SHOULD send a fresh EHLO; the advertised extension list MAY differ from the cleartext one.
• The server MUST NOT advertise STARTTLS in the post-handshake EHLO response, and the client MUST NOT issue STARTTLS when TLS is already active.
• A publicly referenced SMTP server (an MX for a domain) MUST NOT require STARTTLS in order to deliver mail locally — RFC 3207 forbids mandatory TLS on the public port 25 precisely because not all senders support it. (Receiving-side mandatory TLS is instead expressed via MTA-STS/DANE; sender-side via REQUIRETLS below.)

Security model: everything before the handshake — including the EHLO exchange and the STARTTLS advertisement itself — travels in cleartext and "may be modified by an active attacker." A man-in-the-middle can simply strip the STARTTLS keyword and the session silently continues in cleartext (the classic downgrade). RFC 3207's own answer is configuration: both clients and servers "MUST be able to be configured to require successful TLS negotiation of an appropriate cipher suite for selected hosts before messages can be successfully transferred," and clients should verify that the server certificate's domain name matches the host they intended to reach. In practice almost no MTA does this globally, because it would break delivery — which is why the policy mechanisms (MTA-STS, DANE, REQUIRETLS) exist.

Why mail tolerates downgrade: opportunistic security (RFC 7435)

RFC 7435 is the design philosophy behind default MTA behavior. It inverts the usual security framing: instead of treating cleartext as failure, it treats cleartext as the baseline and any encryption as an improvement — "some protection most of the time" beats a strict policy that blocks communication.

Key principles:

• Encrypt whenever mutually supported; authenticate when possible via downgrade-resistant means (DANE, cached/TOFU keys, manual configuration). The outcome per peer may be authenticated+encrypted, encrypted-but-unauthenticated, or cleartext — whichever is the maximum available.
• Explicit policy overrides opportunism. Where an administrator (or a published recipient policy) mandates security, the mandatory policy wins. Opportunistic security is the floor, not the ceiling.
• No misrepresentation: unauthenticated-encrypted sessions must not be logged or shown to users as equivalent to authenticated encryption.
• Prefer forward secrecy (PFS) wherever possible so recorded traffic can't be decrypted after later key compromise.

Terminology this introduces (used across the transport-security articles):

Term	Meaning
Unauthenticated, encrypted	TLS with no peer identity verification — defeats passive monitoring, not an active MITM; still strictly better than cleartext
Authenticated, encrypted	Peer identity verified (certificate/DANE) — defeats both passive and active attacks
TOFU	Trust-on-first-use: accept an unauthenticated key once, cache it, verify continuity thereafter (MTA-STS's caching model is TOFU-shaped)

The deliberate trade-off: opportunistic TLS accepts downgrade vulnerability because encryption's main win is against pervasive passive monitoring, and active attacks at scale become detectable. Falling back to cleartext when the TLS handshake fails is acceptable for opportunistic sessions only — the alternative (refusing delivery) punishes the wrong party. This is exactly the default posture of virtually every sending MTA today, and why an ESP's outbound TLS policy is normally "offer/attempt TLS everywhere, verify certificates only where a recipient policy (MTA-STS/DANE) or local per-destination rule requires it."

Submission and access: implicit TLS on 465 (RFC 8314)

RFC 8314 ("Cleartext Considered Obsolete") governs the user-facing side — mail submission (MUA→MSA) and access — and shifts the recommendation from STARTTLS to implicit TLS (TLS negotiated immediately on connect, before any protocol exchange):

Protocol	Port	Service name	Mode
SMTP submission	465	submissions	Implicit TLS (now the recommended primary)
SMTP submission	587	submission	STARTTLS (kept for transition)
IMAP	993	imaps	Implicit TLS
POP3	995	pop3s	Implicit TLS

Notes an ESP should know:

• Port 465 was historically misregistered ("smtps", later reassigned to another service) but so widely deployed for submission that RFC 8314 formalized the existing practice and IANA-registered it as submissions. It is not for MTA-to-MTA relay — port 25 remains STARTTLS-only.
• Rationale for implicit TLS over STARTTLS: simpler to implement and debug, and immune to the STARTTLS command-injection class of vulnerabilities (where pre-TLS pipelined commands leak into the post-TLS session).
• During transition, "clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465" — properly configured, there is no significant security difference.
• Version floors: servers and MUAs MUST support TLS 1.2 or later; the default minimum-confidentiality requirement is negotiation of TLS 1.1 or greater (raised in practice by RFC 8996 below). SSL 2.x/3.0 and TLS 1.0 should be discontinued "as soon as practicable."
• Certificates: servers must maintain valid certificates for all service names (per RFC 7817), support SNI, and MUAs SHOULD NOT treat a session as confidential if the certificate doesn't validate. DNSSEC-signed TLSA records are an optional additional trust anchor.
• When a provider cuts off cleartext authentication, the server "MUST NOT provide any indication over a cleartext channel of whether the user's authentication credentials were valid" (prevents account enumeration over the insecure path).
• Adds two Received-header clauses: tls (negotiated cipher suite) and group (DH group) — useful when auditing the encryption of a delivery path.

ESP relevance: your SMTP-injection endpoints for customers are submission services. Offering 465 (implicit) and 587 (STARTTLS), enforcing TLS 1.2+, refusing cleartext auth, and presenting a valid SNI-capable certificate is the RFC 8314 baseline customers' libraries increasingly assume.

Per-message mandatory TLS: REQUIRETLS (RFC 8689)

REQUIRETLS is the sender-side counterpart to the recipient-side MTA-STS/DANE policies: it lets the message originator demand TLS for a specific message, hop by hop, and get a bounce rather than a cleartext delivery. It has two independent mechanisms with opposite polarity:

The REQUIRETLS SMTP extension (require TLS)

• Advertised as REQUIRETLS in the EHLO response; invoked as a valueless parameter on MAIL FROM (MAIL FROM:<a@b> REQUIRETLS).
• A client may only forward a REQUIRETLS message to a server when all of: (1) the session is TLS-protected; (2) the MX resolution was trustworthy — DNSSEC-signed MX lookup or MX validated by an MTA-STS policy; (3) the server certificate chain verifies (Web PKI chain or DANE); (4) the next-hop server's post-TLS EHLO advertises REQUIRETLS.
• The sending MTA iterates MX hosts until one meets every condition; if none does, the message MUST NOT be transmitted and MUST be bounced.
• Relays MUST propagate the REQUIRETLS parameter onward. Mediators that re-originate messages should preserve the requirement "to the extent feasible."

Failure signaling (enhanced status codes — see Enhanced Status Codes):

Code	Meaning
5.7.30	REQUIRETLS support required (next hop doesn't support the extension)
5.7.10	Encryption needed (TLS-protected session could not be established)

Bounce handling: non-delivery reports for REQUIRETLS messages MUST themselves carry REQUIRETLS (unless redacted), and the server MUST behave as if RET=HDRS were set — the bounce carries headers only, never the body, so the protected content can't leak through the DSN path. Null-return-path bounces should not be silently discarded merely because the next relay lacks REQUIRETLS.

The TLS-Required: No header field (waive TLS)

The opposite assertion: a message header (TLS-Required: No) telling MTAs that the sender explicitly prefers delivery even without TLS — instructing clients to disregard a failing DANE or MTA-STS policy for this message. Use case: mail that must get through to a misconfigured domain (e.g., a message telling the postmaster their TLS is broken). Clients handling it "SHOULD attempt to send the message regardless of the ability to negotiate STARTTLS" while still using encryption when available. Unlike the SMTP extension, the header survives transit through MTAs that don't implement RFC 8689.

Limitations: REQUIRETLS is transport security only — messages remain visible in plaintext to every MTA on the path; end-to-end confidentiality still requires S/MIME or OpenPGP. Adoption among large mailbox providers remains limited; treat REQUIRETLS as a tool for mandated-secure streams between cooperating parties (see Mandated & Regulatory Email) rather than something to set on general marketing traffic.

Version floor: TLS 1.0 and 1.1 are dead (RFC 8996)

RFC 8996 (March 2021, BCP 195) formally deprecates TLS 1.0, TLS 1.1, and DTLS 1.0, moving RFC 2246 (TLS 1.0), RFC 4346 (TLS 1.1), RFC 4347 (DTLS 1.0), RFC 5469 (DES/IDEA suites), and RFC 7507 (Fallback SCSV) to Historic.

Normative rules:

• "TLS 1.0 MUST NOT be used"; "TLS 1.1 MUST NOT be used"; negotiation of either from any TLS version MUST NOT be permitted.
• Clients MUST NOT send a ClientHello with client_version {03,01} (1.0) or {03,02} (1.1); servers MUST NOT send a matching ServerHello; any party receiving a Hello at those versions MUST respond with a protocol_version alert and close the connection.
• Servers MUST still accept any {03,XX} record-layer version number in a ClientHello (interop), but MUST NOT negotiate the deprecated versions.

Why: both versions bind handshake integrity to SHA-1 (downgrade attacks at ~2^77 work), authenticate with SHA-1 or MD5||SHA-1 signatures, support no AEAD cipher suites, and mandate obsolete ciphers (e.g., TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA). Operationally, every extra supported version is a misconfiguration and maintenance liability. TLS 1.3's ServerHello.Random sentinel supersedes the Fallback SCSV downgrade defense.

Mail-specific consequence (the RFC itself is protocol-generic): the practical floor for SMTP, submission, IMAP and POP is TLS 1.2, with TLS 1.3 preferred. MTA-STS already requires senders to support TLS 1.2+. Major mailbox providers have progressively refused TLS ≤1.1 on submission and increasingly score or refuse old-version handshakes on port 25 — an ESP whose fleet still offers TLS 1.0/1.1 outbound will see handshake failures logged as deferrals/bounces at strict receivers, and inbound acceptance of ancient versions is a compliance finding. Configure: minimum TLS 1.2, modern AEAD suites, PFS key exchange, TLS 1.3 enabled.

Sender-side operational summary for an ESP

Layer	Default posture	Escalation
Outbound port 25	Opportunistic STARTTLS everywhere; fall back to cleartext on handshake failure (RFC 7435)	Honor recipient MTA-STS/DANE policies (verify certs, refuse insecure paths, defer not downgrade); per-destination mandatory-TLS rules for contracted partners; REQUIRETLS for messages that must never travel cleartext
TLS versions/ciphers	TLS 1.2 minimum, 1.3 preferred, AEAD + PFS (RFC 8996)	Never re-enable 1.0/1.1 to "fix" delivery to an ancient receiver — that receiver is the outlier
Certificates (outbound validation)	Not enforced for opportunistic sessions	MUST be enforced when an MTA-STS/DANE policy or REQUIRETLS applies
Submission (customer-facing)	465 implicit TLS + 587 STARTTLS, TLS 1.2+, valid SNI cert, no cleartext auth (RFC 8314)	—
Visibility	Log negotiated version/cipher per delivery; generate TLS-RPT reports for domains that request them; watch Google Postmaster Tools' encryption dashboard	—