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

> The sender-side TLS layer for mail — RFC 3207 STARTTLS mechanics, RFC 7435 opportunistic security, RFC 8314 implicit TLS on 465/587, RFC 8689 REQUIRETLS, and the RFC 8996 TLS 1.0/1.1 deprecation.

Source: emailmarketing.net — https://emailmarketing.net/learn/transport-security/smtp-tls-practice

If you send mail or run a submission service, you need to know how TLS is actually negotiated, when your servers may fall back to cleartext, and which ports and TLS versions to offer. [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts), [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp) and [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) are policies that receiving domains publish. Beneath them is the layer described here, seen from the sender's side.

That layer covers how STARTTLS works on the wire, why mail uses opportunistic TLS by default (without authentication, and tolerating downgrades), which ports and TLS versions apply where, and how TLS can be made mandatory for a single message (REQUIRETLS) or through a minimum protocol version (the deprecation of TLS 1.0/1.1).

## STARTTLS mechanics (RFC 3207)

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

The sequence on the wire:

1. The client connects, the server greets it with `220`, and the client sends `EHLO`.
2. A server that supports TLS lists the `STARTTLS` keyword (with no parameters) in its EHLO response.
3. The client sends the command `STARTTLS` on its own (no parameters are allowed).
4. The server replies, and after a `220` both sides start the TLS handshake immediately.

| Reply code | Meaning |
|---|---|
| `220` | Ready to start TLS. The client MUST begin TLS negotiation immediately |
| `501` | Syntax error (parameters were supplied, and none are allowed) |
| `454` | TLS not available for a temporary reason (the client can retry) |
| `530` | "Must issue a STARTTLS command first": the server requires TLS before other commands |
| `554` | The server refuses further SMTP commands because the security achieved is not sufficient |

Rules after the handshake:

- The SMTP session **returns to its initial state**, as if the 220 greeting had just been sent. The server MUST discard everything it learned from the client before TLS (for example, the EHLO argument), and the client MUST discard the list of server capabilities it received before TLS.
- The client SHOULD send a new `EHLO`. The list of extensions the server advertises MAY differ from the one sent in cleartext.
- The server MUST NOT advertise `STARTTLS` in its EHLO response after the handshake, and the client MUST NOT send STARTTLS when TLS is already active.
- A publicly referenced SMTP server (an MX for a domain) MUST NOT require STARTTLS before it delivers mail locally. RFC 3207 forbids mandatory TLS on the public port 25 because not all senders support it. A receiving domain that wants mandatory TLS uses [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) or [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp) instead, and a sender uses REQUIRETLS, described below.

The security model has a weakness. Everything before the handshake, including the EHLO exchange and the STARTTLS advertisement itself, travels in cleartext and "may be modified by an active attacker." An attacker in the middle can simply remove the STARTTLS keyword, and the session continues in cleartext without any warning. This is the classic downgrade attack.

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 check that the domain name in the server certificate matches the host they meant to reach. In practice, almost no MTA does this for all destinations, because it would break delivery. That is why the policy mechanisms (MTA-STS, DANE, REQUIRETLS) exist.

## Why mail tolerates downgrade: opportunistic security (RFC 7435)

RFC 7435 sets out the design thinking behind how MTAs behave by default. It reverses the usual view of security. Instead of treating cleartext as a failure, it treats cleartext as the **baseline** and any encryption as an improvement: "some protection most of the time" is better than a strict policy that blocks communication.

The main principles:

- **Encrypt whenever both sides support it, and authenticate when possible** through means that resist downgrade (DANE, keys cached on first use (TOFU), manual configuration). With each peer, the result may be authenticated and encrypted, encrypted without authentication, or cleartext, whichever is the best available.
- **An explicit policy overrides opportunistic behavior.** Where an administrator, or a policy published by the recipient, makes security mandatory, the mandatory policy wins. Opportunistic security is the minimum, not the maximum.
- **Do not misrepresent the protection.** Sessions that are encrypted but not authenticated must not be logged, or shown to users, as equal to authenticated encryption.
- **Prefer forward secrecy (PFS)** wherever possible, so that recorded traffic cannot be decrypted if a key is compromised later.

The terms it introduces, which the transport security guides on this site also use:

| Term | Meaning |
|---|---|
| Unauthenticated, encrypted | TLS without checking the peer's identity. It defeats passive monitoring but not an active attacker in the middle (MITM). It is still strictly better than cleartext |
| Authenticated, encrypted | The peer's identity is verified (by a certificate or DANE). It defeats both passive and active attacks |
| TOFU | Trust on first use: accept a key without authentication the first time, cache it, and check that it stays the same afterward (the caching model of MTA-STS works in a similar way) |

