How to Encrypt Email in Gmail: TLS, S/MIME, and End-to-End

Knowing how to encrypt email in Gmail matters because Gmail’s default behavior protects less than most people assume. Messages move over an encrypted channel, but Google can read everything that lands in your inbox. Depending on your account type and who you’re emailing, Gmail offers three meaningfully different levels of protection — and confusing them leads to false confidence.

The short answer first, because it saves most readers the rest of the page: a personal @gmail.com account cannot send end-to-end encrypted mail using any Gmail setting. S/MIME and Client-Side Encryption are Google Workspace features on specific paid tiers, and Confidential Mode is not encryption at all. If you are on a personal account and need genuine end-to-end encryption, your options are layering PGP on top of Gmail or moving the sensitive traffic elsewhere; both are covered at the end of this page.

Which Level Can You Actually Use?

Level	What it protects	Who can use it	Can Google read it?
TLS (default)	The connection between mail servers	Everyone, automatically	Yes
Confidential Mode	Nothing cryptographically; limits forwarding and sets expiry	Everyone	Yes
Hosted S/MIME	Message content against outsiders and the recipient’s provider	Workspace: Frontline Plus, Enterprise Plus, Education Fundamentals/Standard/Plus	Yes — the private key is uploaded to Google
Client-Side Encryption	Message content, inline images and attachments	Workspace: Enterprise Plus, Education Plus, Education Standard, Frontline Plus	No — keys sit with an external key service your organisation controls
PGP via extension or client	Message bodies you encrypt yourself	Anyone, including personal accounts	No

Read that last column carefully, because it is where the marketing and the mechanics part company. Hosted S/MIME is genuine encryption against everyone except Google: the key pair is uploaded to Google in PKCS#12 form so Gmail can sign and decrypt on your behalf. Only Client-Side Encryption and your own PGP keep Google out, and only CSE does it without you managing keys by hand.

For the fuller answer to what Gmail’s defaults already do — and what “encrypted at rest” is worth when the provider holds the keys — see is Gmail encrypted.

What Gmail Encrypts by Default

Every message you send from Gmail travels over Transport Layer Security (TLS), which encrypts the connection between mail servers. When a recipient’s mail provider also supports TLS, your message is protected in transit. Gmail shows a gray lock icon in the compose window when this is active.

TLS has a hard limit: it secures the pipe, not the message. Once your email arrives at Google’s servers — or the recipient’s — it is decrypted and stored in plaintext (from Google’s perspective). If your threat model is a passive wiretapper on a public Wi-Fi network, TLS is sufficient. If your threat model includes Google itself, a subpoena to Google, or a breach of Google’s infrastructure, TLS does not help you.

A red open-lock icon in Gmail’s compose window means the recipient’s server does not support TLS at all. Do not send sensitive information in that case.

Confidential Mode Is Not Encryption

Gmail’s Confidential Mode is frequently marketed alongside encryption, but it is not encryption in any meaningful sense. When you send a confidential message, Gmail removes the email body and replaces it with a link to content stored on Google’s servers. The recipient clicks through to read it; they cannot forward, print, copy, or download it.

The limitations matter. Google still has full access to the content — the same servers, the same subpoena risk, the same access to your information. The protection Confidential Mode offers is against the recipient sharing your message, not against Google or a third party reading it. It also adds SMS passcode verification as an optional step, which is useful for confirming a recipient’s phone number but is not a cryptographic guarantee.

Confidential Mode is appropriate for internal business use where you want to limit accidental forwarding. It is not appropriate when you need actual confidentiality from Google or when legal protections for the message content matter.

S/MIME: Real Encryption for Workspace Accounts

S/MIME (Secure/Multipurpose Internet Mail Extensions) is the first option that provides genuine end-to-end encryption in Gmail. With S/MIME enabled, your message is encrypted using the recipient’s public key, and only the corresponding private key can decrypt it — so the message is opaque to everyone handling it in between, including the recipient’s mail provider. Gmail displays a green lock icon when hosted S/MIME is active. The word doing the work is hosted: your key pair is uploaded to Google in PKCS#12 form so Gmail can sign and decrypt for you, which means Google is inside the trust boundary even though nobody else is.

