confidential mode Archives | HIPAA Compliant Email

June 10, 2026July 7, 2026

How to Encrypt Emails in Gmail With Confidence Mode S/MIME and Add-ons

how to encrypt emails in gmail guide featured image

[mh_key_takeaways]

Gmail exposes different encryption controls depending on the account plan. Personal @gmail.com accounts have almost nothing. Google Workspace tenants have Confidential Mode on every plan and hosted S/MIME on Enterprise Plus.

The right method depends on what the sender needs to protect and who the recipient is. This guide walks through each option in order of increasing security. For compliance workflows, dedicated encrypted email services that layer on top of Gmail are usually the shortest path.

Each section covers steps and limitations. Skip to the section that matches your Gmail plan and your compliance requirement.

What Gmail encryption options actually exist

Gmail supports four different encryption paths, and each targets a different scenario. Knowing the differences prevents wasted effort on a method that does not meet the actual requirement.

TLS between mail servers, enabled by default on every Gmail account.
Confidential Mode, available on every Gmail account but not real encryption.
Hosted S/MIME, available only on Google Workspace Enterprise Plus.
Third-party PGP add-ons like Mailvelope, available on any account.
Gateway-based encryption services, available on any account through DNS routing.

TLS is baseline. Confidential Mode is a restriction feature, not encryption. Hosted S/MIME is the strongest Google-native option. Add-ons and gateways are the third-party options that work on any plan.

The sibling article how to encrypt email covers the same paths in a provider-neutral way for comparison.

How to use Gmail Confidential Mode

Confidential Mode is the option most Gmail users find first. It is available on every plan and appears as a lock icon in the compose window.

Click the lock icon at the bottom of the compose window. A dialog opens with two settings. Set an expiration date from one day to five years, and choose whether the recipient needs an SMS code to open the message.

Send the message as normal. Gmail-to-Gmail recipients see the message with forward, copy, and download disabled. Non-Gmail recipients receive a link to view the message on Google’s servers.

Confidential Mode reduces accidental forwarding on well-behaved clients. It does not encrypt the message body, and Google can still read the content. HIPAA, CMMC, and GDPR auditors do not accept it as encryption.

Use Confidential Mode for casual privacy on messages that do not carry regulated data. Anything else needs a stronger option.

how to encrypt emails in gmail in article illustration one

Setting up hosted S/MIME on Google Workspace Enterprise Plus

Hosted S/MIME is the only Google-native option that meets healthcare compliance. It requires Enterprise Plus, admin configuration, and a per-user certificate from a trusted certificate authority.

Sign in to the Google Admin console with a super admin account.
Go to Apps, Google Workspace, Gmail, User settings.
Select the organizational unit and enable S/MIME encryption for outgoing email.
Each user uploads their personal S/MIME certificate in Gmail settings under Accounts and Import, then S/MIME settings.
Compose a test message to a colleague with an installed certificate to verify the lock icon appears.

Once configured, Gmail shows a green lock icon next to recipients whose certificates are known and encrypts automatically. Recipients without certificates fall back to standard TLS delivery, which is why S/MIME alone is rarely enough for a full compliance program.

The Google Workspace S/MIME setup documentation covers the certificate policies and enforcement options. For the Outlook side of the same standard, see how to encrypt a response email in Outlook.

Adding PGP encryption through Mailvelope

Mailvelope is a browser extension that adds PGP support to Gmail without requiring any Google plan upgrade. It works with personal Gmail accounts and any Workspace tier.

Install Mailvelope from the Chrome or Firefox extension store. On first run, the extension generates a PGP key pair in the browser and stores the private key locally.

Share the public key with correspondents through a keyserver, a direct exchange, or as an attachment on a signed message. Both sides need each other’s public keys before encryption works.

Composing in Gmail then shows a Mailvelope button. Clicking it opens a secure editor window inside the browser. The message is encrypted locally before being pasted into the Gmail compose window, so Google never sees plain text.

PGP fits technical audiences. It does not fit patients or referring providers who will not install a PGP client. For healthcare, gateway-based services are more practical.

[mh_example]

How encryption methods on Gmail compare across scenarios

