S/MIME and OpenPGP both give you signed and encrypted email, and both are supported in mainstream clients. They differ mainly in where trust comes from. S/MIME trusts a hierarchy of certificate authorities. OpenPGP trusts keys that users verify directly, or that people they trust have signed. That difference shapes almost everything else: cost, setup, revocation and the way mistakes show up.
The trust models
S/MIME, specified in RFC 8551, uses X.509 certificates. A certificate authority issues a certificate binding an email address to a public key, and your client accepts it because the chain leads to a root in its trust store. Validation also depends on revocation information, usually CRLs or OCSP. If the CA is careless or compromised, every certificate it issued is affected, which is why the choice of CA matters.
OpenPGP has no central authority. You generate your own key, and a contact decides how much to trust it. The options are direct fingerprint comparison, trust-on-first-use, or a web of trust in which other people sign keys they have verified. The model is decentralised. It asks more of the user, and it fails in a way that is easier to see: a key you never verified is simply unverified.
Comparison
| Aspect | S/MIME | OpenPGP |
|---|---|---|
| Trust anchor | Certificate authorities and root stores | Keys verified by the user, or signed by trusted people |
| Key issuance | Certificate from a CA, sometimes paid, sometimes limited free tiers | Generated locally, free |
| Validation | Chain validation plus CRL or OCSP revocation checks | Fingerprint comparison, signatures, expiry dates |
| Built-in support | Apple Mail, Outlook and many enterprise clients | Thunderbird (built-in OpenPGP), GnuPG, mutt and neomutt via GnuPG |
| Failure mode | A bad or compromised CA affects many certificates at once | An unverified key stays unverified; the user must notice |
| Recipient setup | Recipient needs your certificate, usually obtained when you send a signed message | Recipient needs your public key, from a key server, WKD or an attachment |
| Envelope headers | Visible | Visible |
Usability in practice
S/MIME is often the path of least resistance on a managed desktop. Once a certificate is installed, signing and encryption appear in the compose window, and recipients who already use S/MIME get readable mail without further steps. Certificates expire, usually after a year or a few years, and renewal is a recurring task that is easy to forget. Losing the private key or the certificate means losing access to old encrypted mail, so backups matter.
OpenPGP takes more effort at the start. You generate a key, choose a passphrase, create a revocation certificate and publish the public key where others can find it. The payoff is that the key is yours. There is no third party who can issue or revoke it on your behalf, and you can rotate subkeys without changing your identity. Expiry is still worth setting, because a key with no expiry lingers forever if you lose the private key.
Revocation and recovery
Revocation works differently in each model. With S/MIME the CA revokes the certificate and clients check that status, which depends on the CA publishing timely information. With OpenPGP you publish a revocation certificate that you generated when you created the key. Keep that revocation certificate offline. If you lose the private key without it, the old key remains valid for anyone who still trusts it.
Choosing between them
- Choose S/MIME when your organisation or your correspondents already use it, and the CA is one you trust.
- Choose OpenPGP when you want keys you control, verifiable without a third party, and compatibility with command-line tools.
- Do not expect either to hide who you are emailing. Both protect content, not envelope headers.
- Whichever you pick, back up private keys, record revocation material, and set expiry dates you will actually renew.
ITProMail documents its encryption options as OpenPGP keys and Web Key Directory publication. The setup steps are in the PGP documentation, and the practical side of key use is covered in PGP in practice.