Posted on

How to Send Encrypted Email from Gmail

send encrypted email from gmail guide featured image

🔑 Key Takeaways

  • Free Gmail only has TLS in transit; Google still reads the stored copy in every mailbox.
  • Hosted S/MIME ships on Enterprise Plus and Education tiers; Business Starter and Standard skip it.
  • Confidential Mode blocks forwarding and prints but the body sits readable inside Google storage.
  • Cross-provider encryption needs shared keys or a portal service that both sides can open.
  • Google BAA covers storage and transport; a gateway BAA closes the recipient mailbox gap.

Gmail handles more than 1.8 billion active accounts, and a large share of small healthcare practices, therapists, and specialty clinics run their day-to-day communication through it. The default protection is TLS in transit, which is not the same as end-to-end message encryption.

To send encrypted email from Gmail in a way that satisfies HIPAA or protects sensitive content from mailbox breaches, you need to add a layer on top of the default setup. Google offers two native options, S/MIME on select Workspace tiers and Confidential Mode on all tiers, and a third-party route sits above both.

This guide walks through each option with the exact console clicks, the tier requirements, and the cases where each method fits. It also covers the cross-provider gap that catches most senders on the first try.

Gmail Uses TLS in Transit, Not Content Encryption

Standard Gmail encrypts the connection between Google and the receiving mail server using opportunistic TLS. If the receiving server accepts TLS, the message is protected on the wire. If the receiving server does not support TLS, the message drops to plaintext for that hop.

Once the message arrives at the destination mailbox, the TLS protection ends. The message body is stored in the recipient mailbox in a form the mail provider can read. The same applies to the copy in your Sent folder.

TLS in transit does not meet the HIPAA requirement for end-to-end protection of PHI. It also does not protect against a mailbox breach on either side. A stolen password or a compromised admin session exposes every message in the account.

For content-level encryption you have three native or near-native paths from Gmail. S/MIME through Workspace, Confidential Mode, or a third-party plugin or gateway. Each has a different security ceiling and a different setup cost.

S/MIME Requires a Supported Google Workspace Tier

Hosted S/MIME in Gmail is available on Google Workspace Enterprise Plus, Education Standard, and Education Plus. Business Starter, Business Standard, and Business Plus do not include it. Personal Gmail accounts do not include it either.

To enable it, an admin signs in to the Google Admin console, opens Apps, selects Google Workspace, then Gmail, then User settings. The S/MIME section allows the admin to enable the feature for specific organizational units.

Each user then needs a valid S/MIME certificate issued by a public certificate authority or a private CA integrated with the tenant. The certificate is uploaded to the user profile, either manually or through an API integration with the CA.

Once the certificate is in place, the Gmail composer shows a lock icon in the address field. The icon turns green when the recipient public certificate is known to Google. If the recipient has never sent an S/MIME message to your organization, the lock stays gray.

send encrypted email from gmail in article illustration one

Confidential Mode Is Access Control, Not Encryption

Confidential Mode sits in the Gmail composer next to the send button. Click the lock and clock icon, set an expiration date, and optionally require an SMS passcode. The recipient sees the message with forwarding, printing, and copy disabled.

The message content itself is not encrypted. It sits in Google storage in a form Google can read, and the recipient views it through a Google-hosted preview page. The expiration date deletes the preview link, but the underlying copy in Sent Mail remains in your account.

Confidential Mode is useful for reducing casual forwarding and setting a self-destruct on a routine message. It is not a substitute for encryption when PHI or regulated data is involved.

The Department of Health and Human Services has been consistent that HIPAA requires content-level protection of PHI at rest and in transit. Confidential Mode does not meet that bar on its own. Reference the HHS Security Rule guidance if you need the underlying text.

Google Signs a BAA for Paid Workspace Tiers Only

Google will sign a Business Associate Agreement for Business Starter, Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Education Standard, and Education Plus. The BAA is opt-in through the Admin console under Account, then Legal and Compliance.

The BAA does not extend to personal Gmail accounts. Sending PHI from a free Gmail address is a HIPAA violation regardless of what encryption method you layer on top. The mail provider itself has to be under a BAA.

The Google BAA covers Google storage and transport. It does not cover the recipient mailbox, the recipient mail server, or any downstream forwarding by the recipient. Once the message leaves Google, the Google BAA no longer applies.

That is why message-level encryption matters. TLS protects the wire between Google and the next hop. Message-level encryption protects the content itself all the way through to the intended reader.