The trade-off is deliberate. Opportunistic TLS accepts the risk of downgrade because the main benefit of encryption is against pervasive passive monitoring, and active attacks at scale can be detected. Falling back to cleartext when the TLS handshake fails is acceptable for opportunistic sessions only, because the alternative, refusing delivery, punishes the wrong party.

This is the default behavior of nearly every sending MTA today. It is also why an ESP's outbound TLS policy is normally to "offer and attempt TLS everywhere, and verify certificates only where a recipient policy (MTA-STS or DANE) or a local rule for that destination requires it."

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

RFC 8314 ("Cleartext Considered Obsolete") covers the side of mail that users connect to: submission from a mail client to a submission server (MUA to MSA), and access to mailboxes. It moves the recommendation from STARTTLS to **implicit TLS**, where TLS is negotiated as soon as the connection opens, before any protocol exchange:

| Protocol | Port | Service name | Mode |
|---|---|---|---|
| SMTP submission | **465** | `submissions` | Implicit TLS (now the recommended main option) |
| SMTP submission | **587** | `submission` | STARTTLS (kept during the transition) |
| IMAP | 993 | `imaps` | Implicit TLS |
| POP3 | 995 | `pop3s` | Implicit TLS |

What an ESP should know:

- Port 465 was registered incorrectly in the past ("smtps", later given to another service), but it was so widely used for submission that RFC 8314 made the existing practice official and registered it with IANA as `submissions`. It is **not** for relay between MTAs: port 25 still uses STARTTLS only.
- Implicit TLS is preferred to STARTTLS because it is simpler to implement and debug, and because it is immune to the STARTTLS command injection vulnerabilities, where commands pipelined before TLS leak into the session after TLS.
- During the transition, "clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465". When both are configured properly, there is no significant difference in security.
- Minimum versions: servers and mail clients **MUST support TLS 1.2 or later**. The default minimum requirement for confidentiality is negotiation of TLS 1.1 or later, which RFC 8996 (below) raises in practice. SSL 2.x, SSL 3.0 and TLS 1.0 should be discontinued "as soon as practicable."
- Certificates: servers must keep valid certificates for all their service names (as RFC 7817 describes) and support Server Name Indication (SNI). Mail clients SHOULD NOT treat a session as confidential if the certificate does not validate. TLSA records signed with DNSSEC are an optional additional trust anchor.
- When a provider stops accepting authentication in cleartext, the server "MUST NOT provide any indication over a cleartext channel of whether the user's authentication credentials were valid". This prevents attackers from discovering valid accounts over the insecure path.
- It adds two clauses to the Received header: `tls` (the negotiated cipher suite) and `group` (the Diffie-Hellman group). They are useful when you audit the encryption of a delivery path.

Why this matters to an ESP: the SMTP endpoints where your customers inject mail are submission services. The RFC 8314 baseline that customers' libraries increasingly expect is to offer 465 (implicit TLS) and 587 (STARTTLS), require TLS 1.2 or later, refuse authentication in cleartext, and present a valid certificate that supports SNI.

## Per-message mandatory TLS: REQUIRETLS (RFC 8689)

REQUIRETLS is the sender's counterpart to the policies that recipients publish with MTA-STS and DANE. It lets the **originator of a message** require TLS for that specific message at every hop, and receive a bounce rather than have the message delivered in cleartext. It has two independent mechanisms that work in opposite directions.

### The REQUIRETLS SMTP extension (require TLS)

- The server advertises `REQUIRETLS` in its EHLO response, and the client uses it as a parameter with no value on `MAIL FROM` (`MAIL FROM:<a@b> REQUIRETLS`).
- A client may forward a REQUIRETLS message to a server only when **all** of these are true: (1) the session is protected by TLS; (2) the MX lookup can be trusted, because it was signed with DNSSEC **or** the MX was validated by an MTA-STS policy; (3) the server's certificate chain verifies (through the Web PKI or DANE); (4) the next server's EHLO response after TLS advertises REQUIRETLS.
- The sending MTA tries each MX host in turn until one meets every condition. If none does, the message MUST NOT be transmitted and MUST be bounced.
- Relays MUST pass the REQUIRETLS parameter on. Intermediaries that send messages again as new messages should keep the requirement "to the extent feasible."

