OpenPGP and S/MIME Guide: Email Encryption and Signing

Transport encryption protects email between servers, but once a message lands in a mailbox, a journal or a compromised account, only message-level encryption and signing still protect its content and prove who sent it. OpenPGP and S/MIME are the two standards for end-to-end email security: both sign and encrypt the message body and attachments with the recipient's public key, but they differ in trust model, key distribution and how well they fit an enterprise. This guide explains the current specifications (RFC 9580 for OpenPGP and RFC 8551 for S/MIME 4.0), the EFAIL lessons that changed both, how to choose between them and policy-based service encryption, and how to deploy, operate and measure them. It is for messaging, PKI and security architects in enterprises and government bodies that must exchange sensitive or signed email.

Key takeaways

Signing and encryption solve different problems. Microsoft's S/MIME documentation puts it plainly: a signature proves the sender and integrity but does not hide content, and encryption hides content but does not prove the sender, so most policies need both.
Use authenticated encryption only. EFAIL (2018) showed that unauthenticated CBC and CFB modes let attackers alter ciphertext; S/MIME 4.0 requires AES-GCM through AuthEnvelopedData and OpenPGP RFC 9580 adds AEAD packets (SEIPD v2).
S/MIME fits managed enterprises; OpenPGP fits communities. S/MIME rides on X.509 PKI and directory publication, while OpenPGP uses self-managed keys discovered through key servers or the Web Key Directory.
Key management is the real project. Issuing, publishing, renewing, archiving and recovering encryption keys decides whether users can still read their mail in five years.
Encryption hides content from your own controls too. Gateways, DLP, journaling and eDiscovery cannot inspect what they cannot decrypt, so plan where decryption is allowed before rollout.

How message-level encryption works