Example A five-therapist behavioral health group runs Google Workspace Business Standard at $14 per user per month. Upgrading every seat to Enterprise Plus for S/MIME would add roughly $150 per user per month, or $9,000 per year on top of the base plan. Instead the practice layers a portal-based gateway at $9 per user per month, keeps the existing Workspace BAA, and adds a second BAA with the gateway vendor. Patients read encrypted messages through a browser link with a passcode. Total encryption spend lands near $540 per year.

PGP Requires Key Exchange with the Recipient

PGP is a public-key encryption system that predates S/MIME by several years. It works well between two technical users who have exchanged public keys, and it works poorly at scale across a healthcare organization.

On Gmail, PGP is delivered through browser extensions like FlowCrypt or through a desktop client that syncs with Gmail over IMAP. The sender private key stays on the local device. The recipient needs the same tooling and needs to import your public key before decrypting.

Key management is the friction point. Every new recipient needs a public key exchange. Every device change needs the private key transferred securely. Lost private keys mean lost access to every previously encrypted message.

PGP is not a good fit for a clinical staff workflow where messages go to dozens of external patients, insurance carriers, and referral partners per week. It fits a small circle of technical users. It does not fit a front-desk workflow.

Cross-Provider Encryption Breaks Without a Shared Method

The hard case is sending an encrypted message from Gmail to a Yahoo, Outlook.com, or AOL account. None of those recipients typically has an S/MIME certificate on file. None of them typically has PGP tooling installed. A Confidential Mode message drops to a preview link the recipient may not trust.

The workable pattern for cross-provider encryption is a portal-based encrypted email service. The service intercepts the outbound message, encrypts the payload with a key held on its servers, and sends the recipient a link to a hosted decryption page.

The recipient clicks the link, authenticates with a passcode or email verification, and reads the message in a browser session. The message never lands in the recipient mailbox in decrypted form. Only the link and the metadata do.

This is the same pattern Microsoft uses with Purview Message Encryption for Outlook. It is provider-agnostic on the recipient side, which is why it works for cross-provider sending.

send encrypted email from gmail in article illustration two

Third-Party Services Work with Existing Gmail Accounts

A HIPAA-compliant encrypted email service usually plugs into Gmail one of two ways. The first is a Chrome extension that adds an encrypt button to the composer. The second is a routing configuration in Google Admin that sends outbound mail through the service gateway.

The extension approach fits solo practitioners and small teams. The user installs the extension, signs in to the service account, and gets a new send button next to the standard Gmail send button. The clinical staff experience stays inside Gmail.

The gateway approach fits larger practices with a Workspace admin. Outbound mail from designated accounts is routed through the service SMTP relay, which applies encryption based on the recipient domain or a keyword in the subject line.

Mailhippo uses this pattern. Users keep their existing Gmail account, the recipient gets a portal link, and Mailhippo signs a BAA that covers the encrypted mail path. No S/MIME certificates and no key exchange with the recipient.

Client-Side Encryption Keeps Keys Outside Google

Google Workspace Enterprise Plus offers client-side encryption, or CSE, for Gmail. Keys are held by an external key service that the customer controls, and Google never sees the plaintext of the message or the encryption key.

CSE is designed for regulated customers who need to prove that the mail provider cannot decrypt their messages even under legal request. Government agencies, defense contractors, and some large healthcare systems fit the profile.

The setup cost is significant. The admin has to stand up or contract with a Key Access Control List Service that speaks the Google CSE API, then configure each user account to use it. External recipients need matching CSE tooling, which limits interoperability.

CSE is the right choice for a small subset of Enterprise Plus customers with an existing key management infrastructure. It is not a first-move option for a typical outpatient clinic on Business Standard.

💡Pro Tip: Block outbound send when the S/MIME lock stays grayThe Gmail composer shows a gray lock when the recipient certificate is not on file, and the message goes out over TLS only. Staff assume the lock means safe and send PHI unencrypted. Set a tenant DLP rule in the Admin console that blocks outbound send from PHI-handling accounts when the S/MIME lock is not green. Route those messages to a portal-based gateway as a fallback. This removes the single most common failure mode in a Workspace S/MIME deployment.

Mobile Gmail Sends Encrypted Messages Through the Same Paths

The Gmail mobile app on iOS and Android supports Confidential Mode natively. Tap the three-dot menu in the composer and select Confidential Mode. The expiration and passcode options are the same as on desktop.

S/MIME on mobile requires a Workspace tier that supports it plus a certificate provisioned to the mobile device. iOS handles certificate installation through a configuration profile pushed by MDM. Android handles it through the enterprise container.

Third-party encryption services that offer a Chrome extension do not run on the Gmail mobile app. Their mobile support is usually a standalone iOS or Android app that composes an encrypted message and sends it through the service directly.

