When to Use End-to-End Encryption (PGP, S/MIME) vs Plain TLS

Every few months someone on the team asks whether the company should "encrypt its email". The answer is that it already is, in transit, and that end-to-end encryption is a separate, heavier tool that only a small fraction of messages need. Applying it everywhere would slow down every exchange and confuse most recipients. Here is a decision rule, the honest costs of PGP and S/MIME, and the alternatives that usually work better for a small business.

Quick answer

Use TLS-protected ordinary email (the default with any modern provider) for everyday correspondence. Use end-to-end encryption, or a secure link that expires, when the content would cause real harm if your provider, the recipient's provider, or a compromised mailbox exposed it: medical or legal files, credentials, financial account details, or anything a regulator classes as special-category data. Decide per message type, not per company.

What each layer protects

• TLS in transit: protects the connection between servers and apps. Both providers can still read the message; a compromised mailbox exposes everything in it.
• End-to-end encryption (PGP or S/MIME): the message body and attachments are encrypted with the recipient's public key before leaving your app and can be decrypted only with their private key. Providers see only the subject line and headers. A compromised mailbox without the private key exposes nothing readable.
• Secure link with expiry: the document stays on a server you control; the email carries only a link that stops working after a set time or number of downloads. Not end-to-end in the strict sense, but it removes the attachment from every mailbox it would otherwise sit in for years.

The decision rule

1. Ask: if this exact message were read by a stranger a year from now, would anyone be harmed or would we break a rule? If no, send it normally over TLS.
2. If yes, ask: does the recipient already use PGP or S/MIME, or can they be reasonably expected to? If yes, encrypt end to end.
3. If no, use a secure link with expiry and a password sent by another channel, or a shared workspace with its own login. This covers most client-document scenarios for small firms.
4. For credentials specifically (passwords, API keys), never put them in an email body at all; use the password manager's sharing feature or a one-time secret link.

PGP versus S/MIME in practice

• PGP (OpenPGP) uses keys you generate yourself and share directly or through keyservers. Free, decentralised, well supported in Thunderbird and via plugins for other clients. The hard part is key exchange and helping recipients set up.
• S/MIME uses certificates issued by a certificate authority, which mail clients such as Outlook and Apple Mail support natively. Easier for recipients who already have a certificate, and common in legal, healthcare, and government exchanges. Certificates cost money and expire, so someone must manage renewals.
• Both encrypt only the body and attachments. Subject lines, sender, recipient, and dates remain visible.
• Both require the recipient to have set up a key or certificate in advance. You cannot encrypt end to end to someone who has not.

The costs people underestimate

• Search and archives. Encrypted messages cannot be searched by content in webmail, and an archive of encrypted mail is unreadable if the private key is lost. Plan key backup before the first encrypted message.
• Mobile. Support for PGP and S/MIME on phones is uneven; expect some messages to be readable only on a desktop.
• Offboarding. If a leaver held the only copy of a private key, their encrypted mail is gone with them. Store keys in the password manager under company control.
• Recipient confusion. A first encrypted message often triggers a "this is broken" reply. Send a plain-text note beforehand.

What this looks like for a typical small business

Most firms end up with three tiers: ordinary mail over TLS through their business email provider, secure links for client documents, and end-to-end encryption for one or two relationships that require it (an accountant, a lawyer, a healthcare partner). OquMail covers the first tier for free on your own domain with IMAP and SMTP, which means desktop clients such as Thunderbird or Outlook that support PGP or S/MIME work with it for the third tier; the encryption happens in the client, not at the server, so it does not depend on the provider.

Common questions

Should we move the whole company to an "encrypted email" provider?

Those providers offer end-to-end encryption mainly between their own users; mail to anyone else still travels over ordinary TLS or via a password-protected link. If most of your correspondents are outside, you get the link-based experience anyway, which you can achieve with any provider and a file-sharing tool.

Is a password-protected PDF good enough?

Better than a plain attachment, provided the password travels by another channel and is long. Modern PDF encryption (AES-256) is strong; older PDF password schemes are weak. It still leaves the file in every mailbox it passes through, unlike an expiring link.

Does DKIM or DMARC encrypt anything?

No. They authenticate the sender and protect against spoofing. Encryption is a separate concern.