S/MIME and PGP: two approaches to email encryption

SPF, DKIM, and DMARC confirm that a message came from whoever is listed in the From field. They say nothing about the content. Any server along the route can read the message body if it wants to. Encryption solves a different problem: making the text unreadable to everyone except the sender and recipient. Two standards have handled this since the 1990s - S/MIME and PGP. Both work. Both are genuinely different in how they approach trust and key management.

What email encryption actually protects

SMTP was designed in 1982. The protocol sends messages in plain text. TLS between mail servers (opportunistic STARTTLS or MTA-STS) encrypts the connection, but not the message itself. Once the message lands on the receiving server, it sits there unencrypted. The server admin, a court order, or a breach can expose every word.

End-to-end encryption changes the model. The message is encrypted on the sender’s device and decrypted only on the recipient’s device. The mail server stores ciphertext. Even if somebody intercepts the message in transit or dumps the mailbox database, they get unreadable bytes.

Two standards have survived since the 1990s: S/MIME (Secure / Multipurpose Internet Mail Extensions) and PGP (Pretty Good Privacy), now most commonly used through its open specification OpenPGP. They solve the same problem - encrypting and signing email - but differ in how they handle trust and key distribution.

S/MIME: certificates from a central authority

S/MIME relies on X.509 certificates, the same PKI infrastructure used for HTTPS. A Certificate Authority (CA) verifies your identity and issues a certificate that binds your email address to a public key. The private key stays on your device.

The flow for sending an encrypted message:

1. You obtain the recipient’s S/MIME certificate (usually received automatically when they send you a signed message).
2. Your mail client encrypts the body and attachments using the recipient’s public key.
3. Only the recipient’s private key can decrypt the message.

For signing (proving the message was not altered and really came from you), the direction reverses: you sign with your private key, and anyone with your certificate can verify.

Where to get an S/MIME certificate

As of 2026, free S/MIME certificates have largely disappeared. Actalis still offers free ones for personal use (email validation only, 1-year validity). For organizations, DigiCert, Sectigo, and GlobalSign sell S/MIME certificates starting around $20-40/year per address. Enterprise plans with centralized management cost more but simplify deployment across hundreds of mailboxes.

Client support

This is the main strength of S/MIME. Outlook (desktop and web), Apple Mail, iOS Mail, and Thunderbird support it natively. No plugins needed. Gmail supports S/MIME too, but only for Google Workspace accounts on Business Plus, Enterprise, or Education plans - it does not work with free Gmail. Once the certificate is installed, signing and encrypting happen through the standard compose window, usually with a lock icon or a ribbon badge.

Limitations

• Certificate cost. For a team of 50 people, $30/year per person adds up. The budget is not enormous, but it is not zero.
• Key escrow risk. Some CAs or enterprise deployments archive private keys. If the archive is compromised, past messages can be decrypted. Forward secrecy is not part of the S/MIME standard.
• Certificate expiration. Certificates expire (usually after 1-3 years). Old messages signed with them may show warnings, and encrypting to an expired certificate fails. Renewal is a manual process unless you have an MDM or certificate lifecycle tool.
• Centralized trust. If a CA is compromised or issues a fraudulent certificate, the whole chain breaks. This has happened before with HTTPS CAs, and the S/MIME ecosystem is smaller and less audited.

PGP / OpenPGP: decentralized trust

Phil Zimmermann released PGP in 1991. The core idea: no central authority. You generate a key pair yourself. You publish the public key (on a keyserver, your website, or directly to contacts). Trust comes from a “web of trust” - other people sign your key to vouch for its authenticity - or through direct verification, like comparing fingerprints over a phone call.

The modern open specification is OpenPGP (RFC 9580, updated in 2024). GnuPG (GPG) is the most common free implementation. Others include Sequoia PGP and the OpenPGP.js library used by Proton Mail.

How encryption works

Mechanically, PGP encryption is similar to S/MIME: a symmetric session key encrypts the message body, and the session key itself is encrypted with the recipient’s public key. Signing uses the sender’s private key. The difference is not in the cryptography but in key management.

