How to send encrypted email (and when you actually need to)

"Encrypted email" covers several different things, protecting against different threats. Knowing which one you need saves both effort and false confidence.

Sending a document securely

1. Confirm the transport is encrypted. Any reputable provider uses TLS between client and server, and opportunistic TLS between servers. This is the baseline and needs no action from you.
2. Decide whether transport encryption is enough. For routine business correspondence, it usually is. For contracts, health information, credentials or identity documents, it is not.
3. Protect the content itself. Put the document in a password-protected archive or an encrypted PDF, or share it as a link with a password and an expiry date.
4. Send the password through a different channel — a phone call or a messaging app. A password in the same thread protects nothing.
5. For ongoing confidential correspondence, set up S/MIME or PGP with the other party once, and every message thereafter is encrypted end to end.
6. Set expiry and revoke access when the matter is closed, if your sharing tool supports it.

What each layer protects

TLS protects messages in transit. It does not protect them at rest on either server, and you cannot verify how the recipient's provider handles them afterwards.

Password-protected files and links protect the content wherever it travels — including through forwards and backups. This is the practical option for occasional sensitive documents, because it requires nothing of the recipient beyond a password.

S/MIME encrypts and signs messages using certificates. Well supported in corporate mail clients; requires a certificate per person and some administration.

PGP offers the same guarantees without a central authority, at the cost of manual key exchange. Excellent between technical correspondents, awkward with everyone else.

Choosing in practice

Most organisations do not need end-to-end encryption for everything, and pretending otherwise leads to it being switched off. A workable policy: TLS for everything by default; password-protected files or expiring links for anything confidential; S/MIME or PGP for the specific relationships that justify the setup — legal counsel, auditors, a regulator.

Remember what encryption does not solve. It does not protect against a compromised mailbox, a forwarded message or a screenshot. Access control and two-factor authentication matter at least as much as ciphers.

Frequently asked questions

Is my mail encrypted by default? In transit, almost always. At rest and end to end, only if you or your provider add that layer explicitly.

Do both sides need the same software? For S/MIME and PGP, yes — both parties need keys or certificates. Password-protected files and links work with any recipient.

Is a password-protected ZIP secure enough? With a strong algorithm and a long password shared separately, it is adequate for most business material. It is not a substitute for end-to-end encryption in high-risk cases.

Does encryption stop phishing? No. Phishing targets people, not ciphers — see how to spot phishing emails.

Confidential sending with imail

imail supports password-protected sharing for sensitive files alongside TLS-encrypted connections; the features page has the details. Turning on two-factor authentication is the other half of the job. To get started, create a free account.