The right method depends on the plan, the recipient, and the compliance requirement. A side-by-side view helps narrow the choice.

Method	Works on personal Gmail	Meets HIPAA	Recipient friction	Setup effort
TLS baseline	Yes	No, alone	None	None
Confidential Mode	Yes	No	Low	None
Hosted S/MIME	No, Workspace Enterprise Plus only	Yes	High, needs recipient certificate	High, admin plus per user
PGP via Mailvelope	Yes	Sometimes, depends on documentation	Very high, needs PGP client	Medium
Gateway service	Yes, through Workspace routing	Yes	Low, portal fallback	Low, DNS record

Confidential Mode fits casual privacy. Hosted S/MIME fits large Workspace tenants that already pay for Enterprise Plus. Gateway services fit everyone else, especially small healthcare practices.

The sibling article how to encrypt an email in Outlook 365 covers the same comparison from the Microsoft side.

Encrypting Gmail attachments without changing the message

Sometimes only the attachment carries sensitive data and the message body is fine to send in plain text. Password-protecting the attachment is a common workaround.

Compress the file using 7-Zip, WinRAR, or Windows built-in compression with AES-256 encryption enabled.
Set a strong password of 12 characters or more with mixed case, numbers, and symbols.
Attach the encrypted archive to the Gmail message.
Share the password over a phone call, SMS, or in-person conversation.

Gmail does not scan the contents of an encrypted archive, so the file travels through Google’s servers as opaque data. The recipient extracts the archive with the shared password.

This method is not HIPAA compliant on its own. It produces no audit trail, and the password channel is often insecure. It fits one-off file transfers between organizations without a shared encryption service. Related coverage in how to encrypt a PDF in emails covers the same territory.

how to encrypt emails in gmail in article illustration two

Routing Gmail through a gateway service

Gateway services encrypt outbound Gmail messages by routing mail through their own servers before delivery. Setup takes minutes and does not require a Workspace upgrade.

The practice signs up with the vendor and receives an SPF record and often a DKIM key. The domain administrator adds both to the DNS zone.

Outbound mail from Gmail then routes through the vendor’s gateway, which applies encryption before releasing the message. Recipients read the message either in their normal inbox with TLS enforcement or through a portal fallback if their server does not support the encryption standard.

End users see no change in Gmail. Staff compose and send from the same interface, and the encryption happens invisibly at the server. Vendors like Mailhippo follow this pattern and include the Business Associate Agreement in the base plan.

Related coverage in encrypted emails in Outlook shows the same model applied to the Microsoft side.

Verifying that a Gmail message went out encrypted

An encrypted send is only useful if the encryption held. Gmail provides two ways to verify.

Open the sent message and click the three-dot menu at the top right. Select Show Original. The header at the top of the resulting page displays the TLS status of the delivering connection under Received lines.

For hosted S/MIME messages, Gmail shows a green lock icon in the message header. Clicking the icon opens a panel with the certificate details of the encryption.

If the TLS field shows nothing or the lock icon is missing, the message either traveled without encryption or fell back to a lower tier. That is worth catching before the next send. Sibling coverage in how to view encrypted emails walks through the recipient-side verification.

[mh_protip]

Encrypting the same account across desktop and mobile

Encryption behavior varies by device. A method that works in the desktop browser may not work in the mobile Gmail app, which changes the compose experience for anyone who sends on the go.

Confidential Mode works on both desktop and mobile Gmail. The lock icon appears in the mobile compose window the same way it does on desktop.

Hosted S/MIME works on the mobile Gmail app if the certificate is installed on the device. iOS and Android both support S/MIME certificates in the system keychain.

PGP browser extensions do not work on mobile. Messages composed on the mobile app travel through Gmail unencrypted unless a gateway service handles the encryption at the server.

Gateway services work identically on desktop and mobile because the encryption happens at the server regardless of the client. That consistency is the reason healthcare practices default to gateway services rather than client-side methods.

Compliance-driven encryption on a Gmail account

HIPAA, CMMC, and GDPR each require documented safeguards and audit trails that go beyond message-level encryption. A Gmail user meeting those frameworks needs more than a lock icon in the compose window.