S/MIME is only available on Google Workspace plans — not on personal @gmail.com accounts. The relevant tiers are Frontline Plus, Enterprise Plus, Education Fundamentals, Education Standard, and Education Plus. Your Workspace administrator must enable it via the Admin console at Apps → Google Workspace → Gmail → User settings → S/MIME.

There is a practical friction point: S/MIME only works when both sender and recipient have exchanged digital certificates. Sending an S/MIME-encrypted email to someone without a certificate falls back to TLS or plaintext. This is manageable inside an organization where IT provisions certificates centrally; it is awkward for cross-organization communication.

Google offers two S/MIME modes. Hosted S/MIME stores your encryption key with Google — convenient, but Google retains key access. Client-Side Encryption goes further.

Client-Side Encryption: True End-to-End (Enterprise and Education)

Gmail Client-Side Encryption (CSE) is the highest encryption tier available in Gmail. Encryption happens in the browser before anything reaches Google’s servers, and the keys are controlled by your organization, not Google. Even if Google’s infrastructure were compromised, the message body, inline images, and attachments remain encrypted. Gmail shows a blue shield icon when CSE is active.

CSE is available on Enterprise Plus, Education Plus, Education Standard, and Frontline Plus plans. Users on “Assured Controls” plans can send CSE-encrypted messages to any recipient — including those on non-Gmail providers — without requiring the recipient to have S/MIME certificates. Recipients without Workspace accounts access the message via a guest account flow.

Several features are disabled when using CSE: Google AI products and smart features for Gmail (such as Smart Compose), delegated accounts, Confidential Mode, and email signatures. Attachments are capped at 5 MB.

In April 2025, Google announced a significant simplification: organizations no longer need complex certificate exchange infrastructure to send end-to-end encrypted email, even to non-Gmail recipients. This addressed the long-standing barrier that made enterprise E2EE impractical for most teams. By April 2026, CSE support extended to Gmail mobile on both Android and iOS.

Which Level Do You Actually Need?

The right answer depends on your threat model, not on which option sounds most secure. If you have not framed that yet, do you actually need encrypted email walks through the cases where the upgrade is worth the disruption and the cases where it is not.

TLS (default) is adequate when your concern is passive interception in transit and the recipient’s server also supports TLS. This covers most everyday email — it is not nothing. The gray lock means the connection is encrypted.

Confidential Mode is adequate when you want to limit forwarding and set message expiry within Gmail. It is not appropriate when confidentiality from Google is the goal.

S/MIME is appropriate for regulated industries — healthcare, legal, finance — where end-to-end encryption is a compliance requirement and both parties can manage certificates. Google Workspace makes this operationally reasonable for organizations willing to invest in certificate management.

Client-Side Encryption is appropriate when the organization needs a guarantee that even Google cannot access message content — think government, defense contractors, journalism organizations working with sensitive sources, or any context where a government subpoena to Google should not be sufficient to expose your communications.

If you are a personal Gmail user who needs genuine end-to-end encrypted email, none of these options fully serve you. Personal accounts do not have access to S/MIME or CSE. The practical alternatives are moving to a dedicated encrypted email provider, which the Proton Mail vs Tutanota comparison works through, or keeping Gmail and layering PGP on top of it through a browser extension, which the PGP email encryption setup guide covers step by step. If you decide to move, migrating from Gmail without losing your mail is the sequence that avoids locking yourself out of accounts.

One caveat that applies at every level above: none of them hide the envelope. Sender, recipient, timestamps, the routing path and — in most implementations — the subject line travel in clear text regardless of how the body is encrypted. What email metadata leaks sets out how much of a conversation survives encryption. The part of the envelope you can control is the address you hand out in the first place: a forwarding service puts a disposable address on the sender line instead of your real one, and the addy.io alias guide covers how that works, including replying from an alias so the reply does not expose the account behind it.

If you would rather answer a few questions than weigh five options, the find-your-setup wizard turns your constraints into a provider and alias plan.

Related across the network

• Signal vs Telegram Privacy: What the Encryption Gap Means — anonguide.com
• How to Remove Personal Info from Google Search Results — anonguide.com