Both standards use the same hybrid design. The sender's client generates a random content key, encrypts the message with it, then encrypts that content key to each recipient's public key (and usually to the sender's own key so the sent copy stays readable). Signing hashes the message and signs the hash with the sender's private key. The differences are in packaging and trust.

Aspect	OpenPGP (RFC 9580)	S/MIME 4.0 (RFC 8551)
Status	IETF Standards Track, July 2024; obsoletes RFC 4880, 5581 and 6637	IETF Standards Track, April 2019; obsoletes RFC 5751
Message format	OpenPGP packets, usually in PGP/MIME	CMS (Cryptographic Message Syntax) inside MIME
Trust model	Self-generated keys; trust by fingerprint verification, signatures from others, or organisational key directories	X.509 certificates from a CA; trust from the CA chain
Key discovery	Key servers, Web Key Directory, keys attached to signed mail	Directory or GAL publication, certificates attached to signed mail
Authenticated encryption	SEIPD v2 with EAX, OCB or GCM AEAD modes	AuthEnvelopedData with AES-128 GCM and AES-256 GCM required
Modern algorithms	v6 keys and signatures, Ed25519, Ed448, X25519, X448, Argon2 passphrase protection	ECDSA P-256, EdDSA with curve25519, ECDH with P-256 and X25519
Typical home	Open source projects, security researchers, journalists, some government communities	Enterprise and government mail with managed PKI and Outlook or Apple Mail

What the current specifications change

OpenPGP: RFC 9580

Version 6 formats: new v6 keys, v6 signatures and v6 public key encrypted session key packets. The RFC says an implementation must generate a v6 signature when signing with a v6 key, and must not create v3 signatures.
AEAD encryption: the version 2 Symmetrically Encrypted and Integrity Protected Data packet uses EAX, OCB or GCM. Version 1 SEIPD and the legacy SED packet remain only so that historic data can be read.
Passphrase protection: Argon2 string-to-key is recommended over iterated and salted S2K, and simple S2K must not be generated.
Retired options: IDEA must not be generated (it may be read for old data), ElGamal v6 session key packets must not be generated, and the legacy packet format should not be used for new data.
Interoperability caution: the OpenPGP ecosystem has also seen a separate LibrePGP effort (the Web Key Directory draft refers to both OpenPGP and LibrePGP keys). Test that every client and gateway you rely on reads the key and message versions you plan to generate before switching to v6.

S/MIME 4.0: RFC 8551

Content encryption: AES-128 GCM and AES-256 GCM are required, ChaCha20-Poly1305 is SHOULD+, and AES-128 CBC is MUST- (still required, expected to be downgraded).
AuthEnvelopedData: added for confidentiality with integrity. Section 3.3 of the RFC warns that enveloped-only messages lack integrity, so ciphertext can be altered without detection.
Signatures: receiving agents must support ECDSA with P-256 and SHA-256 and EdDSA with curve25519; RSA PKCS #1 v1.5 with SHA-256 is MUST-.
Retired algorithms: SHA-1, DSA and triple DES are marked historic.
Public certificates: for publicly trusted S/MIME certificates, the CA/Browser Forum S/MIME Baseline Requirements apply (version 1.0.16 at 28 September 2026, initial implementation date 1 September 2023). They define Mailbox-, Organization-, Sponsor- and Individual-validated profiles in Multipurpose and Strict generations; issuance under Legacy profiles stopped from 15 July 2025.

EFAIL and what it teaches defenders

EFAIL, published in May 2018 and presented at USENIX Security that August, showed two classes of weakness that exposed plaintext of encrypted mail (CVE-2017-17688 for OpenPGP and CVE-2017-17689 for S/MIME). One abused how some clients rendered decrypted parts of multipart HTML mail alongside attacker-controlled content, so the client itself sent decrypted text to an external server. The other modified CBC (S/MIME) or CFB (OpenPGP) ciphertext, which unauthenticated modes cannot detect. The researchers found the ciphertext modification class straightforward against S/MIME and harder against OpenPGP because of its modification detection code.

The defensive lessons still apply today:

Require authenticated encryption: configure clients and gateways to send AES-GCM AuthEnvelopedData (S/MIME) or SEIPD with integrity protection (OpenPGP), and to refuse to display messages whose integrity check fails.
Restrict remote content: block automatic loading of remote images and other external content in mail clients, which also helps against tracking and phishing.
Patch clients: EFAIL was largely fixed in client software, so unmanaged or outdated mail clients carry the risk.
Treat decryption as a privileged event: the client that decrypts holds the plaintext; endpoint security matters as much as the cryptography.

Choosing an approach

Need	S/MIME	OpenPGP	Policy-based service encryption
Signed mail that recipients' clients verify natively	Strong fit with a public or partner-trusted CA	Works where recipients use OpenPGP clients	Not a signature in the end-to-end sense
Encryption to the general public	Needs recipient certificates; rarely practical	Needs recipient keys; rarely practical	Strong fit: recipient reads in a portal or authenticated client
Communities that already use PGP (open source, researchers, CERTs)	Weak fit	Strong fit; publish keys through WKD	Weak fit
Central key recovery, archiving and eDiscovery	Good with CA key archival and directory publication	Possible with an organisational key or gateway, but harder	Built in, because the provider or your tenant holds the keys
Protection from the mail provider itself	Yes, keys held by users or your PKI	Yes, keys held by users	No: provider-managed keys

Microsoft's documentation contrasts S/MIME with Microsoft Purview Message Encryption: Purview is policy-based (administrators decide when messages are encrypted, inside or outside the organisation) and built on Azure Rights Management without a PKI, while S/MIME requires certificates and publishing infrastructure and users apply it per message. Many organisations run both: S/MIME for signing and for partners with PKI, service encryption for the general public. Microsoft also notes that S/MIME is disabled in Outlook on the web for messages with sensitivity labels that apply protection actions, so test label and S/MIME policy together.

Small organisations: start with signing using certificates from a public S/MIME CA and use service encryption for confidentiality; running your own S/MIME PKI is rarely worth it below a few hundred users. Large organisations and government: run an internal or managed S/MIME PKI with separate signing and encryption certificates, key archival for encryption keys, and directory publication; add OpenPGP only for communities that require it.

Deploying S/MIME in a managed enterprise

Decide certificate types: separate signing and encryption certificates let you archive encryption keys for recovery without ever escrowing signing keys, which preserves non-repudiation.
Issue certificates: from an internal CA or a public S/MIME CA. Microsoft's Exchange Online guidance requires each user certificate to have a private key and a populated Subject Key Identifier, and suggests issuing from an intermediate CA so the root survives a mass reissue. See the Private CA Design and Operations Guide.
Publish public certificates: in Microsoft environments, write them to the userSMIMECertificate and userCertificate attributes in Active Directory and synchronise them with Microsoft Entra Connect, so senders' clients can find recipients' certificates.
Tell the service which CAs to trust: for Exchange Online, export the root and intermediate certificates to an SST file and load them with Set-SmimeConfig -SMIMECertificateIssuingCA.
Configure clients: deploy user certificates through device management, enable S/MIME in each client, and for mobile set mailbox policy parameters such as RequireSignedSMIMEMessages, RequireEncryptedSMIMEMessages and RequireEncryptionSMIMEAlgorithm.
Pilot: start with a signing-only pilot group, verify signatures across Outlook desktop, web, mobile and Apple Mail, then enable encryption for a pilot group with defined recipients.
Roll back: encryption is the hard part to reverse, because mail encrypted to a key needs that key forever. Keep key archival and recovery tested before encryption leaves the pilot.

Deploying OpenPGP

Key generation: generate keys on the user's device or a hardware token; prefer Ed25519 for signing and X25519 for encryption where every peer supports them, and set an expiry so abandoned keys age out.
Publication with WKD: the Web Key Directory lets clients fetch a key over HTTPS from the recipient's own domain at /.well-known/openpgpkey/, using a hashed local part. Clients try the advanced method (an openpgpkey subdomain) first and then the direct method. WKD is an individual Internet-Draft (draft-koch-openpgp-webkey-service-22, 22 July 2026, Informational, not IETF-endorsed), so treat details as subject to change.
Organisational keys: security teams and PSIRTs commonly publish a team key for vulnerability reports. Rotate it on a schedule, keep the private key offline or in a token, and publish the fingerprint on an authenticated web page.
Revocation certificates: create one at key generation and store it securely, so a lost or compromised key can be revoked.
Fingerprint verification: a key fetched from a key server proves nothing about who owns it. Verify fingerprints through a second authenticated channel (a signed web page, a directory you control, or in person) before marking a key as trusted, and record which method was used for high-value correspondents such as regulators or incident response partners.
Gateways: OpenPGP gateways that encrypt and decrypt at the mail edge give central policy but move plaintext and keys into the gateway, which then becomes a high-value system.

Key lifecycle and identity

Every encryption key is an identity credential with a long tail: mail encrypted today must be readable for as long as you retain it.

Archival and recovery: archive encryption private keys (never signing keys) in the CA or a key management system with multi-person recovery, and log each recovery. See the Cryptographic Key Management Guide.
Leavers: revoke signing certificates at departure; keep encryption keys in archive for the retention period so mailbox content stays accessible to authorised reviewers.
Shared and service mailboxes: mailboxes for teams, applications and gateways need their own certificates or keys with named owners. These are non-human identities and belong in the same inventory as other machine credentials.
Private key theft: attackers who reach an endpoint can copy software keys (ATT&CK T1552.004 Private Keys) and read archived mail. Hardware tokens or platform key storage reduce this.

Detection and measurement

Monitor CA issuance and recovery events for S/MIME templates, and alert on encryption key recovery outside an approved request.
Track signature verification failures reported by gateways and clients; a spike can indicate certificate expiry, a broken chain or tampering.
Watch for mail-forwarding rules and mailbox exports on executive mailboxes (T1114 Email Collection, T1114.002 Remote Email Collection), which encryption alone does not prevent once the user's client decrypts.
Log which messages bypass content inspection because they are encrypted, and route them to a defined review path.

Metric	Why it matters
Share of outbound mail from in-scope roles that is signed	Shows signing policy is actually used
Users with valid, unexpired certificates or keys	Expired credentials cause silent fallback to unprotected mail
Encrypted messages sent with authenticated encryption (GCM or SEIPD v2)	Measures EFAIL-class exposure
Successful key recovery tests per quarter	Proves archived mail stays readable
Clients below supported version	Unpatched clients reintroduce rendering flaws

Common failure patterns

Encryption without archival: users lose a laptop or leave, and years of encrypted mail become unreadable, including to legal hold.
Unauthenticated modes left on: clients still send AES-CBC enveloped data or legacy OpenPGP packets because defaults were never changed.
Signing keys escrowed: combining signing and encryption in one archived key undermines non-repudiation.
No directory publication: senders cannot find recipients' certificates, so users give up and send in clear.
Treating encryption as anti-phishing: a valid signature proves which key signed, not that the sender is who the display name claims. Train users to check the signer identity. See the Email Identity and BEC Guide.
Inspection blind spots: malware in encrypted attachments (T1566.001 Spearphishing Attachment) bypasses gateway scanning unless a decryption point exists.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SC-8 and SC-8(1) Transmission Confidentiality and Integrity, Cryptographic Protection	Message-level protection beyond the transport link
NIST SP 800-53 Rev. 5	SC-12, SC-13, SC-17	Key management, approved cryptography, PKI certificates for S/MIME
NIST SP 800-53 Rev. 5	IA-5(2) Public Key-based Authentication	Certificate path validation and revocation checks for signatures
NIST SP 800-177 Rev. 1	Trustworthy Email (content security)	Recommends S/MIME for content encryption and authentication alongside SPF, DKIM, DMARC and TLS
NIST CSF 2.0	PR.DS-01, PR.DS-02, PR.AA-01	Data at rest and in transit, managed credentials
MITRE ATT&CK v20	T1114, T1552.004, T1557	Mail collection, key theft, interception

Practitioner checklist

Define which roles must sign, which must encrypt, and to whom, before choosing technology.
Require AES-GCM AuthEnvelopedData for S/MIME and integrity-protected (preferably SEIPD v2) encryption for OpenPGP.
Issue separate signing and encryption certificates, and archive only encryption keys with multi-person recovery.
Publish certificates in the directory and OpenPGP keys through WKD on your own domain.
Block remote content loading in mail clients and keep every client patched.
Decide where encrypted mail may be decrypted for DLP, journaling and eDiscovery, and document it.
Assign owners and certificates to shared, service and gateway mailboxes.
Test key recovery and certificate renewal at least quarterly.

OpenPGP and S/MIME Email Encryption Guide: Choosing, Deploying and Operating Message Encryption