HIPAA requires a signed Business Associate Agreement with the mail provider. Google offers a BAA on Workspace with specific settings enabled by the admin. Personal Gmail accounts have no BAA option.

CMMC requires FIPS 140-2 validated cryptographic modules for Controlled Unclassified Information. That standard rules out most consumer-grade browser extensions.

Gateway services designed for healthcare include the BAA, use FIPS-validated encryption, and produce the audit logs auditors ask for. The HHS sample BAA provisions are the reference for what the agreement should contain.

Practices coordinating email compliance with patient outreach can review their healthcare marketing agency engagement to keep both aligned.

Choosing the right method for your Gmail workflow

The right choice depends on the account plan, the recipient list, and the compliance requirement.

Personal users sending occasional sensitive messages can use Confidential Mode for basic access restriction or a PGP extension for real end-to-end encryption to technical peers.

Small businesses on Workspace Business Standard or below need either an upgrade to Enterprise Plus or a gateway service. The gateway is almost always cheaper and works with the existing plan.

Healthcare practices with HIPAA obligations need either Workspace Enterprise Plus with hosted S/MIME plus a signed BAA or a dedicated gateway service that includes the BAA in the base plan. Gateway services are the shorter path for most solo and small clinics.

Practices reviewing email decisions alongside their broader digital footprint can pair the choice with a look at their healthcare website security features to align intake forms and portal links with the same compliance standards as the mailbox.

[mh_faqs]

April 27, 2026July 7, 2026

How to Send Encrypted Email in Gmail

how to send encrypted email gmail guide featured image

[mh_key_takeaways]

Gmail handles more than 1.8 billion active accounts, and a large share of business email in North America runs through Workspace. Every one of those messages travels over TLS by default when the receiving server supports it. TLS is not the same as message-level encryption.

Learning how to send encrypted email in Gmail means picking the right method for the recipient and the sensitivity of the content. Gmail offers three options built in: TLS transport encryption, Confidential Mode, and S/MIME on Enterprise plans.

For healthcare organizations and any team handling regulated data, native Gmail options often fall short of HIPAA requirements. This guide walks through each method and when to use it.

Gmail Uses TLS for Every Message by Default

Every Gmail message leaves Google servers over Transport Layer Security whenever the receiving mail server supports it. TLS encrypts the connection between the two servers. Nobody sitting on the network path in between can read the message.

The padlock icon in the top-right corner of an open Gmail message shows the transport status. A gray padlock means TLS is active. A red padlock means the recipient server does not support TLS and the message will travel unencrypted.

TLS protects the connection, not the stored copy. Once the message lands in the Sent folder or the recipient inbox, TLS no longer applies. Google can read the message content on its servers, and so can the recipient mail provider.

According to Google documentation, TLS is opportunistic. If a recipient server does not accept encrypted connections, Gmail sends the message in plaintext by default. That behavior alone disqualifies TLS as a standalone compliance method for protected health information.

Confidential Mode Adds Access Controls but Not End-to-End Encryption

Gmail Confidential Mode is available on every personal Gmail account and every Workspace edition. To use it, click Compose, then click the padlock and clock icon at the bottom of the compose window. A menu appears with an expiration date and an optional SMS passcode.

Confidential Mode disables forwarding, copying, printing, and downloading for the recipient. When the expiration date passes, the message becomes unreadable. Senders can revoke access before expiration from the Sent folder.

The mode does not use end-to-end encryption. Google can read the message content. Screenshots defeat the copy and print restrictions because the recipient still sees the message on screen. SMS passcodes rely on phone carrier security, which SIM-swap attacks routinely bypass.

Confidential Mode suits casual privacy needs such as sending a temporary access code or a document link that should expire. It does not meet HIPAA transmission standards, and Google does not extend its business associate agreement to cover Confidential Mode as a compliant PHI transmission method.

how to send encrypted email gmail in article illustration one

S/MIME Hosted Encryption Requires Workspace Enterprise

S/MIME is the built-in Gmail option for true message-level encryption. It is available only on Google Workspace Enterprise Plus, Education Standard, and Education Plus editions. Workspace Business tiers do not include it.

