RFC 9787: Guidance on End-to-End Email Security
In plain English — editorial summary, not part of the RFC
End-to-end cryptographic protections for email messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for Mail User Agent (MUA) implementers to help mitigate those risks and to make end-to-end email simple and secure for the end user. It provides a useful set of vocabulary as well as recommendations to avoid common failures. It also identifies a number of currently unsolved usability and interoperability problems.
Document record
- Document ID
- RFC9787
- Published
- August 2025
- Authors
- D. K. Gillmor; A. Melnikov; B. Hoeneisen
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- sec
- Pages
- 53
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 9788Header Protection for Cryptographically Protected EmailCurrent
August 2025
- RFC 8387Practical Considerations and Implementation Experiences in Securing Smart Object NetworksCurrent
May 2018
- RFC 6283Extensible Markup Language Evidence Record Syntax (XMLERS)Current
July 2011
- RFC 5403RPCSEC_GSS Version 2Updated
February 2009
- RFC 9216S/MIME Example Keys and CertificatesCurrent
April 2022
- RFC 8812CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) AlgorithmsCurrent
August 2020
- RFC 4490Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)Current
May 2006
- RFC 4303IP Encapsulating Security Payload (ESP)Current
December 2005
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?