Start with the recipient and the information
Email encryption works best when the sender and recipient agree on a supported method before the sensitive message is composed. Decide who may read the information, which devices they will use, and whether an organization requires a particular delivery service. Send only the information needed for the task.
A padlock can describe a connection, a message or a portal session. Ask where decryption happens and who controls the keys. That answer tells you whether a mail provider or organizational gateway can read the content along the way.
| Approach | What it protects | What to establish |
|---|---|---|
| Transport TLS | The connection between participating mail systems or a client and server. | Whether protection is required on the relevant hops; mail systems can still process readable content. |
| S/MIME | Message content encrypted for certificate holders; signatures can verify signed content. | Compatible clients, recipient certificates and the organization’s certificate and recovery process. |
| OpenPGP | Message content encrypted to recipient keys; signatures use a signing key. | Compatible implementations and a trusted way to verify the public key. |
| Secure portal | Content accessed inside a service after the recipient follows a notification. | Recipient authentication, service access, expiry, downloads and retention. |
On a narrow screen, scroll the table sideways. Keyboard users can focus the table and use the arrow keys.
Choose the simplest approved workflow that both parties can complete. A person who cannot open an encrypted attachment may improvise an unsafe workaround; a rehearsal reveals that problem early.
Connect the key to the right person
S/MIME 4.0 describes cryptographic protection for MIME messages, using certificates as part of the system. Validate the intended address, certificate status and trust chain through the supported client. Follow the administrator’s process when a certificate changes.
OpenPGP defines message formats and key handling. A public key found in a directory still needs a trustworthy association with the person. Compare its fingerprint through an established contact route and record the verification in the client where supported. Keep the private key private.
Treat an unexpected key change as a reason to recheck through a known phone number or another independently trusted channel. A new device or planned renewal may explain it. A display name, familiar avatar or email containing a replacement key supplies too little evidence by itself.
Rehearse a complete exchange
- Confirm the recipient and method through an established contact route. Record the client or service and the devices being tested.
- Set up keys or certificates using the product’s current instructions. Arrange protected recovery before relying on the account for important records.
- Compose harmless sample text, add a harmless attachment and explicitly select the supported encryption option. Check the final recipients after autocomplete has finished.
- Have the recipient open the message and attachment on their intended device. Ask them to reply using the same protected workflow; inspect the received reply’s security details.
- Inspect subject lines, notifications, quoted replies, sent-mail copies and downloads. Record which parts remain visible and where plaintext copies appear.
- Confirm that the sender can reopen the sent message and that the approved recovery process works in a controlled test. Document the result without copying private keys into the test record.
Thunderbird provides one concrete implementation: its OpenPGP HOWTO and FAQ explains key acceptance and backing up a secret key. Follow the current instructions for your installed version; another client may use different controls.
Header protection depends on the implemented format and client behavior. RFC 9788 specifies protection for email headers, but a standard’s existence does not establish that a particular pair of clients implements it. Keep sensitive details out of the subject until you have checked the actual exchange.
Work through a recipient compatibility problem
The useful result is a verified handoff: the expected person obtained the expected document using the agreed protection. A successful send operation establishes only one step.
Resolve failures without losing protection
- If the client reports an unusable recipient key, check the address, expiry, revocation and verification status. Obtain a replacement through a trusted route.
- If an attachment fails, test the supported format and size with harmless content. Use the approved alternate channel when compatibility cannot be resolved.
- If an old message becomes unreadable after migration, check whether its original decryption key is available through approved recovery. A new key generally cannot decrypt content addressed only to an old key.
- If a message goes to the wrong person, revoke portal access where available and promptly follow the information owner’s incident process. Account for copies already obtained.
For regulated or organizational information, confirm the applicable policy with its owner. Encryption is one control within a larger process involving identity, access, retention and incident response.
Keep a usable review record
Download the email exchange test record (plain text). Save a copy, fill it out in a text editor, and keep it with your approved project records.