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

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.

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 before it leaves your browser using the recipient’s public key, and only the recipient’s private key can decrypt it. Google cannot read the content. Gmail displays a green lock icon when hosted S/MIME is active.

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.

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 like Proton Mail or Tuta, or using a PGP-based workflow via a browser extension. Both routes are covered in detail elsewhere on this site.

For context on the broader risk landscape around email and AI-based threats, AI Alert ↗ tracks vulnerabilities and incidents relevant to communication security, including emerging attacks that bypass email authentication controls.

Sources

• Learn how Gmail encrypts your emails ↗ — Google’s official documentation covering TLS, S/MIME, and the lock icon indicators. Primary reference for default encryption behavior.

• Learn about Gmail Client-side encryption ↗ — Official feature documentation covering CSE availability by plan, technical constraints (attachment limits, blocked file types, disabled features), and how the blue shield icon works.

• Gmail: Bringing easy end-to-end encryption to all businesses ↗ — Google Workspace blog post announcing simplified E2EE without certificate infrastructure, including the April 2025 beta rollout and timeline for non-Gmail recipients.

• Gmail end-to-end encryption now available on mobile devices ↗ — Google Workspace Updates confirming April 2026 extension of CSE to Android and iOS Gmail apps.