Enabling S/MIME starts in the Admin console. Navigate to Apps, then Google Workspace, then Gmail, then User settings. Toggle S/MIME encryption for sending and receiving. Save the change and wait up to 24 hours for it to propagate.

Each user then uploads a personal S/MIME certificate under Gmail settings, Accounts and Import, Upload your public certificate. The certificate must come from a trusted certificate authority. Both sender and recipient need valid certificates.

When the setup is complete, the padlock icon in a compose window turns green for messages that will send with S/MIME encryption. If the recipient does not have a valid certificate installed, the padlock stays gray and the message sends over TLS only.

Confidential Mode Setup Takes Under a Minute

Open Gmail and click Compose. Fill in the recipient, subject, and body as usual. At the bottom of the compose window, find the icon that looks like a padlock with a clock overlay and click it.

Select an expiration date from the dropdown. Options range from one day to five years. Choose whether to require an SMS passcode. If SMS is selected, enter the recipient phone number in the field that appears.

Click Save. Send the message. The recipient receives an email with a link to view the message. If SMS was enabled, they receive a text with a passcode to enter before the message loads.

External Gmail recipients see the message inline, gated by expiration.
Non-Gmail recipients click through to a Google-hosted page.
Sender can revoke access at any time from the Sent folder by clicking Remove Access.

[mh_example]

S/MIME Certificates Need Renewal and User-Level Provisioning

S/MIME certificates expire, typically after one to three years depending on the issuing authority. Renewals require administrator action for every user account. Certificates issued to a departing employee should be revoked in the Admin console to prevent decryption of prior messages.

Certificate authorities include DigiCert, Sectigo, GlobalSign, and IdenTrust. Costs range from around $20 per user per year for basic identity validation to over $100 per user per year for extended validation with organization details.

For encrypted send to work, the recipient also needs a valid certificate from a trusted authority. External correspondents who do not use S/MIME cannot receive encrypted messages this way. Gmail falls back to TLS transport encryption for those recipients.

This is why S/MIME suits internal exchanges between staff at the same organization or between organizations that have coordinated certificate deployment. It does not suit sending sensitive content to patients or external vendors who do not manage their own certificates.

HIPAA Coverage in Google Workspace Has Boundaries

Google offers a business associate agreement to Workspace customers on Business Standard, Business Plus, and all Enterprise editions. The BAA covers Gmail, Calendar, Drive, Meet, and other core services. Personal Gmail accounts are not covered.

The BAA covers the transmission of PHI through Gmail when standard TLS encryption is in effect between servers. It does not cover Confidential Mode as a distinct HIPAA-safe transmission method. Practices assuming Confidential Mode is HIPAA-compliant are working from a mistaken reading of the BAA.

Because TLS is opportunistic and falls back to plaintext when the recipient server does not support it, Workspace admins cannot guarantee encrypted delivery to every recipient without additional controls. That gap is what drives many healthcare organizations to add a HIPAA-focused encrypted email service.

Additional HIPAA safeguards include audit logging of message access, secure archive retention for six years, and enforced encryption on any message flagged with PHI. Native Gmail provides some of these; complete coverage typically involves a purpose-built service.

how to send encrypted email gmail in article illustration two

Third-Party Services Layer HIPAA Compliance Over Gmail

Purpose-built HIPAA-compliant email services integrate with Gmail through a browser plug-in, a Gmail add-on, or SMTP relay. The sender composes and sends from Gmail without changing workflow. The service handles encryption, delivery fallback, and audit trail.

Mailhippo works this way. It sends over TLS when the recipient server supports it, falls back to a secure portal link when TLS is unavailable, includes a signed BAA in the base plan, and requires no certificate management for senders or recipients. Practices on standard Gmail or Workspace Business use it to close the HIPAA gap without switching platforms.

The recipient experience is a single click. They receive a notification email with a link, click it, authenticate with a passcode, and read the message in a browser. No account creation, no software install, no key management.

For healthcare organizations that also handle web presence and patient acquisition, coordinating email security with the broader tech stack matters. Firms offering healthcare marketing services often deploy encrypted email and HIPAA-compliant website design together.

Recipient Experience Differs Across Each Method

TLS is invisible to the recipient when it works. The message arrives in the inbox looking like any other email. No click-through, no passcode, no external portal. Nothing signals that transport encryption was applied.