Key distribution: the hard part

S/MIME piggybacks on the CA infrastructure that already exists for the web. PGP has no such luxury. Getting someone’s public key reliably is the central challenge. The classic SKS keyserver network had real problems: no identity verification, certificate flooding attacks, and GDPR conflicts. Modern alternatives are better: keys.openpgp.org requires email verification before publishing, and WKD (Web Key Directory) lets domains serve keys over HTTPS at a well-known path.

WKD lookup example for alice@example.com:

GET https://openpgpkey.example.com/.well-known/openpgpkey/example.com/hu/<hash>
# or direct method:
GET https://example.com/.well-known/openpgpkey/hu/<hash>

If your organization controls its DNS and web server, setting up WKD takes about an hour. After that, any OpenPGP-compatible client can fetch your team’s keys automatically, without manual import.

Client support

This is PGP’s weakness. Outlook does not support OpenPGP natively. Apple Mail does not either. Thunderbird is the major desktop client with built-in OpenPGP support (since version 78). For other clients, you need plugins: Gpg4win with GpgOL for Outlook on Windows, GPGMail for Apple Mail (paid, from GPGTools). On mobile, options are sparse: OpenKeychain on Android works with K-9 Mail / Thunderbird for Android; on iOS, PGP support barely exists.

Web-based solutions like Proton Mail and Mailvelope (a browser extension for Gmail and others) hide the complexity behind a simpler interface. Proton Mail makes PGP transparent: users encrypt and decrypt without ever touching a key management dialog. That only works between Proton users or when the external recipient has published an OpenPGP key.

S/MIME vs. PGP: direct comparison

Neither protocol is strictly better. S/MIME wins on ease of deployment in corporate environments where Outlook or Apple Mail is standard. PGP wins on cost, decentralization, and flexibility for technical users who distrust centralized CAs.

When encryption is actually necessary

Most marketing sends don’t need encryption. You are not transmitting secrets in a 15%-off promo. Encryption makes sense when the message content has value to third parties or when a leak causes real damage.

Scenarios where it is justified:

• Personal data under GDPR. Sending a colleague or partner a file with passport details, medical records, or financial data. The regulation requires appropriate protective measures, and email encryption is one of them.
• Legal correspondence. Attorney-client privilege does not hold if a mail server admin can read the thread. Many law firms in the US and Europe use S/MIME for corporate email for exactly this reason.
• Financial reporting. Quarterly results before public announcement, M&A documents, internal forecasts - anything that moves a stock price.
• Journalism and activism. Source protection. Whistleblower channels at The Guardian, The New York Times, and ProPublica all publish PGP keys for secure contact.
• Defense and government. Encryption is often mandated by sector standards here, not left to individual choice.

When encryption is overkill

A marketing newsletter is an open message - you want people to read it. Encrypting it only hurts: a recipient without the right key sees an unreadable blob instead of your content. Bulk sending of encrypted email is technically possible (each message encrypted with each recipient’s key separately), but no ESP supports it and there is no point.

Transactional messages - receipts, registration confirmations, password resets - are also typically not encrypted. TLS between servers covers transit. MTA-STS makes TLS mandatory rather than optional. For most transactional scenarios, that is enough. To verify TLS is actually in use, set up MTA-STS for your domain and monitor TLS-RPT reports.

Practical setup: S/MIME in Outlook

For an organization where Outlook is the standard client, S/MIME is the least painful path. Here is what the setup looks like:

