[mh_key_takeaways]
Encrypted email protects message content from anyone who is not the intended recipient. The term covers three separate technical layers, and they solve different problems. Getting the layer right is what separates a defensible deployment from a false sense of security.
This guide walks through each layer, the tools that implement it, and where each one fits a business or healthcare workflow. It closes with a practical view on when to combine layers and when a portal-based encrypted email service is the right choice.
The reader should come out with enough context to decide which encryption model matches the recipients they email most often and what the budget implications are.
Encrypted Email Covers Three Distinct Layers
The first layer is TLS in transit. It encrypts the network connection between two mail servers. The message body travels through a tunnel that a passive network snoop cannot read.
The second layer is end-to-end encryption at the message level. S/MIME and PGP encrypt the body with the recipient public key. The mail server sees only ciphertext.
The third layer is portal-based delivery. The sender uploads the message to a hosted portal. The recipient authenticates and reads it in a browser. The mail itself never leaves the portal.
Each layer defends against a different threat. TLS covers passive interception. End-to-end covers a compromised or subpoenaed provider. Portal covers recipients who cannot install client-side keys.
TLS Is the Baseline for All Modern Mail Providers
Gmail, Outlook, iCloud, and most business mail providers negotiate TLS 1.2 or 1.3 by default. The two servers exchange certificates, agree on a cipher, and encrypt the connection.
TLS ends when the message arrives at the recipient server. The mail sits at rest on that server in a form the provider can decrypt. A subpoena, a rogue admin, or a provider compromise exposes plaintext.
TLS also fails when the receiving server does not support it. Older on-premise Exchange systems still exist in the wild. Google publishes a delivery status for each domain the user emails, which can reveal these gaps.
MTA-STS and DANE are add-ons that force TLS on the sending side. NIST covers the technical baseline in Special Publication 800-177 Trustworthy Email. Every modern deployment should have MTA-STS enabled at a minimum.
End-to-End Encryption Uses Keys the Provider Cannot See
S/MIME and PGP are the two dominant end-to-end standards. Both work by encrypting the message body with the recipient public key on the sender client before the message leaves the device.
S/MIME uses X.509 certificates from a certificate authority. It is native in Outlook, Apple Mail, and Google Workspace Enterprise. Setup requires a certificate for each user.
PGP uses a web of trust model where users sign each other public keys. It runs on plugins in most mail clients. Setup requires a keypair and public key exchange with every contact.
Both models fail when the recipient has no client-side setup. A referring physician on personal Gmail without S/MIME cannot receive an S/MIME encrypted message. Related linked topic: should I consider encrypted email using ProtonMail as one example.
Portal-Based Encrypted Email Works With Any Recipient
Portal delivery is the practical choice when recipients are variable, include patients, or refuse to install certificates. The sender writes the message in a normal mail client or a web portal.
The service uploads the message to a hosted portal. The recipient receives a notification with a link. They click the link, authenticate with a passcode or SSO, and read the message in a browser.
Microsoft Purview Message Encryption uses this model. Google Workspace confidential mode uses a similar model. Third-party services like Mailhippo use the same model with a HIPAA-focused BAA in the base plan.
Portal delivery works with any recipient on any device. The tradeoff is friction. Replies happen in the portal, not the recipient normal inbox. Threading breaks for downstream record keeping.
[mh_example]
HIPAA Requires More Than Encryption Alone
HIPAA compliance for email requires three things. A signed Business Associate Agreement with the mail provider. Technical safeguards under the Security Rule. Workforce training on encryption use.
Encryption is one technical safeguard. Access controls, audit logging, session timeouts, and secure key management are others. The HHS Security Rule spells out the full list.
A signed BAA is what makes the mail provider a business associate under 45 CFR 164.502(e). Without it, sending PHI through any encrypted service is still a HIPAA violation regardless of encryption strength.
Gmail on Google Workspace Business Standard and above and Outlook on Microsoft 365 Business Standard and above both offer BAAs. Free personal accounts do not. See related healthcare security context for how email fits inside the broader stack.
Common Encrypted Email Deployment Patterns
Small practices with a single mail provider usually run TLS plus a portal gateway. This covers passive interception and external recipient delivery in one setup.
Mid-size clinics with a stable set of peer providers add S/MIME on top for the peer traffic. TLS is baseline, S/MIME handles peer clinical mail, portal handles patients and one-off external contacts.
Larger hospitals with internal PKI use S/MIME across the entire clinical workforce. They still add a portal for patient communication. The two models coexist and are chosen per recipient by the mail client or by a policy rule.
Common encrypted email deployment components include:
- TLS baseline with MTA-STS enforced on outbound
- SPF, DKIM, and DMARC configured on the sending domain
- S/MIME certificates issued to clinical users for peer traffic
- Portal service for patient and external recipient traffic
- DLP rules that auto-encrypt messages containing SSN, MRN, or PHI patterns
- Audit logs retained per HIPAA six-year requirement
Free Encrypted Email Options and Their Limits
Free encrypted email exists but comes with real limits. Personal ProtonMail and Tutanota accounts offer zero-access encryption at rest and portal-based delivery for external recipients.
The catch is no BAA. Free tiers do not qualify for HIPAA use regardless of encryption strength. Storage caps and daily message limits also fail business use quickly.
Free personal S/MIME certificates from Actalis and similar issuers give real end-to-end encryption but require manual install and renewal. Time cost is often higher than a paid service.
For a solo user with occasional secure needs, free options are workable. For a practice with regulatory obligations, paid tiers with BAAs are the only defensible path. Related: free encrypted email for a fuller comparison.
[mh_protip]
Encrypted Email Feature Comparison
The table below compares the main encrypted email models on the dimensions that matter most for a business buyer.
| Model | Encryption Level | Recipient Setup | HIPAA Fit | Best For |
|---|---|---|---|---|
| TLS only | Transit | None | Baseline only | General business mail |
| S/MIME | End-to-end | Certificate install | Peer traffic | Clinic-to-clinic |
| PGP | End-to-end | Keyring install | Rare in healthcare | Technical users |
| Portal gateway | End-to-end at rest | Passcode or SSO | All recipients | Patient and external mail |
| Zero-access mailbox | End-to-end at rest | Account creation | With BAA on paid tier | Privacy-focused solo users |
Encrypted Email Troubleshooting Basics
Delivery failures are the most common encrypted email problem. TLS failures show up as messages sitting in the outbound queue or arriving in plain form when the receiving server does not support TLS.
S/MIME failures usually trace to certificate expiration, address mismatch, or a missing intermediate CA. The recipient client shows a specific error that names the failing check.
Portal delivery failures often trace to the recipient marking the notification as spam. Adding the sender portal domain to a safe-sender list at the recipient side fixes this. See related linked topic: how to troubleshoot encrypted email.
Deliverability upstream matters too. A domain without SPF, DKIM, and DMARC lands portal notifications in spam even when the portal itself works. The Gmail sender guidelines apply to portal notification email the same way they apply to normal outbound mail.
Choosing an Encrypted Email Setup for Your Practice
The right choice depends on three questions. Who are you emailing most often. Are they technical enough to hold a certificate. Do you already run on Microsoft 365 or Google Workspace.
For a practice that emails patients daily and peer clinics occasionally, a portal gateway is the higher-value setup. Patients never install anything. Peer clinics can still receive the portal notification and open it in a browser.
For a practice that emails peer clinics daily and rarely emails patients, S/MIME across the peer network with a portal fallback for patients is the higher-value setup. Peer traffic runs at inbox speed with no extra clicks.
Mailhippo operates as a portal gateway on top of Gmail or Outlook, includes a BAA in the base plan, and requires no per-user certificate management. It fits practices that need patient-safe encryption without moving off their existing mail provider. Practices building a compliant public site alongside their email strategy can pair this with healthcare marketing support so intake, contact, and email flows stay inside the same compliance boundary.
[mh_faqs]