For a clinical staff workflow where phones and tablets are common, verify the mobile path before rolling out the desktop-first setup. A method that works on the browser but not on a phone will not survive contact with actual daily use.

Practical Setup Order for a Small Healthcare Practice

Start with the BAA. Confirm the Google Workspace tier and enable the BAA in the Admin console. A personal Gmail account is not a starting point for PHI. Move to Workspace first.

Second, decide on the encryption method based on tier. If the practice is on Enterprise Plus and has an existing PKI, S/MIME is a clean fit. If the practice is on Business Standard or Business Plus, a third-party service is the shorter path than upgrading every seat to Enterprise Plus.

Third, train the front desk on the send workflow. The most common failure mode is a staff member forgetting the encrypt button and sending PHI in cleartext. A gateway that encrypts based on recipient domain or subject keyword removes that human step.

For related work on other clients, see the send a encrypted email from outlook guide and the how to send encrypted email from yahoo account reference. For a mobile-first walkthrough, see how to send an encrypted email from phone. Practices building out the broader digital stack for patient trust often pair encrypted email with a locked-down healthcare website security posture and a HIPAA-aware healthcare website design.

Common Failure Modes and How to Avoid Them

The most common failure is treating Confidential Mode as encryption. Front-desk staff assume the lock icon means the message is safe. It reduces forwarding but leaves the body readable to Google. Document the difference in the staff handbook.

The second is sending PHI from a personal Gmail account. There is no BAA, so any PHI in the message is a breach the moment it is sent. Migrate every clinical account to Workspace and disable personal Gmail forwarding.

The third is assuming S/MIME works when the recipient public certificate is not on file. The lock icon stays gray and the message goes out with TLS only. Set the tenant policy to block outbound send on the gray-lock state for accounts that handle PHI.

See the NIST SP 800-177 Rev 1 guidance on trustworthy email for the underlying reasoning on why TLS alone is not sufficient. The HIPAA Journal encryption requirements page summarizes the practical bar for covered entities.

  • Confirm your Workspace tier before assuming S/MIME is available.
  • Sign the Google BAA in the Admin console under Account, Legal and Compliance.
  • Never send PHI from a personal Gmail account.
  • Use Confidential Mode as a policy control, not as encryption.
  • Verify the mobile path before rolling out the desktop workflow.
  • Test S/MIME by exchanging a signed message with the recipient first, then encrypt.
  • Set a tenant policy that blocks unencrypted send for accounts that handle PHI.
  • Route outbound PHI mail through a gateway with a recipient-domain rule.
  • Keep the encrypt button visible in the composer to reduce human error.
  • Audit sent-folder contents monthly for accidental unencrypted PHI.
Posted on

Best Encrypted Email Options Compared for Real-World Use

best encrypted email guide featured image

🔑 Key Takeaways

  • No single best product; the right pick depends on device, recipient mix, and compliance scope.
  • Inbox-native services fit 1-100 seat regulated shops with a BAA in the base plan and fast setup.
  • Gateway products like Zix and Barracuda earn their price above 500 seats with mature IT teams.
  • S/MIME and PGP suit zero-knowledge use cases but require key setup on every recipient device.
  • Consumer webmail like Proton or Tuta fits personal privacy, not business workflows or HIPAA.

Searching for the best encrypted email produces long ranked lists that ignore the one question that determines the answer: what is the workflow. A solo therapist sending a session note to a patient has different requirements than a bank compliance team sending statements to 50,000 customers.

This guide compares the four main categories of encrypted email with honest trade-offs rather than a single ranked list. Each section addresses who the category fits, what it does well, and what breaks in production.

The categories are inbox-native services, gateway policy products, S/MIME or PGP client-side encryption, and consumer secure webmail. The right choice starts with the workflow, not the marketing.

Categories of Encrypted Email in the Market Today

The encrypted email market breaks into four categories that solve different problems. Confusing them produces mismatched deployments and either compliance gaps or unnecessary friction.

Inbox-native services encrypt outbound messages at the vendor gateway and deliver them to the recipient’s regular inbox with a one-click decrypt experience. Examples include Mailhippo, ProtonMail bridging, and similar services. They target small to mid-size regulated businesses.

Gateway policy products scan every outbound message for regulated content, encrypt matches, and store the encrypted content in a portal for external recipients. Examples include Zixcorp, Barracuda Email Gateway Defense, and Proofpoint Email Protection. They target enterprises with mature IT teams.

S/MIME and PGP encrypt messages at the client using cryptographic keys held by the sender and recipient. No vendor holds a decryption key. Consumer secure webmail (ProtonMail, Tuta, Skiff) provides zero-knowledge storage plus end-to-end encryption between same-provider users, with password-protected links for external recipients.

