RFC 8689: SMTP Require TLS Option

Standards Track Transport Security Published November 2019

ELI5: Normal email encryption is like asking a courier “please use the armored truck if it’s available.” If the armored truck is busy, the courier shrugs and uses a regular van. REQUIRETLS is a stamp on the envelope that says “armored truck or don’t deliver it at all.” The message would rather bounce than travel unencrypted.

Why This Exists

Server-to-server email encryption (via STARTTLS) is opportunistic by default. If the receiving server doesn't support TLS, or if a man-in-the-middle strips the STARTTLS capability, most sending servers will fall back to cleartext delivery. The message gets through, but without encryption.

Technologies like MTA-STS and DANE address this at the domain level — they let a receiving domain declare "all mail to us must use TLS." But those are receiver-side policies. The sender had no way to say "this specific message requires TLS at every hop."

RFC 8689 fills that gap with two complementary mechanisms:

The REQUIRETLS SMTP extension: A per-message flag in the SMTP envelope that tells each relay server "do not deliver this message unless the next hop supports TLS with verified certificates."
The TLS-Required header: A message header that signals the same intent, usable when the sender doesn't have direct control over the SMTP envelope (e.g., when submitting through an MSA).

How It Works

The REQUIRETLS SMTP Extension

The sender advertises its intent during the SMTP transaction by adding REQUIRETLS as a parameter to the MAIL FROM command:

# Server advertises REQUIRETLS support in EHLO S: 220 mx.example.com ESMTP C: EHLO sender.example.org S: 250-mx.example.com S: 250-STARTTLS S: 250-REQUIRETLS S: 250 OK # Upgrade to TLS first C: STARTTLS S: 220 Go ahead # ... TLS handshake with certificate verification ... C: EHLO sender.example.org S: 250-mx.example.com S: 250-REQUIRETLS S: 250 OK # Submit with REQUIRETLS flag C: MAIL FROM:<alice@example.org> REQUIRETLS S: 250 OK C: RCPT TO:<bob@example.com> S: 250 OK

What Happens at Each Hop

When a relay server processes a message with the REQUIRETLS flag, it must enforce these rules before forwarding:

TLS is mandatory. The connection to the next hop must use TLS. If the next server doesn't support STARTTLS, the message must not be delivered — it bounces.
Certificate verification is required. The next hop's TLS certificate must be valid and match the server hostname (via DANE/TLSA or Web PKI). Self-signed or mismatched certificates cause a bounce.
The REQUIRETLS flag propagates. The relay must pass the REQUIRETLS parameter to the next hop if it also supports the extension. If the next hop doesn't support REQUIRETLS, the relay may still deliver if it can verify TLS via DANE or MTA-STS.

The TLS-Required Header

For senders who submit via an MSA and don't control SMTP parameters directly, the TLS-Required header provides the same signal:

TLS-Required: No ; Wait — "No" means "do not require TLS"? ; Correct. The header has two values: ; TLS-Required: No → explicitly opt OUT of REQUIRETLS ; (use normal opportunistic TLS) ; The absence of the header means normal behavior. ; The REQUIRETLS envelope flag is the positive signal.

The TLS-Required: No header is specifically designed as an opt-out mechanism. It tells the sending MTA: "even if REQUIRETLS would normally apply to this message (e.g., because of a domain-wide policy), don't enforce it for this particular message." This is useful for messages like password resets or notifications where delivery is more important than guaranteed encryption.

Bounce Behavior

When REQUIRETLS prevents delivery, the sending server generates a non-delivery report (bounce). The bounce itself must also be sent over TLS — REQUIRETLS applies to DSN (Delivery Status Notification) messages too. If the bounce cannot be delivered securely, it is silently dropped rather than sent in cleartext (to avoid leaking information about the original message).

# Next hop doesn't support TLS — REQUIRETLS prevents delivery C: EHLO relay.example.org S: 250-mx.recipient.com S: 250 OK # No STARTTLS advertised — cannot deliver with REQUIRETLS # Relay generates a bounce to alice@example.org: # 550 5.7.30 REQUIRETLS support required but not available

Key Technical Details

Relationship to MTA-STS and DANE

Mechanism	Who Sets Policy	Scope	Verification Method
MTA-STS	Receiving domain	All mail to the domain	Web PKI (HTTPS fetch)
DANE	Receiving domain	All mail to the domain	DNSSEC + TLSA records
REQUIRETLS	Sending server/user	Per-message	DANE or MTA-STS at each hop

REQUIRETLS is complementary, not competitive. MTA-STS and DANE protect the receiving domain's inbound mail. REQUIRETLS protects a specific outbound message. A message with REQUIRETLS is validated using DANE or MTA-STS at each hop — if neither is available for a hop, delivery fails.

TLS Version Requirements

REQUIRETLS requires TLS 1.2 or later. Connections using TLS 1.0 or 1.1 do not satisfy the requirement, consistent with RFC 8996 deprecating older TLS versions.

Enhanced Status Codes

Code	Meaning
`5.7.30`	REQUIRETLS support required but not available at the next hop
`5.7.31`	REQUIRETLS cannot be honored (e.g., next hop's certificate is invalid)

Common Mistakes

Assuming REQUIRETLS is widely deployed. Adoption is still limited. Most MTAs do not yet support the REQUIRETLS extension. Using it for all mail will result in bounces to many recipients.
Confusing REQUIRETLS with STARTTLS. STARTTLS is the mechanism to upgrade a connection to TLS. REQUIRETLS is a policy that mandates STARTTLS succeed and certificates validate. STARTTLS without REQUIRETLS is opportunistic; REQUIRETLS makes it mandatory.
Expecting end-to-end encryption. REQUIRETLS ensures TLS on each hop, but the message is decrypted and re-encrypted at every relay server. It is hop-by-hop encryption, not end-to-end. For true end-to-end encryption, use S/MIME or PGP.
Not handling bounces. REQUIRETLS will cause legitimate delivery failures when the recipient's server doesn't support TLS or has certificate issues. Your application must handle these bounces and potentially retry without REQUIRETLS or notify the user.
Using TLS-Required: Yes. There is no TLS-Required: Yes value. The header only has a No value for opt-out. The positive signal is the REQUIRETLS SMTP parameter, not a header value.
Forgetting about bounces. REQUIRETLS applies to DSN messages too. If the bounce can't be delivered over TLS, it is silently dropped. The original sender may never know delivery failed.

Deliverability Impact

Reduces delivery rate. Enabling REQUIRETLS for all messages will cause delivery failures to servers that don't support TLS or have certificate issues. Use it selectively for messages where security outweighs delivery certainty.
Protects high-value messages. For financial notifications, legal documents, healthcare data, or any message subject to regulatory compliance, REQUIRETLS ensures the message is never transmitted in cleartext.
Complements MTA-STS. If your domain publishes MTA-STS and your recipients' domains also have MTA-STS or DANE, REQUIRETLS adds per-message assurance on top of the domain-level policies. The combination provides the strongest transport security available in SMTP.
Bounce messages are also protected. Because REQUIRETLS applies to DSNs, sensitive information in bounce messages (which can include parts of the original message) is also protected from cleartext transmission.