Confidential Mode delivers a notification email with a View the email button. The recipient clicks and, if SMS was enabled, enters a passcode from a text message. They read the message in a Google-hosted view with copy, forward, print, and download disabled.

S/MIME delivers a locked message icon in a supported email client. Outlook, Apple Mail, and Gmail render the message inline once the recipient certificate decrypts it. In an unsupported client, the recipient sees garbled ciphertext or an attachment they cannot open.

Portal-based services deliver a notification with a link. The recipient clicks, authenticates with a one-time code, and reads in a browser. This suits patients and external contacts who do not manage certificates but expect a low-friction click.

[mh_protip]

Common Errors When Sending Encrypted Email in Gmail

The red padlock is the most frequent warning. It means the recipient mail server does not support TLS. For non-sensitive content, the message still sends. For PHI or other regulated data, do not send when the padlock is red without a portal fallback.

S/MIME send failures often trace to a missing recipient certificate. Gmail shows a gray padlock instead of green, and the message sends over TLS. To force S/MIME, both parties must have valid certificates uploaded and the Workspace admin must have enabled the feature at the domain level.

Confidential Mode messages sometimes fail to render for recipients on strict email security gateways. The notification email arrives, but the click-through link is stripped or blocked by the recipient inbound filter. Test with the specific recipient before relying on Confidential Mode for time-sensitive delivery.

According to HIPAA Journal, the most common compliance failure is sending PHI to an external address without confirming the transmission was encrypted end to end. Assume nothing about transport; verify the method for every sensitive message.

Choose the Method by Recipient and Content Sensitivity

Match the encryption method to the message. Casual internal notes to colleagues who use Gmail can rely on TLS. Time-limited access to a document link or a temporary credential fits Confidential Mode. Regulated content going to an external recipient needs message-level encryption or portal delivery.

Internal team messages, no regulated content: TLS is sufficient.
Temporary access codes to trusted external recipients: Confidential Mode.
Regulated PHI, PII, or financial data to any external recipient: S/MIME or a HIPAA-compliant service.
Recipients on unknown email systems: portal-based delivery with fallback.

For healthcare providers, portal-based services with a BAA are the most reliable path. They handle recipients across all mail providers, provide audit logs, and remove certificate management. Setup takes minutes rather than the administrator overhead S/MIME requires.

Related reading covers how to send encrypted email across platforms, how to send an encrypted email from Outlook, and how to send encrypted email using Gmail for Workspace teams. For teams building patient-facing infrastructure, resources on healthcare website security features pair well with encrypted email deployment.

Verify Encryption for Every Sensitive Message

Before hitting Send on any message with regulated content, check the padlock icon. Green means S/MIME. Gray means TLS. Red means unencrypted, and the message should not go without a portal fallback.

For Workspace administrators, the Admin console provides an Email Log Search that shows the encryption status of every outbound and inbound message. Use it to audit compliance for a defined period, especially before signing off on a HIPAA risk assessment.

According to NIST Special Publication 800-45, verified end-to-end encryption or a portal-based delivery method is required for messages carrying sensitive personally identifiable information across public networks. Assumed TLS is not the same as verified TLS.

The final rule is straightforward. Do not send regulated content over Gmail unless you have picked and verified a method that meets the transmission standard. Pick S/MIME for internal certified users, or add a HIPAA-compliant service for everyone else.

[mh_faqs]

March 25, 2026July 7, 2026

How to Send Encrypted Email from Gmail

send encrypted email from gmail guide featured image

[mh_key_takeaways]

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.

[mh_example]

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.

[mh_protip]

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.

[mh_faqs]

March 18, 2026July 7, 2026

Can I Encrypt an Email in Gmail (and Every Other Client)

can i encrypt an email in gmail guide featured image

[mh_key_takeaways]

Encrypting an email should be a one-click operation. In practice it depends on which client, which plan, and which recipient the sender is dealing with.

The core question, can I encrypt an email in Gmail, has three answers. So does the same question for Outlook and GoDaddy. This guide walks through each path, when to use it, and when a hosted encrypted email service is the simpler choice.