Comparing the Four Categories Side by Side

A comparison table makes the trade-offs concrete. Each category solves a specific problem well and specific problems poorly.

CategoryBest fitSetup timeRecipient frictionCompliance BAA
Inbox-native serviceSmall regulated practiceMinutesLow (one click)Yes in base plan
Gateway policy productEnterprise 500 plus seats30 to 90 daysMedium (portal)Yes, sold separately
S/MIME or PGPZero-knowledge use casesDays per userHigh (key management)Varies by vendor
Consumer secure webmailPersonal privacyMinutesMedium (password link)Rare

The table shows why single rankings mislead. A product that scores best on setup time may score worst on policy control, and a product that scores best on cryptographic strength may score worst on recipient adoption. Selection depends on which axis matters most for the workflow.

best encrypted email in article illustration one

Inbox-Native Services for Small Regulated Practices

Inbox-native encrypted email is the best fit for the largest slice of the regulated market: small to mid-size practices in healthcare, legal, and financial services. Setup takes minutes. The BAA is included in the base plan. Recipients read messages in their normal inbox.

The model works by encrypting the message at the sender’s vendor gateway and generating a per-recipient decrypt link that opens the plaintext in the recipient’s browser without requiring a portal account or password. The trade-off is dependence on the vendor’s session model rather than recipient-held cryptographic keys.

  • Setup: minutes, no MX record changes required for outbound-only workflows
  • Recipient experience: one-click read in their normal inbox
  • Compliance: BAA included in the base plan
  • Best for: 1 to 100 user practices in healthcare, legal, financial services

Practices that need to send HIPAA-covered PHI to patients, referring providers, or payers often find inbox-native services such as Mailhippo the fastest route to compliance without operating gateway infrastructure. Our team at Redefine Web frequently pairs these services with healthcare website security features for practices building out full digital compliance.

Gateway Policy Products for Enterprise Regulated Content

Gateway policy products fit enterprises with hundreds to thousands of users, heavy regulated content flow, and IT teams capable of running the gateway. Zixcorp, Barracuda, Proofpoint, and Cisco all fit this category.

The policy engine scans every outbound message for regulated content patterns. Matches trigger encryption automatically. That enforcement model catches gaps that user-triggered encryption misses when a busy user forgets to click the Encrypt button.

The trade-offs are cost, setup complexity, and recipient portal friction. Total per-user annual cost typically runs $30 to $120 depending on tier. Setup and policy tuning cycles run 30 to 90 days. External recipients hit a portal login unless they are members of a shared directory such as ZixDirectory.

The value scales with volume and directory overlap. A health system exchanging PHI daily with 20 other Zix-using organizations gets substantial workflow benefit from the directory. A 15-person practice does not.

Example A 22-person orthopedic clinic evaluates encryption options after switching billing platforms. Zix quotes about $65 per user annually plus a 25-seat minimum with a 60-day policy tuning cycle. Purview inside Microsoft 365 Business Standard would require upgrading 22 seats to Business Premium at an extra $10 per user monthly. A dedicated inbox-native service costs $10 per mailbox monthly, includes a BAA in the base plan, and sets up in under an hour through a DNS change. The clinic picks the inbox-native path because the operational math favors it below 100 seats.

S/MIME and PGP for Cryptographic Zero-Knowledge

S/MIME and PGP are the answer when the requirement is zero-knowledge encryption with recipient-held keys. No vendor holds a decryption key. That property matters for government contractors, journalists, security researchers, and legal work involving sensitive sources.

Both standards use public-key cryptography. The sender encrypts with the recipient’s public key. The recipient decrypts with their private key held on their device. Interception of the ciphertext yields nothing without the private key.

The setup burden is real. Recipients must generate keys, install client software, and understand the key exchange model. Certificate revocation and expiration add operational complexity. NIST publishes technical guidance in Special Publication 800-177 on trustworthy email that covers the underlying principles.

Outlook 365 and Apple Mail support S/MIME natively once a certificate is provisioned. Thunderbird includes built-in OpenPGP support. Adoption outside technical audiences remains low because most business recipients cannot receive S/MIME or PGP messages without a setup burden they will not undertake. Our guide to S/MIME email encryption signature covers the mechanics in depth.

best encrypted email in article illustration two

Consumer Secure Webmail for Personal Privacy

ProtonMail, Tuta, Skiff, and similar consumer secure webmail services target individuals who want private mail for personal accounts. Zero-knowledge storage protects the mailbox from provider access even under legal compulsion.

