[mh_key_takeaways]
Email encryption is not one process. It is a family of methods that apply differently depending on the sender client, the recipient client, and the license tier on both sides. The right method for a given message is the one that lands in a form the recipient can actually read.
This article walks through the three main encryption methods in production use today. Transport-layer TLS, client-level S/MIME, and portal-based encryption through services like Microsoft Purview or a HIPAA-compliant encrypted email service. Each has a role, and the trade-offs matter for healthcare senders in particular.
The three encryption methods you actually have
Every email encryption solution in production use is a variation on one of three methods. Transport Layer Security, client-side S/MIME or PGP, and portal-based encryption through a secure gateway.
Transport Layer Security encrypts the connection between two mail servers. When both servers support TLS 1.2 or higher and negotiate a session, the message content travels encrypted between them. TLS is invisible to the sender and recipient. It does not require any action to enable and does not require any client-side setup.
Client-side encryption using S/MIME or PGP encrypts the message body itself with a key that only the recipient can decrypt. The encrypted content is safe even if the mail server storing it is breached. S/MIME requires certificates on both sender and recipient devices. PGP requires key pairs.
Portal-based encryption uploads the message content to a secure gateway. The recipient receives a notification with a link to authenticate and view the content in a browser. This method removes the need for the recipient to have any specific client or certificate. It is the standard approach for external communications where the sender cannot control what the recipient uses.
How to encrypt an email in Outlook desktop
Outlook desktop on Microsoft 365 Business Premium and Enterprise E3 or higher includes the Encrypt button in the Options ribbon of a new message. Clicking it applies Microsoft Purview Message Encryption using the sender tenant as the authentication backend.
The steps in Outlook desktop:
- Compose a new message and address it to the recipient
- Click the Options tab in the ribbon
- Click Encrypt in the Permission group
- Choose Encrypt-Only, Do Not Forward, or a custom policy from the dropdown
- Complete the message body and click Send
The recipient sees a notification with a Read the Message button. Clicking the button opens a browser session, prompts for sign-in with Microsoft, Google, or a one-time passcode, and displays the decrypted content on the Microsoft encryption portal.
Outlook desktop also supports S/MIME encryption for messages between recipients who have exchanged certificates in advance. The Sign and Encrypt buttons in the Message ribbon apply S/MIME. Certificate management is more complex than portal-based encryption and is typically used only for internal messages between employees on the same tenant.
How to encrypt an email in Outlook on the web
Outlook on the web at outlook.office.com supports the same Purview Message Encryption as the desktop client. The interface is different, but the underlying mechanism is identical.
The steps in Outlook on the web:
- Compose a new message
- Click the three-dot More menu at the top of the compose window
- Select Encrypt from the menu
- Choose the encryption level and any restrictions
- Send the message normally
The recipient experience is identical to messages encrypted from the desktop client. The tenant license and Azure Rights Management configuration are the same underlying requirement.
Outlook on the web does not support S/MIME on all account types. Consumer Outlook.com accounts have no S/MIME. Enterprise accounts support S/MIME through a browser extension that must be installed separately. For most healthcare senders, portal-based encryption through Purview is the practical choice regardless of client.
[mh_example]
How to encrypt an email in Office 365 through the admin side
Office 365 administrators can configure mail flow rules that automatically encrypt outbound messages matching specific criteria. This removes the requirement for the sender to click Encrypt on each individual message.
Common auto-encryption triggers:
- Subject line contains a keyword like Secure or Encrypt
- Recipient domain matches a specified partner list
- DLP scanner detects PHI patterns in the message body or attachments
- Sender is a member of a specified group like clinical staff
- Attachment contains a specific document classification tag
The rule is configured in the Exchange admin center under Mail flow, Rules. The action is Apply Office 365 Message Encryption and rights protection with a chosen template. Testing the rule in audit mode before enforcing it prevents unexpected encryption of messages that should have gone in plaintext.
The Microsoft Purview Message Encryption documentation is the canonical reference for rule syntax and configuration options.
How to encrypt an email in Gmail
Gmail encryption depends on the tier. Consumer Gmail at gmail.com uses TLS in transit for all outbound mail but does not support end-to-end encryption directly. Google Workspace Enterprise Plus and Education Plus support client-side S/MIME.
For Enterprise Plus S/MIME:
- Ensure S/MIME is enabled at the admin console under Apps, Gmail, User Settings
- Upload S/MIME certificates for users through the admin console or self-service
- Compose a new message and address it to a recipient whose certificate is on file
- Click the lock icon in the compose window to see the encryption status
- Choose Enhanced Encryption from the options
- Send the message normally
Business Starter, Standard, and Plus tiers do not include S/MIME support. Practices on those tiers that need to send encrypted PHI typically add a HIPAA email service on top of Gmail. Google Workspace signs a Business Associate Agreement on Business Starter and higher, but the BAA alone does not provide the encryption. Sibling coverage of the Gmail-specific workflow is available at how to send encrypted email Gmail.
Confidential Mode is not encryption. It is a Google-specific feature that adds expiration dates and forwarding restrictions to messages, but the message content itself is not encrypted end to end. HHS has not endorsed Confidential Mode as satisfying HIPAA transmission security requirements.
How to encrypt an email on iPhone Mail
Apple Mail on iPhone supports S/MIME encryption once a personal certificate is installed as a configuration profile. Portal-based encryption from Purview or a HIPAA email service works with no iPhone-specific setup.
For S/MIME on iPhone:
- Email the .p12 certificate file to yourself or obtain it through your organization MDM
- Install the profile through Settings, General, VPN and Device Management
- Enter the certificate password when prompted
- Open Settings, Mail, Accounts, select the account, Advanced
- Enable S/MIME and select the installed certificate under Sign and Encrypt by Default
Once configured, Apple Mail shows a lock icon on any composition to a recipient whose certificate is on file. The lock indicates encryption is active. Tap the icon to see certificate details or to disable encryption for a specific message.
For portal-based encryption, no iPhone-specific setup is required. The sender initiates encryption at the desktop or in the Outlook mobile app, and the recipient receives the standard notification that works on iPhone as on any other device.
[mh_protip]
Choosing between S/MIME, TLS, and portal encryption
The choice depends on the recipient. Internal messages between employees on the same tenant benefit from S/MIME or tenant-native encryption because certificates are managed centrally and no external portal is needed. External messages to business partners on Microsoft 365 or Google Workspace can use enforced TLS if the receiving domain is known and configured.
External messages to consumer email addresses require portal-based encryption. Patients on gmail.com, yahoo.com, aol.com, and icloud.com will not install S/MIME certificates, and enforced TLS to those providers is not fully reliable across all message paths.
The HHS Security Rule guidance and the NIST SP 800-45 email security guidelines provide the compliance framework for evaluating any specific configuration.
When native encryption is not enough for healthcare
Native encryption in Outlook, Gmail, and iPhone Mail works well for many use cases but leaves gaps for regular PHI transmission. Purview Message Encryption requires a Business Premium or Enterprise license, which is more expensive than most small practices need. Gmail S/MIME requires Enterprise Plus, which is not economical at practice scale. iPhone S/MIME requires certificate management the practice has to run for every clinician.
A dedicated HIPAA email service consolidates the encryption, BAA, audit logging, and archiving into one product that works with the existing Gmail or Outlook mailbox. A HIPAA-compliant secure email service that includes the BAA in the base plan removes the license-tier problem and the certificate-management problem at once. This mention concludes the product context for this article.
Recipient experience is the deciding factor in most healthcare deployments. A patient who cannot easily open the message will call the practice for help, and staff time on password resets and portal walkthroughs adds up. Portal-based encryption with federated sign-in through Microsoft, Google, or a one-time passcode is the pattern that produces the fewest support tickets. Sibling coverage on how do you open an encrypted email in Outlook covers the recipient side.
Related healthcare marketing coverage is available at Redefine Web healthcare website security features and at the healthcare marketing hub for practices coordinating email compliance with website and patient acquisition.
[mh_faqs]
