🔑 Key Takeaways
- Email encryption stacks in three layers: TLS in transit, portal-based, and full end-to-end.
- Personal Gmail has zero real encryption; Confidential Mode fails HIPAA, CMMC, and GDPR checks.
- Outlook’s Encrypt button on Business Premium runs Purview and reaches any recipient via portal.
- S/MIME suits business rollouts; PGP suits individuals; both stall on recipients without keys.
- Compliance needs a BAA, retained logs, and a documented standard, not a per-message click.
The question “how can I encrypt my emails” has different answers depending on which mail provider is in front of you. Gmail, Outlook, and Microsoft 365 each expose different controls, and personal accounts on all three offer less than their business counterparts.
This guide walks through the encryption paths available in each platform, explains where S/MIME and PGP fit, and covers the compliance layer for practices that need audit trails. For practices sending patient information, dedicated encrypted email services are usually the shortest path.
Each section below covers the steps for a specific platform or method. Skip to the section that matches your setup.
Three layers of email encryption you need to understand first
Email encryption is not one thing. It operates at three layers, and each solves a different problem.
The first layer is TLS between mail servers. It protects the message on the wire from one server to the next. Gmail, Outlook.com, and Microsoft 365 all enforce TLS 1.2 or 1.3 by default when the receiving server supports it.
The second layer is message-level encryption. The mail provider encrypts the message body on its own servers and delivers it to external recipients through a portal or a signed session. Microsoft Purview Message Encryption and Google Workspace hosted S/MIME operate at this layer.
The third layer is end-to-end encryption. The message body is encrypted on the sender’s device and stays encrypted until the recipient decrypts it. S/MIME with client-held certificates and PGP both operate at this layer.
Most business scenarios stop at the second layer. The third layer adds friction that only pays off when the message content is unusually sensitive or the recipient’s mail server cannot be trusted with plain text.
How to encrypt emails in Gmail with a Workspace account
Gmail on Google Workspace Enterprise Plus supports hosted S/MIME. The admin enables it in the Google Admin console under Apps, Google Workspace, Gmail, User settings.
Once enabled, users upload their S/MIME certificate through Gmail settings. Compose messages then show a lock icon next to the recipient field, indicating that the message will send encrypted.
Encryption only applies when the recipient also holds a certificate. For recipients without one, Gmail falls back to standard TLS delivery. That fallback is the reason S/MIME alone is not sufficient for a healthcare workflow.
The Google Workspace S/MIME setup guide walks through the certificate upload and enforcement policies. Confidential Mode is not a substitute for S/MIME and does not satisfy HIPAA.
Practices on lower Workspace tiers do not have hosted S/MIME. Those accounts need a third-party gateway or a dedicated compliant email service.
How to encrypt emails in Outlook with a Microsoft 365 plan
Outlook on Microsoft 365 Business Premium, E3, and E5 exposes an Encrypt button in the compose window. It sits in the Options ribbon on the desktop app and in the three-dot menu on Outlook web.
Clicking Encrypt triggers Purview Message Encryption. The user picks an encryption policy such as Encrypt Only or Do Not Forward. The message travels encrypted, and external recipients receive a portal link with sign-in options.
The Microsoft Purview Message Encryption documentation details the policy options and the recipient experience. Setup usually completes in the admin center within an hour if Azure Rights Management is already active on the tenant.
Business Basic and Business Standard do not include the Encrypt button. Practices on those plans either upgrade or add a dedicated encryption layer. Sibling coverage for the Outlook-specific path is in can I encrypt emails in Outlook.
For a broader walkthrough of Gmail-side encryption steps, see how can I encrypt an email.
Setting up S/MIME on a desktop Outlook client
Desktop Outlook supports S/MIME natively. The user needs a certificate issued to their email address, installed in the Windows certificate store or on a smart card.
- Obtain an S/MIME certificate from a trusted certificate authority. Commercial certificates cost $20 to $60 per year.
- Import the certificate into the Windows certificate store under Personal, Certificates.
- In Outlook, open File, Options, Trust Center, Trust Center Settings, Email Security.
- Under Encrypted email, click Settings and select the imported certificate.
- Optionally enable Encrypt contents and attachments for outgoing messages to make encryption the default.
Once configured, the compose window shows a lock icon when the recipient’s certificate is available. If the recipient has never sent a signed message, Outlook cannot encrypt to them until their certificate is exchanged.
The exchange step is the operational tax of S/MIME. It works well inside a practice where every mailbox has a certificate. It falls apart with external partners and patients who do not.
A five-provider family medicine clinic runs on Google Workspace Business Standard at $12 per user per month. Staff want to send referral summaries to a cardiologist on Outlook. Business Standard does not include hosted S/MIME. Upgrading five seats to Enterprise Plus at $30 each would cost $150 per month. Instead, the practice adds a gateway service at $10 per mailbox that layers on top of Workspace, keeps Gmail as the compose interface, and includes the BAA and audit trail for $50 per month total.
Using PGP with Thunderbird or Mailvelope
PGP encryption uses a public-private key pair that the user generates and controls. It works with any email account, including personal Gmail and Outlook.com, but requires a compatible client on both ends.
Thunderbird has built-in PGP support since version 78. The user generates a key pair in Account Settings, End-to-End Encryption. The public key is shared with correspondents through a keyserver, direct exchange, or embedded in outgoing signatures.
Mailvelope is a browser extension that adds PGP support to Gmail and other web-based clients. It handles key generation and message encryption directly in the browser without the mail provider seeing plain text.
PGP is the preferred method for individual users, journalists, and technical audiences who prioritize key control. It is rarely the right method for a healthcare practice because patients and referring providers will not install a PGP client.
For a client-facing walkthrough of PGP versus gateway encryption, the sibling article how do my clients encrypt email covers the tradeoffs.
Encrypting attachments without encrypting the message
Sometimes the message body is fine to send in plain text and only the attachment carries sensitive data. Password-protecting the attachment lets the email travel through any provider.
- 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 email as normal.
- Share the password over a separate channel, such as a phone call, SMS, or in-person conversation.
This method is common for one-off file transfers between organizations that have no shared encryption infrastructure. It is not compliant on its own for HIPAA because it does not produce an audit trail and the password channel is often insecure.
Practices exchanging patient files frequently should route those exchanges through a compliant email service instead. The sibling piece on how to encrypt my sent emails covers the outbound side in more depth.
Government and military email encryption requirements
Army and other DoD email accounts require encryption through the DoD Common Access Card or Personal Identity Verification card. The CAC holds the S/MIME certificate that Outlook and OWA use to encrypt outbound mail.
Signed drivers for the CAC reader and the ActivClient middleware need to be installed on the endpoint. Once installed, Outlook detects the certificate and enables Sign and Encrypt buttons in the compose ribbon.
Encrypting from a home computer to a .mil address requires the sender’s CAC and the recipient’s published certificate. The DoD Global Address List holds those certificates for internal-to-internal traffic.
Contractors handling Controlled Unclassified Information under CMMC use a similar S/MIME model or a compliant email gateway. The NIST SP 800-171 Rev. 2 guidance covers the required controls for those workloads.
Compliance-driven encryption for HIPAA, CMMC, and GDPR
User-driven encryption on a per-message basis rarely satisfies a compliance framework. The framework requires a documented standard, retained audit trails, and a signed agreement with the vendor handling the data.
HIPAA requires a Business Associate Agreement with the email vendor. CMMC requires FIPS 140-2 validated cryptographic modules for CUI. GDPR requires a Data Processing Agreement covering personal data of EU residents.
A gateway-based compliant service handles all three by applying encryption at the mail server, retaining logs, and providing the signed agreement in the base plan. That removes the burden of a user deciding whether a specific message qualifies.
Practices that also send bulk patient communications should coordinate with a healthcare marketing agency so that outreach and compliance sit on the same infrastructure.
The HIPAA Journal breakdown of compliant email is the authoritative external reference for the healthcare side.
Framework first, technology second. HIPAA, CMMC, and GDPR each demand different documentation and cryptographic standards. Write down which framework applies, which data types you send, and how you will prove encryption during an audit. Only then compare S/MIME, Purview, or gateway services against those requirements. Buying the tool first almost always produces a mismatch that surfaces six months later.
Verifying that a message was actually encrypted
An encrypted send is only useful if the encryption held. Every major mail client provides a way to verify.
In Gmail, open the message, click the three-dot menu, and select Show Original. The header displays the TLS status of the delivering connection.
In Outlook desktop, right-click the message and choose Message Options. The header shows Received lines with TLS version details.
For end-to-end encryption, the client shows a lock icon or shield in the message header. S/MIME messages in Outlook show a blue ribbon. Encrypted messages in Gmail show a green lock.
If none of those indicators appear, the message either traveled without encryption or the encryption fell back to a lower tier than the sender expected. That is worth catching before the next send rather than after an audit.
When a dedicated compliant email service saves setup time
The setup steps above cover the manual paths available in Gmail, Outlook, and Microsoft 365. Each works for individual users comfortable managing certificates or keys per contact.
A dedicated compliant email service replaces the manual path with an automatic one. The practice connects its existing mailbox, adds a DNS record, and every outbound message is encrypted at the gateway. No per-contact certificate exchange is required.
Mailhippo is one example of that model. It works with existing Gmail and Microsoft 365 accounts, includes the Business Associate Agreement in the base plan, and delivers messages directly to recipient inboxes without a portal login for standard scenarios.
For the underlying encryption model comparison, the sibling article how to encrypt email covers the technical layer in more depth. For the recipient-side experience, how can you encrypt an email walks through what the reader sees.
Choosing the right method for your workflow
The right encryption method depends on volume, sensitivity, and recipient technical skill.
Individuals sending occasional sensitive messages to technical peers can use PGP through Thunderbird or Mailvelope. The setup pays off because the recipient list is small and every recipient has the tools.
Small businesses on Microsoft 365 Business Premium can use the Encrypt button. It handles the recipient experience through the portal and needs no per-user certificate.
Healthcare practices, law firms, and financial services with compliance obligations need a gateway-based service. It removes the user decision and produces the audit trail auditors ask for.
Practices reviewing the broader digital footprint alongside the email decision can also review their healthcare website security features so the same standards apply across email, forms, and portals.
Frequently Asked Questions
Not with real encryption. Personal @gmail.com accounts do not offer S/MIME or Purview-style message encryption. Confidential Mode adds an expiration date and disables forwarding on some clients, but the message body is not encrypted in a way that satisfies HIPAA or CMMC. Options are to upgrade to Google Workspace Enterprise Plus for hosted S/MIME, install a browser extension that adds PGP support on both sides of the conversation, or route the mailbox through a dedicated encryption gateway that handles the encryption automatically.
On Microsoft 365 Business Premium and Enterprise plans, the Encrypt button triggers Purview Message Encryption. The message is encrypted at the Microsoft server and delivered to external recipients through a portal link. Internal recipients on the same tenant read the message directly in Outlook because the encryption keys travel inside the tenant. The button appears in the Options ribbon on desktop Outlook and in the three-dot menu on Outlook web. It does not appear on personal @outlook.com accounts.
One per employee, yes, if you route encryption through S/MIME. Certificates are issued per email address by a trusted certificate authority and typically cost $20 to $60 per year at the business tier. Some Microsoft 365 Enterprise plans include managed certificates. The larger operational cost is the certificate exchange with external recipients, because both sides need each other’s public certificate before encryption works. That exchange is the reason many practices choose a gateway-based service instead of S/MIME.
Yes, and it is a common workaround. Zip the file with a password using 7-Zip or the built-in Windows compression tool, then share the password over a separate channel like a phone call or SMS. The email carrying the encrypted zip stays unencrypted, so it can travel through any provider. The tradeoff is friction for the recipient, who has to install a compatible unzip tool and manage the password. Encrypting the message itself is simpler once the practice has a compliant service in place.
Gmail on mobile inherits the encryption settings of the underlying account. A Workspace mailbox with hosted S/MIME sends encrypted messages from the mobile app once the certificate is installed on the device. Outlook on iOS and Android supports the Encrypt button for Microsoft 365 Business Premium and Enterprise users. Personal accounts on both apps have no encryption controls. A gateway-based compliant email service handles encryption at the server, so the mobile experience is identical to a regular send.
Usually not. Most encryption methods, including S/MIME, PGP, and Microsoft Purview Message Encryption, encrypt the message body and attachments but leave the subject line in plain text. That is because mail servers use the subject for routing, filtering, and threading. Sensitive information should therefore stay out of the subject line even when the message body is encrypted. Some end-to-end services encrypt the subject as well, but interoperability with standard clients drops sharply when they do.
On Gmail, open the message and click the three-dot menu, then View Original. The header shows the TLS status of the connection that delivered the message. On Outlook, right-click the message and select Message Options or View Source. Look for the Received header lines and check for TLS 1.2 or 1.3 versions. For end-to-end encrypted messages, the client shows a lock or shield icon in the message header. If neither the header nor the icon confirms encryption, the message traveled unprotected.
