RFC 8689: SMTP Require TLS Option
In plain English — editorial summary, not part of the RFC
The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required. If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed or by requesting that recipient-side policy mechanisms such as MTA-STS and DNS-Based Authentication of Named Entities (DANE) be ignored when relaying a message for which security is unimportant.
Document record
- Document ID
- RFC8689
- Published
- November 2019
- Authors
- J. Fenton
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- sec
- Pages
- 16
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 8314Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and AccessUpdated
January 2018
- RFC 7817Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related ProtocolsCurrent
March 2016
- RFC 7672SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)Current
October 2015
- RFC 7960Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email FlowsCurrent
September 2016
- RFC 9422The LIMITS SMTP Service ExtensionCurrent
February 2024
- RFC 7103Advice for Safe Handling of Malformed MessagesCurrent
January 2014
- RFC 6710Simple Mail Transfer Protocol Extension for Message Transfer PrioritiesCurrent
August 2012
- RFC 6531SMTP Extension for Internationalized EmailCurrent
February 2012
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?