🔑 Key Takeaways
- Encrypt email splits four ways: TLS transport, S/MIME, PGP keys, or portal-based delivery.
- TLS drops to plaintext if the receiving server fails to negotiate, so it fails as a standalone.
- S/MIME and PGP encrypt the message content but need certificates or keys installed on both sides.
- Portal services skip recipient setup and fit patient mail because zero install runs on their end.
- HIPAA needs a signed BAA plus encryption in transit and at rest, not just any single method.
Encrypt email covers four different technical methods that each solve a different problem. Transport Layer Security handles the connection layer. S/MIME and PGP handle the message content. Portal-based services handle the recipient experience for external contacts.
This guide covers how to encrypt email across the major clients and use cases. Each method has a specific fit. Match the tool to the sensitivity of the content and the recipient environment.
The right choice depends on plan level, staff count, and how often external recipients change. Read each section for the fit and decide based on the actual send flow.
TLS Is the Baseline Encryption Every Modern Mail Server Uses
Transport Layer Security protects the connection between two mail servers. When one server sends to another, both negotiate a TLS handshake and encrypt the traffic in flight. Any observer on the network path sees only ciphertext.
TLS is on by default in Gmail, Outlook, Apple Mail, Yahoo, and every other major provider. Users do not turn it on. Administrators do not configure it per message. It happens automatically when both servers support it.
The catch is opportunistic fallback. If the receiving server does not support TLS, the sending server delivers the message in plaintext by default. No warning, no error. The sender sees a padlock in the client and assumes encryption, but the message reached the recipient over an unencrypted link.
For regulated content, the fallback rules out TLS as a standalone protection. The NIST SP 800-45 guide on email security recommends verified end-to-end encryption for sensitive email, not opportunistic TLS.
S/MIME Encrypts Message Content in Outlook and Apple Mail
S/MIME uses X.509 certificates to encrypt the message content itself. Once encrypted, only the recipient with the matching private key can read the message. The mail provider stores ciphertext and cannot decrypt.
Outlook supports S/MIME on all plans that include the desktop apps. Apple Mail supports S/MIME natively on macOS and iOS. Gmail supports S/MIME on Workspace Enterprise Plus, Education Standard, and Education Plus.
Setup requires a certificate for the sender and a certificate for the recipient. Certificates come from a trusted authority like DigiCert, Sectigo, or IdenTrust. Public keys attach to signed messages, so correspondents build up a keyring by receiving signed mail from each other.
S/MIME works well between internal users and formal partner organizations with matching PKI. It does not work well for one-off external contacts because most personal accounts do not have S/MIME set up.
PGP Uses an Open-Source Key Model
PGP is the open-source alternative to S/MIME. It does the same job with a different key management model. Users generate a public and private key pair, share the public key with correspondents, and encrypt messages with the recipient public key.
Thunderbird has built-in PGP support. Mailvelope provides a browser plugin for Gmail. GPG Suite covers Apple Mail on macOS. Outlook needs a third-party add-in like Gpg4win.
PGP has stronger cryptographic flexibility than S/MIME but a steeper learning curve. Key generation, keyserver management, and web-of-trust verification all fall to the user. Recipients unfamiliar with the process will not decrypt a PGP message without help.
PGP fits technical users and organizations where security-conscious sender and recipient both know the tooling. It does not fit patient-facing healthcare communication because most patients cannot manage PGP keys.
Portal Services Handle the External Recipient Case
Portal-based encrypted email services solve the friction problem that S/MIME and PGP create for external recipients. The sender writes the message in the normal client. The service encrypts the message and delivers a notification email with a click-to-open link.
The recipient clicks the link, verifies with a one-time passcode or a portal password, and reads the message in a browser. No key management, no certificate exchange, no software install for the recipient.
This is the model most healthcare practices adopt for patient-facing PHI. It works for patients, external providers, and vendors on any mail platform. The recipient does not need to configure anything on their end.
The tradeoff is that the message content lives on the vendor server. Vendor selection matters because that server becomes part of the compliance boundary. Portal services with a signed BAA and audit logging fit HIPAA. Consumer messaging apps generally do not.
A three-provider chiropractic office wants encrypted email for referrals. The office manager tests opportunistic TLS to a regional insurer, but the insurer server drops TLS on receipt and delivers cleartext. The manager then tests S/MIME, but the insurer contact has no certificate. Finally the manager routes the message through a portal-based HIPAA service. The insurer clicks the notification, enters a one-time passcode, and reads the referral in 45 seconds. The office standardizes on the portal path for external referrals.
Encrypting Attachments Follows the Whole-Message Method
Attachments encrypt through the same method as the message body when using Purview, S/MIME, PGP, or a portal service. The sender does not need to encrypt attachments separately. The whole message envelope carries the encryption to the recipient.
Practices that need a separate attachment method have three options:
- Save the file as a password-protected PDF and share the password through a different channel
- Place the file in an encrypted ZIP archive using 7-Zip or WinZip with AES-256
- Use a HIPAA-compliant file transfer service for very large files that exceed mail size limits
The whole-message method is easier for recipients and less error-prone than juggling separate passwords. Password-protected PDFs and ZIP files also fail when the sender emails the password in the same conversation, which happens frequently.
Once a recipient decrypts and downloads an attachment, the local copy is no longer covered by the sender-side encryption. HIPAA rules on the local file remain in force. That is a downstream concern for the recipient environment.
HIPAA Requires More Than the Encrypt Button
HIPAA compliance for email transmission requires four things: a signed business associate agreement with the mail platform, verified encryption in transit and at rest, access logs for six years, and workforce training on when to send PHI over email.
The Encrypt button alone does not cover all four. It covers the transmission layer. The BAA, the logging, and the training all fall to the covered entity to configure and maintain.
Microsoft 365 and Google Workspace both include HIPAA-eligible configurations with signed BAAs. Administrators accept the BAA in the admin center. The BAA applies to the tenant from that point forward. The covered entity handles the rest.
Dedicated HIPAA email services like Mailhippo include the BAA in the base plan without requiring plan upgrades on the underlying mail platform. This matches practices that need HIPAA-safe email but do not want to reconfigure the whole tenant.
Mobile Clients Support the Same Methods
Encrypt email on mobile works through the same methods as desktop. Outlook mobile supports Microsoft Purview Encrypt-Only and Do Not Forward through the same Encrypt option in the compose menu. Recipients open messages in the browser tab or in the Outlook mobile app.
Apple Mail on iOS supports S/MIME natively. Certificates install through a Configuration Profile pushed by mobile device management. The Encrypt icon appears in the compose window once the certificate is available.
Gmail mobile supports Confidential Mode through the standard compose interface. Portal-based encrypted email services provide mobile apps or work through the mobile browser. Mailhippo, Proofpoint, and other vendors all support mobile recipient flows.
The mobile recipient experience matters for patient-facing mail. Many patients read email on a phone. The service should present a clean mobile view of the decrypted message with tap-friendly buttons.
Portal services fit patients and one-off external contacts because zero setup is required on the recipient end. S/MIME fits internal staff or partner organizations with managed PKI where certificates already exist. PGP fits technical users only. TLS fits general business mail with no regulated content. Picking the wrong method for the recipient population is the fastest way to tank open rates and force staff back to unencrypted workarounds.
Cost Varies From Free to Enterprise Tier
Encrypted email cost ranges widely. TLS is free and included in every mail platform. Gmail Confidential Mode is free with any Gmail account. S/MIME certificates cost fifty to several hundred dollars per user per year depending on the authority and support level.
Microsoft Purview Message Encryption requires Business Premium at around twenty-two dollars per user per month, up from Business Basic at six dollars. That is a plan-wide upgrade, not a per-message cost. Dedicated HIPAA services typically run five to twenty dollars per user per month depending on plan tier.
Practices on Business Basic or Business Standard often find a dedicated HIPAA service costs less than upgrading every seat to Business Premium. The math depends on how many seats need to encrypt versus how many just handle general mail.
Compare total cost of ownership, not just per-seat rate. Setup time, training, and ongoing configuration also count. A simpler service with a higher per-seat rate can cost less overall.
The Recipient Experience Determines Adoption
The single largest factor in encrypted email adoption is the recipient experience. Every step the recipient has to take lowers the open rate on regulated messages. Every extra sign-in or password reset lowers it further.
The rough order from easiest to hardest recipient experience is:
- TLS message that arrives inline with no extra step
- Portal service with a one-click link and one-time passcode
- Portal service with account registration and password
- S/MIME message that requires certificate pre-install
- PGP message that requires key pair generation
Practices should match the method to the recipient population. Patient-facing mail needs the simplest recipient path. Internal mail between staff can use a more complex path because the setup is done once during onboarding.
Measure the open rate on encrypted messages. If the rate drops significantly compared to regular mail, the recipient path is too long. Switch to a shorter path.
Mailhippo Handles the HIPAA Case With One-Click Recipient
Mailhippo secure email service works with existing Gmail or Outlook accounts and includes a signed BAA in the base plan. There are no PGP keys, no S/MIME certificates, and no license upgrades on the underlying mail platform.
The sender writes the message in a browser interface or through an add-in. Mailhippo encrypts the content and delivers a notification email to the recipient. The recipient clicks the link, enters a one-time passcode delivered to the same email address, and reads the message.
This is the shortest recipient path among common HIPAA options. Patients on any mail platform can open the message on desktop or mobile. Attachments open inline. Replies encrypt automatically back to the sender.
The broader compliance stack includes healthcare website security features, patient portal configuration, and internal access controls. Encrypted email is one layer. The full stack covers the practice end to end.
Frequently Asked Questions
Open a new message in Outlook. Click Options in the ribbon, click Encrypt, and pick Encrypt-Only or Do Not Forward. Write the message and click Send. Microsoft Purview handles the encryption and delivery. External recipients receive a notification email with a Read the message button that opens the content in a browser tab. They sign in with a Microsoft or Google account or request a one-time passcode. The Encrypt button requires Microsoft 365 Business Premium or higher.
Gmail Confidential Mode is the built-in encryption option. Click the padlock and clock icon in the compose window, set an expiration date, and optionally require SMS verification. Confidential Mode blocks forward, copy, download, and print. It is not end-to-end encrypted and does not meet HIPAA requirements on its own. For HIPAA, use Google Workspace with a signed BAA plus Google Workspace client-side encryption, or route messages through a dedicated HIPAA email service that includes the BAA in the base plan.
The simplest method is to encrypt the whole message using Microsoft Purview, S/MIME, PGP, or a portal-based service. All four methods encrypt the message body and attachments together. To encrypt an attachment separately, save it as a password-protected PDF, or place it in an encrypted ZIP file using 7-Zip or WinZip with AES-256. Share the password through a separate channel. The whole-message method is easier for recipients and less error-prone than the separate password method.
S/MIME uses X.509 certificates issued by trusted certificate authorities. The user pays for a certificate, installs it in the mail client, and encrypts using recipient certificates. PGP uses an open-source key pair generated by the user. Public keys share on keyservers or through direct exchange. Both methods encrypt at the message level. S/MIME integrates with Outlook, Apple Mail, and Gmail Enterprise. PGP integrates with Thunderbird, Mailvelope, and GPG Suite. S/MIME is more common in corporate settings. PGP is more common among technical users.
No, TLS alone does not satisfy the HIPAA transmission security standard reliably. TLS is opportunistic. If the receiving mail server does not support TLS, the sending server delivers in plaintext without any warning. The sender assumes encryption but the message reaches the recipient over an unencrypted connection. HIPAA requires verified encryption for PHI transmission. Use a message-level method like Microsoft Purview, S/MIME, or a portal-based service that enforces encryption on every send with no plaintext fallback.
Yes, if you use the right method. TLS reaches any recipient but drops to plaintext if the receiving server does not support TLS. S/MIME and PGP only work if the recipient has a matching certificate or key. Portal-based services work for any recipient because the message decrypts in a browser after a one-time verification. Practices sending to patients and external contacts on mixed platforms usually choose a portal-based method for the widest compatibility.
It depends on the method. S/MIME and PGP messages stay as encrypted ciphertext in the mail client and decrypt on demand each time the recipient views them. Portal-based services keep the message encrypted on the server and decrypt in the browser for viewing. Microsoft Purview messages stay encrypted at rest. Once a recipient downloads an attachment or copies content out of the encrypted view, the local copy is no longer covered by the sender-side encryption.
