Email was never designed to be private. SMTP carries your message as plain text across servers you don't control, and the protocol's authentication layers — SPF, DKIM, DMARC — protect the domain from spoofing, not the content from being read. If you want a message that only its recipient can open, you have to encrypt it before it enters that pipe. For decades, two standards have done exactly that: S/MIME and OpenPGP.
Both use the same fundamental scheme: the sender encrypts to the recipient's public key and signs with their own private key, so the recipient gets confidentiality and a proof of authorship in one envelope. The cryptography underneath is broadly comparable. The architecture around the keys is where they diverge sharply — and that architecture is what makes one feel like corporate plumbing and the other like a hobbyist's ritual.
The Question Public-Key Email Can't Avoid
Encrypting to a public key is easy. The hard part is the binding problem: a public key is just a blob of math, and nothing about it inherently says "this belongs to alice@example.com." If an attacker can convince you that their key is Alice's, they can read everything you send "to Alice." Every email encryption system is really an answer to one question — how do I trust this binding? — and S/MIME and PGP answer it in opposite directions.
S/MIME: Trust Flows Down From Authorities
S/MIME (Secure/Multipurpose Internet Mail Extensions) solves the binding problem the same way HTTPS does: with X.509 certificates issued by Certificate Authorities. You obtain a certificate from a CA, which verifies — to some level of rigor — that you control the email address before signing a certificate that binds your identity to your public key. Recipients trust your key because they trust the CA that vouched for it, and their mail client already ships with a list of trusted root CAs.
This hierarchical model is why S/MIME dominates enterprise. It's built into Microsoft Outlook, Apple Mail, and most corporate mail clients with no plugin required. An organization can run its own CA, issue certificates to every employee automatically, and get encrypted, signed internal mail that "just works" in the client people already use. Revocation has a defined mechanism too — certificates can be revoked and checked via CRLs or OCSP, the same infrastructure that backs the web's certificate revocation system.
Convenience comes from outsourcing trust to CAs. But a CA can be compelled, compromised, or simply careless — and if a CA in your trust store issues a fraudulent certificate for an address, the binding it certifies is exactly as trusted as a real one. You inherit the CA's trustworthiness whether you audited it or not.
PGP: Trust Is Something You Build Yourself
OpenPGP takes the opposite stance. There are no authorities. You generate your own keypair, and trust in a key comes from people verifying it directly — checking a fingerprint in person, or relying on others' signatures on that key through the web of trust. There's no gatekeeper deciding who gets a key and no central party that can be compelled to mis-issue one.
That decentralization is PGP's philosophical strength and its practical curse. Key discovery is a perennial pain — historically handled by keyservers, more recently by mechanisms like Web Key Directory — and verifying fingerprints out of band is something almost no normal user will reliably do. PGP also has essentially no native client support: you bolt it on with tools like GnuPG plus a mail-client plugin, or you use a provider that has wrapped it for you. The friction is the reason PGP, despite being older and beloved by technologists, never reached ordinary inboxes.
Side by Side
| Property | S/MIME | OpenPGP |
|---|---|---|
| Trust model | Hierarchical — CA-issued X.509 certificates | Decentralized — direct verification / web of trust |
| Native client support | Built into Outlook, Apple Mail, most enterprise clients | Requires plugins or dedicated tooling |
| Key issuance | Obtain a certificate from a CA (often paid) | Generate your own, free, instantly |
| Revocation | CRL / OCSP infrastructure | Revocation certificates, keyservers (inconsistent) |
| Best fit | Organizations with central IT | Individuals and technical communities |
What Neither One Fixes
It's tempting to treat the S/MIME-vs-PGP choice as the email-security decision. It isn't, because both share the same hard limits.
Metadata stays exposed. Both encrypt the message body, but the headers — sender, recipient, timestamps, and in standard usage the subject line — travel in the clear. Anyone watching the mail flow learns who is talking to whom and when, which is frequently more revealing than the contents. This is the same metadata problem that haunts every store-and-forward system.
No forward secrecy. Modern messaging protocols rotate keys so that compromising today's key doesn't expose yesterday's messages. S/MIME and PGP both lean on long-lived keypairs; capture the private key, and every message ever encrypted to it becomes readable. That's a structural gap relative to the forward secrecy of protocols like Signal or MLS.
In 2018, the EFAIL research disclosed attacks that could exfiltrate decrypted plaintext from both S/MIME and OpenPGP email by abusing how mail clients handled HTML and multipart MIME. The flaws were largely in client behavior rather than the core cryptography — but they were a pointed reminder that bolting encryption onto a format from another era leaves sharp edges.
So Which Should You Use?
If you're inside an organization with managed IT, S/MIME is the path of least resistance: certificates issued centrally, encryption built into the client everyone already has, revocation handled by infrastructure. If you're an individual or part of a technical community that values keys no authority can mis-issue, PGP gives you trust you control — at the cost of doing the work yourself. Our comparison of age versus GPG covers a third path for file encryption when you don't need email interoperability at all.
Where Haven Fits
Haven uses OpenPGP for email so it interoperates with the wider world — you can exchange encrypted mail with anyone holding a PGP key, no walled garden required. For real-time chat with other Haven users, it uses the MLS protocol instead, precisely because MLS delivers the forward secrecy and clean group key management that neither S/MIME nor PGP was built to provide.
That split is deliberate, and it reflects the honest conclusion of this comparison: PGP and S/MIME are both reasonable ways to encrypt email, but email encryption is a different, older problem than secure messaging — and the right tool depends on which one you're actually solving.