End-to-end encryption between same-provider users works transparently. Two ProtonMail users exchange messages that neither Proton nor anyone else can read. That works well for privacy-focused individuals communicating with each other.

Cross-provider messaging falls back to password-protected links. The recipient receives a notification with a link and enters a password shared out-of-band by the sender. That friction limits business adoption because most business exchanges cross providers.

Business identity requirements also limit consumer webmail adoption for regulated use. Custom domain support usually requires an upgraded plan. BAA coverage is rare. Practices needing HIPAA-compliant email typically look at inbox-native business services rather than consumer secure webmail. Our companion piece on protonmail encrypted email covers the ProtonMail-specific trade-offs in more detail.

Best Encrypted Email for Microsoft 365 Users

Microsoft 365 users have three practical options for encrypted email. The right one depends on license tier and whether external contacts also run Microsoft 365.

Microsoft Purview Message Encryption is bundled with M365 E3 and E5 licenses. Sending an encrypted message uses the Encrypt button in the Outlook ribbon. Recipients on M365 read the message inline. External recipients read through a portal link. Documentation is at learn.microsoft.com/en-us/purview/ome.

Gateway products such as Zixcorp integrate with M365 through connectors. The gateway sits in the outbound path and applies policy-based encryption. That model layers policy control on top of the M365 baseline and works well for regulated enterprises.

Inbox-native services work independently of the M365 license tier. The service adds encryption capability without requiring E3 or E5. That option fits organizations on Business Basic or Business Standard plans that need encryption without a license upgrade.

💡Pro Tip: Match the category to the workflow firstRanked lists that pick a single winner ignore the workflow question that determines the answer. Before comparing products, write down the recipient audience, the compliance framework, the current mail platform, and the IT team size. A gateway product wins for a 2,000-seat hospital and loses for a solo therapist. A consumer secure webmail service wins for personal privacy and loses for HIPAA. The workflow selects the category, and only then does product comparison matter.

Best Encrypted Email for Google Workspace Users

Google Workspace users have similar categorized options with Workspace-specific implementations. The right choice depends on Workspace plan and workflow.

Google Workspace Client-Side Encryption (CSE) is available on Enterprise Plus and Education Plus plans. CSE encrypts message content with keys the customer controls, providing a zero-knowledge model. Documentation is at support.google.com/a/answer/10741897.

Gateway products integrate with Workspace through similar connector models to M365. The policy engine sits in the outbound path. Inbox-native services also work with Workspace at any plan tier, adding encryption capability without a plan upgrade.

For solo practitioners on Workspace Business Starter or Standard, inbox-native services typically provide the fastest route to HIPAA-compliant email. A small healthcare practice on Workspace Business Standard adding an inbox-native service reaches BAA-covered encryption in under a day without touching the Workspace license.

Best Encrypted Email for Mobile Devices

Mobile encrypted email adoption is fragmented. iOS supports S/MIME natively in the Mail app once a certificate is provisioned. Android S/MIME support depends on the mail app; Gmail on Android does not support S/MIME without third-party integration.

Consumer secure webmail services (ProtonMail, Tuta) publish full-featured Android and iOS apps that handle encryption transparently for same-provider recipients. External recipients get password-protected links opened in a browser.

  • iOS Mail: S/MIME native, requires certificate provisioning
  • Gmail on Android: no native S/MIME, PGP via FlowCrypt or similar
  • ProtonMail apps: transparent E2E between Proton users
  • Inbox-native services: recipient reads in normal mail app, no separate app needed

For mobile senders in regulated industries, inbox-native services minimize the mobile setup burden. The sender uses their normal mail app and adds a subject-line tag or clicks a bookmarklet to route through the encryption service. Recipients read on any device without setup.

Best Encrypted Email for HIPAA-Regulated Healthcare

HIPAA-regulated healthcare organizations need encrypted email with a signed BAA covering the vendor as a business associate. The BAA is required under 45 CFR 164.502(e) whenever PHI moves through a vendor system. HHS publishes sample BAA provisions outlining expected coverage.

Small to mid-size practices typically get better economics from inbox-native encrypted email services with BAAs bundled in the base plan. Enterprises with 500 plus users benefit more from gateway policy products with granular filter control.

Free consumer services such as Gmail and Outlook.com do not sign BAAs at the free tier and are not appropriate for PHI regardless of TLS support in transit. Business tiers with BAA support exist for Google Workspace and Microsoft 365 but require the correct plan level.

For a broader look at HIPAA-compliant options across categories, our companion piece on HIPAA compliant email services covers pricing tiers and BAA coverage in more depth. The related guide on best encrypted email service ranks specific vendors by workflow fit.