How failures are reported, with enhanced status codes (see [Enhanced Status Codes](https://emailmarketing.net/learn/bounce-handling/smtp-enhanced-status-codes)):

| Code | Meaning |
|---|---|
| `5.7.30` | REQUIRETLS support required (the next hop does not support the extension) |
| `5.7.10` | Encryption needed (a session protected by TLS could not be established) |

Bounce handling: non-delivery reports for REQUIRETLS messages MUST themselves carry REQUIRETLS (unless they are redacted), and the server MUST behave as if `RET=HDRS` were set. The bounce contains only the headers, never the body, so the protected content cannot leak through the delivery status notification (DSN). Bounces with a null return path should not be discarded silently just because the next relay does not support REQUIRETLS.

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

This header makes the opposite request. A message header (`TLS-Required: No`) tells MTAs that the sender explicitly prefers delivery even without TLS, and instructs clients to ignore a DANE or MTA-STS policy that fails for this message. It is meant for mail that must reach a misconfigured domain, for example a message telling the postmaster that their TLS is broken.

Clients that handle it "SHOULD attempt to send the message regardless of the ability to negotiate STARTTLS", while still using encryption when it is available. Unlike the SMTP extension, the header survives passing through MTAs that do not implement RFC 8689.

Limitations: REQUIRETLS provides transport security only. Messages remain readable in plaintext on every MTA along the path, and confidentiality from end to end still requires S/MIME or OpenPGP. Adoption among large mailbox providers is still limited. Use REQUIRETLS for streams that must be secure between parties that cooperate (see [Mandated & Regulatory Email](https://emailmarketing.net/learn/operations/mandated-and-regulatory-email)), not on general marketing traffic.

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

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

The normative rules:

- "TLS 1.0 MUST NOT be used" and "TLS 1.1 MUST NOT be used". Negotiating either of them 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), and servers MUST NOT send a matching ServerHello. Any party that receives a Hello with those versions MUST respond with a `protocol_version` alert and close the connection.
- Servers MUST still accept any `{03,XX}` version number at the record layer of a ClientHello (for interoperability), but MUST NOT negotiate the deprecated versions.

The reasons: both versions tie the integrity of the handshake to SHA-1, which allows downgrade attacks at a cost of ~2^77 operations. They authenticate with SHA-1 or MD5||SHA-1 signatures, support no AEAD cipher suites, and require obsolete ciphers (for example, `TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA`). In operation, every extra version you support is a source of misconfiguration and maintenance work. The sentinel value in TLS 1.3's ServerHello.Random replaces the Fallback SCSV defense against downgrade.

What this means for mail (the RFC itself applies to all protocols): the practical minimum for SMTP, submission, IMAP and POP is **TLS 1.2**, with TLS 1.3 preferred. [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) already requires senders to support TLS 1.2 or later. Major mailbox providers have progressively refused TLS ≤1.1 on submission, and increasingly score or refuse handshakes with old versions on port 25.

An ESP whose servers still offer TLS 1.0/1.1 for outbound mail will see handshake failures, logged as deferrals or bounces, at strict receivers. Accepting very old versions on inbound connections is a compliance finding. Configure a minimum of TLS 1.2, modern AEAD cipher suites, key exchange with PFS, and TLS 1.3 enabled.

## Sender-side operational summary for an ESP

| Layer | Default behavior | Stricter options |
|---|---|---|
| Outbound port 25 | Opportunistic STARTTLS everywhere; fall back to cleartext if the handshake fails (RFC 7435) | Honor the [MTA-STS](https://emailmarketing.net/learn/transport-security/mta-sts) and [DANE](https://emailmarketing.net/learn/transport-security/dane-smtp) policies of recipients (verify certificates, refuse insecure paths, defer rather than downgrade); mandatory TLS rules for the destinations of contracted partners; REQUIRETLS for messages that must never travel in cleartext |
| TLS versions and ciphers | TLS 1.2 minimum, 1.3 preferred, AEAD and PFS (RFC 8996) | Never turn 1.0 or 1.1 back on to "fix" delivery to a very old receiver; that receiver is the exception |
| Certificates (validation on outbound mail) | Not enforced for opportunistic sessions | MUST be enforced when an MTA-STS or DANE policy, or REQUIRETLS, applies |
| Submission (for customers) | 465 with implicit TLS and 587 with STARTTLS, TLS 1.2 or later, a valid certificate with SNI, no authentication in cleartext (RFC 8314) | None |
| Visibility | Log the negotiated version and cipher for each delivery; generate [TLS-RPT](https://emailmarketing.net/learn/transport-security/tls-rpt) reports for domains that ask for them; watch the encryption dashboard in Google Postmaster Tools | None |