1. Buy S/MIME certificates from a CA (Sectigo, DigiCert). For organizations, an Organization Validated (OV) certificate shows the company name in the signature.
2. Export the certificate as a .pfx file (PKCS#12). The file contains both the public certificate and the private key, protected by a password.
3. Import the .pfx into the Windows Certificate Store, or deploy via Active Directory / Intune for centralized management.
4. In Outlook: File → Options → Trust Center → Email Security → select the certificate for signing and encryption.
5. Send a signed message to a colleague. They receive your public certificate automatically and can now encrypt messages to you.

In Microsoft 365 Admin Center you can enable S/MIME organization-wide, upload root and intermediate CA certificates, and set a policy to sign all outgoing mail by default and encrypt when the recipient’s certificate is available.

Practical setup: PGP in Thunderbird

Thunderbird is the only major client with built-in OpenPGP support (no plugins). Setup:

1. Account Settings → End-To-End Encryption → Add Key. Generate a new key or import an existing one.
2. Recommended parameters: Ed25519 for signing, Curve25519 for encryption. If you need compatibility with older systems, RSA 4096.
3. Publish your public key: export as a .asc file and upload to keys.openpgp.org. Or configure WKD on your domain.
4. To send an encrypted message: import the recipient’s public key. Thunderbird can look up keys automatically via WKD and keys.openpgp.org.

# Generate key via GPG CLI
gpg --quick-gen-key "Alice Smith <alice@example.com>" ed25519 sign 2y
gpg --quick-add-key <fingerprint> cv25519 encrypt 2y

# Export public key
gpg --armor --export alice@example.com > alice-public.asc

# WKD setup (direct method)
# Place the file at:
# https://example.com/.well-known/openpgpkey/hu/<sha1-hash-of-localpart>

Common mistakes when deploying encryption

• No private key backup. An employee reinstalls their OS and the key is gone. Every encrypted message they received is permanently unreadable. For S/MIME: export the .pfx and store it somewhere secure. For PGP: export the private key (gpg --export-secret-keys) and keep it on an encrypted drive.
• Encrypting without signing. Encryption hides content but does not prove who sent it. Without a signature, the recipient cannot verify the encrypted message actually came from you. Always sign.
• Storing keys on the mail server. Some solutions offer server-side encryption where the key lives on the server and encryption/decryption happens there. That is not end-to-end. Compromise the server and you expose everything. Keys belong on the user’s device.
• Forgetting the subject line. Neither S/MIME nor PGP encrypts the Subject header. It travels in plain text. If your subject reads “Confidential: Acquisition of X”, encrypting the body does nothing. Keep subjects neutral.
• Not checking the recipient can decrypt. Send an encrypted message to someone without a configured key and they see a smime.p7m attachment with no idea what to do with it. Confirm both sides are set up before you rely on encryption.

Encryption and authentication are different jobs

Confusing the two is common. SPF, DKIM, and DMARC are authentication: they confirm the message came from a legitimate sender and was not tampered with in transit. They do not hide the content. S/MIME and PGP operate at the message level: the content is closed to outsiders, and the signature ties authorship to a specific person (not a domain, but the key holder).

For bulk sending, you need authentication: SPF, DKIM, DMARC, possibly BIMI. For confidential one-to-one correspondence, you need encryption. These are not mutually exclusive. An OpenPGP-encrypted message still passes SPF/DKIM checks, because those checks operate on headers and the envelope, not the body.

Alternatives: when email is the wrong channel

If S/MIME or PGP feels like too much overhead for the task, there are simpler options. A secure portal (send a link to a document behind authentication), E2EE messengers like Signal, or encrypted file-sharing services. For a one-off confidential document transfer, a portal approach is easier than deploying PKI.

But if confidential correspondence is a regular part of your work (law, medicine, finance), the investment in S/MIME or PGP pays off. Configure it once and every message is protected automatically. No links, no portals, no extra steps per send.

Bottom line

S/MIME fits organizations where Outlook or Apple Mail is standard, there is budget for certificates, and centralized management through AD/MDM matters. PGP fits technically minded users, journalists, developers, and organizations that want no dependency on a central CA. Both standards handle encryption. Neither handles deliverability.

An encrypted message sent to a nonexistent address bounces exactly like an unencrypted one. Encryption protects content. Authentication protects reputation. A clean address list ensures delivery. Three separate layers, each doing its own job.