The setup order matters. Check the client, check the plan, then choose the encryption method that matches the recipient. A method that works for a colleague on the same tenant may not work for a patient on a free consumer account.

Gmail Confidential Mode is not encryption

Confidential Mode appears in the Gmail compose window as a lock icon at the bottom of the toolbar. Clicking it opens a dialog for expiration and passcode settings.

The message body is not encrypted. Google servers store the message in the same format as any other Gmail message. The controls are behavioral, meaning they restrict what the recipient can do in the Gmail interface.

The recipient can still screenshot the message, retype it, or print the screen. The expiration setting removes access from the Gmail viewer, but any content already read is out of the sender’s control.

For casual privacy, Confidential Mode is useful. For HIPAA or any regulated data, it is not sufficient. The Security Rule requires actual encryption of the transmitted content.

Native S/MIME in Gmail requires Enterprise Plus

Google Workspace supports hosted S/MIME on Enterprise Plus, Education Standard, and Education Plus. Business Starter, Standard, Plus, and Enterprise Standard do not include native S/MIME.

To enable S/MIME, an administrator uploads each user’s S/MIME certificate through the Admin console and configures the S/MIME setting under Apps, Google Workspace, Gmail, User settings.

Sending an encrypted message to an external recipient requires the recipient’s public certificate. If Gmail does not have the certificate on file, the compose window shows the message as signed but not encrypted.

The certificate exchange problem is the reason most practices skip S/MIME even when the plan supports it. Patients and external contacts rarely have S/MIME certificates.

can i encrypt an email in gmail in article illustration one

Third-party extensions add encryption to any Gmail plan

Browser extensions like Mailhippo, Virtru, and FlowCrypt add an encryption toggle to the Gmail compose window. When the toggle is on, the extension encrypts the message before it leaves the browser.

External recipients receive a link and open the message in a portal. They authenticate with a Google, Microsoft, or email-verified passcode, depending on the extension.

The advantage over S/MIME is that recipients need no configuration. The advantage over Confidential Mode is that the encryption is real. The trade-off is a per-user monthly fee.

For healthcare senders, the extension has to come with a signed BAA. Mailhippo, Virtru, and Paubox all offer BAAs. FlowCrypt does not, which rules it out for HIPAA use. Practices weighing which extension to install often compare notes across how can i encrypt my emails and similar decision guides.

Outlook 365 has an Encrypt button that triggers Purview

Can I encrypt an email in Outlook? Yes. On Microsoft 365 Business Premium or higher, the Encrypt button appears on the Options ribbon in Outlook Desktop and in the Actions menu in Outlook on the web.

Clicking Encrypt applies Microsoft Purview Message Encryption. The message body and attachments are encrypted, and external recipients receive a portal link that they open after authenticating with Microsoft, Google, or a one-time passcode.

The Encrypt button only appears if Azure Rights Management is active on the tenant. If a super administrator has never enabled it, the button is invisible even on the correct license.

On Business Basic or Business Standard, the Encrypt button is not available. Practices on those plans need to upgrade to Business Premium or use a third-party gateway.

[mh_example]

Outlook Desktop supports S/MIME on any plan

Outlook Desktop has supported S/MIME for over 20 years. The setup runs through File, Options, Trust Center, Trust Center Settings, Email Security.

A user imports an S/MIME certificate from a certificate authority into the Windows certificate store, then binds it to their Outlook profile. Digital signing and encryption become available on the compose window.

To send an encrypted message to an external recipient, the sender needs the recipient’s public certificate. Outlook stores public certificates from previously received signed messages, which is how the exchange usually happens.

Outlook on the web has more limited S/MIME support and requires the S/MIME control installed through the browser. Outlook Mobile does not support S/MIME send at all on most versions.

can i encrypt an email in gmail in article illustration two

Consumer Outlook.com has free encryption between Microsoft accounts

Outlook.com consumer accounts include free encryption for messages between Microsoft accounts. The shield icon in the compose window toggles encryption on.

The recipient experience depends on what account they use. Other Outlook.com or Microsoft 365 users see the decrypted message natively. External recipients on Gmail, Yahoo, or similar receive a portal link.

