[mh_key_takeaways]
Encrypting an email converts the message body and attachments into ciphertext that only an authorized recipient can read. The sending client, the mail server, or both handle the encryption depending on the method used.
This guide covers the current methods for encrypting an email across Outlook, Gmail, and HIPAA-focused services. It explains the setup, the sender steps, the recipient experience, and when a dedicated encrypted email service is a simpler fit.
Encryption is one layer in a broader security posture. The right method depends on plan level, recipient environment, and compliance requirements. Read each section to match the method to the use case.
Encryption Standards Fall Into Three Main Categories
Email encryption uses three main models: transport-level encryption, message-level encryption, and portal-based encryption. Each model protects a different segment of the delivery path.
Transport-level encryption uses TLS between the sending and receiving mail servers. TLS is the baseline. It protects the message during network transmission but leaves the content in cleartext on the mail servers at each end.
Message-level encryption uses S/MIME or PGP to encrypt the message body and attachments before they leave the sending client. Only the recipient key can decrypt the message. The mail servers see ciphertext.
Portal-based encryption stores the encrypted message on a server and delivers a link to the recipient. Microsoft Purview Message Encryption and most HIPAA email services use this model. The recipient authenticates and reads the message in a browser session.
Microsoft Purview Message Encryption Covers Most Outlook Users
Microsoft Purview Message Encryption is the default encryption path for Outlook users on Microsoft 365 Business Premium and higher. The sender clicks Options, then Encrypt, in the ribbon of a new message. Purview handles the encryption and delivery on the server side.
Two options appear: Encrypt-Only and Do Not Forward. Encrypt-Only encrypts the content and lets the recipient reply, forward, and print. Do Not Forward encrypts the content and blocks forward, print, and download.
External recipients on Gmail, Yahoo, or another provider receive a notification email with a Read the message button. The button opens outlook.office365.com in a browser. The recipient signs in with a Microsoft or Google account or requests a one-time passcode.
Detailed sender steps are in the Microsoft support guide for encrypted messages in Outlook. The setup on the tenant side is minimal if Azure Rights Management is already active.
Gmail Users Rely on Confidential Mode or Client-Side Encryption
Gmail offers two encryption features. Confidential mode is available on every Gmail account, including personal Gmail and every Workspace plan. Client-side encryption is available only on Workspace Enterprise Plus and Education Plus.
Confidential mode sets an expiration date and disables forward, copy, print, and download. It does not encrypt the message body in a way that meets HIPAA transmission requirements on its own. Google can still access the content on its servers.
Client-side encryption encrypts the message content in the browser before it reaches Google servers. The encryption keys are managed by the customer through an external key service. Google cannot decrypt the message.
Standard Workspace plans that need encryption for HIPAA use a gateway or a dedicated HIPAA email service. The Gmail interface stays the same. The encryption happens at the outbound gateway or at the service layer.
S/MIME Provides End-to-End Encryption With Certificates
S/MIME is a message-level encryption standard supported by Outlook, Apple Mail, and most enterprise mail clients. It uses X.509 certificates issued by a trusted certificate authority such as DigiCert, Sectigo, or IdenTrust.
The sender installs a personal certificate in the mail client. The recipient must also have an S/MIME certificate available. Outlook stores recipient certificates from signed messages the user has previously received.
Once certificates are in place, the sender clicks Encrypt on a new message. The mail client uses the recipient public key to encrypt the content. The recipient decrypts with the private key stored in the recipient client.
S/MIME provides true end-to-end encryption because no server between the sender and recipient can decrypt the message. The trade-off is certificate management. Practices with dozens of external recipients need a workflow for exchanging certificates before the first encrypted message can go out.
[mh_example]
PGP Handles Encryption Between Technical Users
PGP, sometimes called OpenPGP or GPG, is a second message-level encryption standard. It relies on a web of trust rather than a centralized certificate authority. Users generate a key pair and publish the public key to a key server or exchange it directly.
PGP is common in security research, legal work, and technical communities where both parties are comfortable managing keys. Mainstream Outlook and Gmail do not include PGP out of the box. Third-party plugins add support.
The strengths of PGP are strong cryptography and no dependence on a central authority. The weaknesses are key management overhead and a recipient experience that assumes technical familiarity. A patient receiving a PGP message will not know how to decrypt it.
Healthcare practices sending PHI to patients almost never use PGP because the recipient experience is unrealistic. PGP fits internal or business-to-business scenarios where both sides run the same tooling.
TLS Alone Does Not Meet HIPAA Transmission Requirements
TLS encrypts the connection between mail servers. It is the baseline for any modern mail transmission. TLS 1.2 and TLS 1.3 are the current versions in use, according to NIST SP 800-52 Rev. 2.
Opportunistic TLS is the common default. If the receiving server supports TLS, the connection uses TLS. If the receiving server does not support TLS, the connection falls back to cleartext. A sender using opportunistic TLS cannot guarantee the message stayed encrypted end to end.
Forced TLS requires the receiving server to support TLS or the message does not go out. Forced TLS is safer but harder to configure across a large recipient list. Most Outlook and Gmail tenants use opportunistic TLS by default.
HHS guidance treats TLS as acceptable for transmission but recommends message-level encryption for high-risk PHI. See the HHS Security Rule guidance for the current position. Practices should assume TLS alone is not sufficient.
Sensitivity Labels Automate Encryption at Scale
Sensitivity Labels in Microsoft 365 apply encryption automatically based on content classification. Administrators define labels in the Microsoft Purview compliance portal and set rules that trigger a label when the message contains specific patterns.
Patterns can include medical record numbers, Social Security numbers, credit card numbers, or custom regular expressions for practice-specific fields. A matching pattern applies the label and the encryption policy in one step.
The sender does not have to remember to click Encrypt. The system enforces encryption based on content. This removes human error from the encryption decision on routine mail.
Deployment requires Microsoft 365 E3 or E5 licensing and configuration of Purview Information Protection. Sensitivity Labels fit large practices and health systems that already run Microsoft 365 at the enterprise tier.
Attachments Are Encrypted Along With the Message Body
Every current message encryption method encrypts attachments as part of the message. S/MIME, PGP, Microsoft Purview, and Google client-side encryption all treat attachments and the body as a single encrypted unit.
The recipient sees one verification step. After the sign-in or key decryption, both the body and the attachments become readable. Do Not Forward rights in Microsoft Purview show attachments in the portal preview and block download.
Attachment size limits apply before encryption is added. Outlook and Gmail cap standard attachments at 20 to 25 megabytes. Very large files exceed the limit and get rejected before encryption is even attempted.
Practices sending large imaging files, video, or full record sets should use a HIPAA-compliant file transfer service instead of email attachments. The email carries the link. The file transfer service handles the payload.
Encryption Alone Does Not Equal HIPAA Compliance
HIPAA compliance includes administrative, physical, and technical safeguards. Encryption is one of the technical safeguards. The covered entity is responsible for the full set.
The covered entity needs a signed business associate agreement with the email provider, access logging, workforce training, an incident response plan, and configuration that enforces encryption on PHI. Microsoft 365 and Google Workspace include a BAA as part of the standard business terms.
Practices that outsource the full mail security posture use a HIPAA email service that includes the BAA, encryption, access logs, and audit trails in a single plan. Mailhippo is one option for practices that want a HIPAA-compliant secure email service that works with an existing Gmail or Outlook account without switching providers.
The choice between running encryption inside Microsoft 365 or Google Workspace and using a dedicated service comes down to IT capacity, license cost across all seats, and the sensitivity of the mail volume.
[mh_protip]
Practical Setup Checklist for a First-Time Sender
A first-time sender can get an encrypted message out today by picking one path and running through the setup. The choice depends on the mail platform already in use.
- Confirm the license level of the Microsoft 365 or Google Workspace tenant.
- Verify that a business associate agreement is in place with the mail provider if PHI is involved.
- Enable the Encrypt button in Outlook or client-side encryption in Gmail if the license supports it.
- Test with an external recipient on a different mail platform to see the actual recipient view.
- Document the sender steps for staff who will send encrypted mail on a routine basis.
The test send matters. The sender view is not the recipient view. A practice sending encrypted PHI to a patient should see the exact browser experience the patient will see before sending real mail.
Practices building the wider HIPAA posture around the encryption method also need to cover the website, intake forms, and patient portals. See the guide on healthcare website security features for the site-side controls that pair with encrypted email.
Common Errors When Encrypting an Email
Several errors show up in the first weeks of a new encrypted email workflow. Most trace back to license mismatch, recipient environment, or a missing configuration step on the tenant.
- The Encrypt button does not appear in Outlook because the license is Business Basic or Business Standard.
- The recipient does not receive the notification because a corporate spam filter blocks the outlook.office365.com sender.
- The S/MIME send fails because the recipient certificate is not in the Outlook contact record.
- The one-time passcode does not arrive because the recipient inbox filters bulk mail into a folder the recipient does not check.
- Attachments exceed the 25 megabyte limit and get rejected before encryption is applied.
Each of these errors has a fix. Licensing is a purchase or a switch to a service that bundles encryption. Recipient filters can be addressed by asking the recipient to allow the sender domain. Certificates can be exchanged through a first signed message.
Related reading covers practical steps for common platforms: to encrypt an email, encrypting email in Outlook, email encrypting workflows, and what does encrypting an email do in outlook. Each guide breaks down the sender view for a specific tool.
When a Dedicated Encrypted Email Service Fits Better
A dedicated encrypted email service fits practices that need HIPAA compliance without adding license overhead or IT complexity. The service handles the encryption, the BAA, the access logs, and the recipient portal.
The sender writes mail in the same Gmail or Outlook interface. Outbound mail routes through the service gateway. The recipient gets a portal link or a native decrypt depending on the service configuration.
Mailhippo is a HIPAA-compliant secure email service that works with existing Gmail and Outlook accounts. The BAA is included in the base plan. Encryption applies to every outbound message. Recipients open messages with one click, without creating a Microsoft or Google account.
Practices building the wider healthcare digital presence often pair encrypted email with a compliant site, intake, and portal setup. A healthcare marketing agency can coordinate the site and communication layer around the encryption service already in place.
[mh_faqs]
