Encrypted Email Guide for Business and HIPAA Workflows

📅 April 6, 2026 ✍️ By Chris Almond ⏱️ 8 min read
encrypted email guide featured image

🔑 Key Takeaways

  • Encrypted email spans three layers: TLS in transit, S/MIME or PGP end to end, and portal delivery.
  • TLS 1.2 or 1.3 protects the wire between servers, but plaintext still sits readable at rest on both.
  • S/MIME and PGP need pre-exchanged keys, which breaks a first send to any patient on personal Gmail.
  • Portal encryption reaches any browser recipient, but replies stall outside the sender inbox thread.
  • HIPAA needs a signed BAA plus training and Security Rule safeguards, not just working encryption.

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.

encrypted email in article illustration one

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.

Example

A mid-size clinic with a stable set of peer providers layers all three encryption models. TLS runs by default between Microsoft 365 mail servers and their peer clinic servers. S/MIME certificates issued from an internal PKI cover peer clinical mail between six known referring physicians. A portal gateway handles patient billing statements and one-off external contacts who cannot install certificates. DLP rules in Exchange Online auto-encrypt any message containing an MRN pattern. Audit logs retain for the six-year HIPAA administrative requirement.

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.

encrypted email in article illustration two

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.

💡Pro Tip: Enable MTA-STS before deploying any content encryption

TLS is the required baseline but fails silently when the receiving server does not support it or downgrades the connection. MTA-STS forces TLS on outbound mail and blocks delivery when the receiving side cannot negotiate a secure session. NIST Special Publication 800-177 covers the technical baseline. Deploy MTA-STS at the DNS layer before adding S/MIME or portal encryption, otherwise the transit layer stays exposed to downgrade attacks that content encryption cannot fix.

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.

Frequently Asked Questions

What is encrypted email? +

Encrypted email is any email where the message content is scrambled so only intended parties can read it. The term covers three separate layers. TLS encrypts the network connection between mail servers. S/MIME and PGP encrypt the message body at the client level. Portal services encrypt the stored content behind a login. Each layer defends against a different threat. Most business deployments use TLS as a baseline and add either message-level or portal-based encryption depending on how technical the recipients are.

Is Gmail encrypted email? +

Gmail uses TLS between mail servers when the other side supports it, and it encrypts stored mail at rest on Google servers with keys Google controls. Gmail is not end-to-end encrypted by default. Google can read stored mail because Google holds the keys. Google Workspace Enterprise and Education tiers add hosted S/MIME support, which adds true end-to-end encryption when both sides hold certificates. Confidential mode adds a passcode and expiration but does not add end-to-end encryption. See related coverage in how is email encrypted.

Is encrypted email HIPAA compliant? +

Encrypted email can meet HIPAA if the covered entity signs a Business Associate Agreement with the mail provider, configures technical safeguards under the Security Rule, and trains staff on encryption use. Encryption alone does not equal compliance. The BAA covers the legal relationship. The configuration covers the technical safeguards. Training covers workforce use. A free personal Gmail or Outlook account cannot meet HIPAA even with strong encryption because no BAA is available on those tiers.

What is the difference between encrypted email and secure email? +

Secure email is a broader term that covers encryption plus anti-phishing, anti-malware, DLP, and archiving. Encrypted email refers specifically to the encryption layer. A secure email service usually bundles multiple protections including encryption. A HIPAA-compliant secure email service adds a BAA and audit logging on top. For most business buyers, secure email is the product category and encrypted email is one required feature inside it.

Can I send encrypted email to any recipient? +

Not without setup on both sides for message-level encryption. S/MIME and PGP require both sender and recipient to hold keys or certificates. Portal-based encryption works with any recipient because the encryption stays on the sender-hosted portal and the recipient only needs a browser and a passcode. For practices that send PHI to patients, portal delivery is the only workable model. For peer clinical mail between known providers, S/MIME is often more efficient after the initial setup.

What is TLS encrypted email? +

TLS encrypted email uses Transport Layer Security to protect the network connection between two mail servers. When Gmail sends a message to Outlook, both servers negotiate a TLS session and the message body travels through an encrypted tunnel. TLS ends when the message arrives at the recipient server. The message sits at rest on that server in a form the provider can decrypt. TLS is the baseline for modern mail delivery but does not qualify as end-to-end encryption for regulated data.

Does encrypted email cost extra? +

TLS is free and built into every modern mail provider. S/MIME certificates cost $0 to $200 per user per year depending on issuer and assurance level. PGP is free but requires plugins. Portal-based services like Mailhippo charge a per-user monthly fee, usually less than $10 per user. Microsoft Purview Message Encryption is included in Microsoft 365 Business Premium and above. Total encrypted email cost depends more on which model the practice needs than on any single tool.

Send your first secure email today Start free — no credit card required. HIPAA-compliant encryption in minutes. Start Free →