The free encryption tier does not include a BAA. Microsoft signs BAAs on Microsoft 365 business plans, not on consumer Outlook.com. Healthcare users on Outlook.com are not compliant.

For a personal user who wants to send an encrypted message once in a while, Outlook.com’s built-in encryption is a fine free option. For a practice, it is not.

GoDaddy email splits into two products with different encryption options

GoDaddy sells two email products under two brand names. Professional Email is GoDaddy’s own product, and Microsoft 365 from GoDaddy is a rebranded Microsoft 365 tenant.

On Professional Email, transit encryption uses TLS whenever the receiving server supports it. There is no built-in body encryption. Users who need it install a third-party extension or upgrade.

On Microsoft 365 from GoDaddy, encryption works exactly like any Microsoft 365 tenant. Business Premium and higher get the Encrypt button. Lower tiers do not.

GoDaddy does not sign a BAA for its consumer-tier products. Healthcare senders on GoDaddy need to be on the Microsoft 365 Business Premium tier, activate the BAA through the Microsoft admin center, and use Purview or a third-party service for encryption.

[mh_protip]

Comparison of encryption methods across common clients

The three main methods, TLS, S/MIME, and portal-based, each have trade-offs. TLS is automatic and covers most modern receivers, but the sender has no visibility into whether a specific message actually used TLS on delivery.

S/MIME is strong when both sides have certificates, but the certificate exchange kills the workflow for most external recipients. Portal-based services solve the certificate problem but add a step for the recipient.

Method	Recipient effort	HIPAA-ready	Included in
TLS only	None	Only with signed BAA plus verified TLS enforcement	Every provider
Gmail Confidential Mode	Passcode entry	No	Every Gmail plan
S/MIME	Certificate install	Yes, if BAA in place	Enterprise Plus, Outlook Desktop, Microsoft 365
Purview Message Encryption	Portal login	Yes, if BAA in place	Microsoft 365 Business Premium+
Third-party portal service	Portal login	Yes, with signed BAA	Mailhippo, Virtru, Paubox

The right column matters more than the others for a healthcare practice. If the encryption method is not paired with a signed BAA, it does not meet the Security Rule requirement regardless of how strong the cryptography is.

What to choose based on the sender’s situation

A solo practitioner on Gmail should install a hosted encryption service and skip the plan-tier gymnastics. The monthly fee is smaller than the friction of managing S/MIME certificates for every recipient.

A small group practice on Microsoft 365 Business Standard should upgrade to Business Premium, activate the Encrypt button, and train staff on when to use it. That is the shortest path to compliance for a Microsoft-first shop.

A larger clinic with mixed email systems benefits from a gateway service that sits in front of every outbound path. The gateway enforces encryption regardless of which client the user sends from.

Practices that want the marketing site and patient intake to match the email compliance posture should work with an agency familiar with HIPAA-compliant website design so the intake forms, the appointment reminders, and the outbound clinical mail all share the same encryption story.

Quick setup steps for the three most common configurations

For Google Workspace Business Standard with a hosted encryption service: sign up with the vendor, connect the Gmail account through OAuth, install the browser extension, and send a test message to a personal address on a non-compliant server. Confirm the recipient sees a portal link.

For Microsoft 365 Business Premium: activate Azure Rights Management under Settings, Org settings, Services, Microsoft Azure Information Protection. Confirm the Encrypt button appears in the Outlook ribbon. Send a test message.

For Outlook Desktop with S/MIME: purchase a certificate from a certificate authority, install it in the Windows certificate store, bind it under Trust Center, Email Security, and exchange a signed message with the intended recipient to swap public certificates.

The Google Confidential Mode help page and the Microsoft Purview documentation both walk through the client-side steps for reference.

Check the plan tier before choosing an encryption method.
Skip Confidential Mode for any regulated data.
Use a third-party hosted service if S/MIME certificate exchange is not practical.
Confirm a signed BAA is in place before sending PHI over any channel.
Test with a real external recipient before rolling out to staff.

Answering can i encrypt an email in gmail is the easy part. The harder question is which method fits the sender’s plan, the recipient’s setup, and the compliance requirements attached to the content. The right combination changes the moment any of those three factors change.

[mh_faqs]