How to Encrypt Email in Microsoft 365 and Google Workspace

Exchange Online and Gmail both use Transport Layer Security (TLS) when they exchange mail with another server that supports it. TLS encrypts the connection, so the message cannot be read while it travels between those two servers. Gmail shows a red open padlock when a message was not protected by TLS.

TLS is opportunistic by default: if the other server does not support it, mail may be delivered without it unless an administrator requires TLS for that domain. More importantly, TLS ends at each server. The message is stored in readable form in the sender’s and recipient’s mailboxes, in journaling and archive systems, and on any server that relays it. Our comparison of transport encryption and message encryption explains the difference.

For routine correspondence, TLS is a sensible baseline. For contracts, health or financial records, legal matters and other personal data, most organizations want protection that stays with the message itself.

Microsoft Purview Message Encryption

Included with some Microsoft 365 plans, Microsoft Purview Message Encryption lets users apply an encrypt option in Outlook, and lets administrators apply it automatically with mail flow rules. Recipients outside Microsoft 365 receive a message with a link, then sign in or request a one-time passcode to read it in a browser. It works well for occasional exchanges with people who have no encryption software of their own, but it uses Microsoft’s own format rather than PGP or S/MIME.

S/MIME in Outlook

Outlook supports S/MIME natively. Each sender needs an X.509 certificate and private key, and the recipient’s certificate must be available before a message can be encrypted to them, usually from a directory or from an earlier signed message. Issuing and renewing certificates for every user and device is the main obstacle; our guide to S/MIME certificate expiration and renewal explains what that involves over time.

PGP

Microsoft 365 has no built-in OpenPGP support. Users can install third-party add-ins, but keys then live on individual devices, and encryption depends on each user remembering to apply it.

Hosted S/MIME

Some Google Workspace editions support hosted S/MIME. Administrators enable it and upload user certificates, and Gmail encrypts a message when it holds the recipient’s certificate, typically after receiving a signed message from them.

Client-side encryption

Gmail client-side encryption, available in certain Enterprise and Education editions, encrypts message content in the browser with keys held in an external key service that the organization controls. It suits organizations with strict key-custody requirements, but it requires identity-provider and key-service configuration, and external recipients need a compatible way to read the message.

Confidential mode is not encryption

Gmail’s confidential mode can disable forwarding, copying and printing and set an expiry date. It does not encrypt the message to the recipient with S/MIME or PGP, so it should not be relied on for regulated data. Like Microsoft 365, Gmail has no native OpenPGP support.

Built-in tools are designed around each platform’s own users. Organizations tend to outgrow them when:

• partners, regulators or customers require PGP, which neither platform provides;
• the same policy must apply across both platforms, or across several mail systems after a merger;
• keys and certificates must be generated, published, looked up and renewed centrally rather than on each device;
• recipients without PGP or S/MIME need alternatives, such as a secure portal or an encrypted PDF, chosen by policy.

In that model, the mail platform hands outbound messages to a cloud encryption service through an outbound connector in Microsoft 365, or an outbound gateway or routing rule in Google Workspace. The service applies policy, finds recipient keys and certificates, and delivers the message, while users keep their usual mail client. Our guide to integrating email encryption with Microsoft 365 and Google Workspace covers the routing, and how cloud email encryption works walks through each step.

1. Classify what needs protection. Identify the message types, recipients and regulations that call for message-level encryption.
2. List partner requirements. Record which partners use PGP, which use S/MIME and which use neither.
3. Enforce TLS where you can. Require TLS for important partner domains as a baseline.
4. Choose a method per audience. Use built-in tools where they are enough, and route the rest through a gateway that supports both standards.
5. Pilot, then expand. Start with one department or rule, confirm delivery and replies with real partners, then widen the policy.

CloudPGP provides cloud-hosted PGP email encryption and cloud-hosted S/MIME email encryption behind Microsoft 365 and Google Workspace, so both standards can be applied by central policy without client add-ins.