HorizLogoSm.fw_.png
Start Trial

Tag: secure email

Posted on

ProtonMail Encrypted Email Explained for Business and HIPAA Use

protonmail encrypted email guide featured image

[mh_key_takeaways]

ProtonMail encrypted email is one of the most recognized names in consumer secure email. The service applies end-to-end encryption between Proton accounts and zero-access encryption on stored mail. That combination is why journalists, activists, and privacy-focused professionals adopted it early.

Businesses ask a different question. They want to know if encrypted email from Proton clears HIPAA, fits an existing Gmail or Outlook workflow, and holds up when the recipient is on a normal inbox. This post answers those three questions with plain detail.

The short answer is that ProtonMail encrypted email works well for Proton-to-Proton exchange and acceptably for external recipients through a portal. For a healthcare practice on Microsoft 365, the fit depends on how often staff send PHI to outside inboxes.

ProtonMail Uses Two Encryption Models in Parallel

Proton applies end-to-end encryption to messages between two Proton accounts. The sender client encrypts the message with the recipient public key before it leaves the device. Only the recipient private key can decrypt it.

For stored mail, Proton uses zero-access encryption. The account password derives the private key on the user device. Proton stores the encrypted mail on its servers and does not hold the plaintext or the key material to decrypt it.

These two models are often confused. End-to-end covers transit between two Proton users. Zero-access covers everything at rest, including mail that arrived from Gmail or Outlook in plain form and was encrypted on receipt by Proton.

Neither model encrypts every field. Sender, recipient, subject line for external mail, timestamp, and IP metadata remain visible to Proton for routing and abuse handling. Users evaluating protonmail encrypted email for regulated work should account for that metadata exposure.

Password-Protected Messages Reach External Recipients

Most business recipients are not on Proton. Sending them a secure message uses the password-protected message feature. The sender writes the message, clicks the lock icon, sets a password, and optionally adds a hint.

The recipient receives a notification email with a link. They open the link in a browser, enter the password, and read the message inside a Proton-hosted portal. Replies happen inside that portal, not in the recipient normal inbox.

Password sharing has to happen through a separate channel. Sending the password inside the same email chain defeats the purpose. Phone call, text, or an in-person handoff are the practical options for password delivery.

The portal step is the operational friction most teams report. Staff on the receiving end often ask for the message in plain email instead. Practices that plan to use protonmail encrypted email for outbound PHI need a policy that forbids that fallback.

protonmail encrypted email in article illustration one

HIPAA Compliance Requires a Signed BAA on a Business Plan

ProtonMail is not automatically HIPAA-compliant. A covered entity must sign a Business Associate Agreement with Proton. Proton offers the BAA on Proton for Business plans, not on free personal accounts.

Sending PHI from a free Proton account is a HIPAA violation regardless of encryption strength. The signed BAA is what makes Proton a business associate under 45 CFR 164.502(e). Without it, the covered entity carries the full liability for any exposure.

Signing the BAA covers the service. It does not cover configuration. The practice still owns access controls, session timeouts, audit log review, and workforce training. The HHS Security Rule lays out the technical safeguards a covered entity must apply.

Retention is another common gap. Proton offers configurable retention, but the default may not match a state medical board rule. Admins should review retention against the state records law before turning users loose on protonmail encrypted email for PHI.

ProtonMail Runs on OpenPGP Underneath

ProtonMail uses OpenPGP as the underlying protocol for message encryption between Proton accounts and for external users who supply a PGP public key. This is the same OpenPGP standard documented by the IETF in RFC 4880.

What Proton adds is automation. Key generation happens on account creation. Key storage lives inside the encrypted account. Key exchange with other Proton users happens transparently. Users never see a keyring or a fingerprint.

That transparency is the main difference from a manual PGP setup like Thunderbird with Enigmail. The cryptography is the same. The user experience is different by a wide margin.

The tradeoff is portability. Moving off Proton means exporting keys, importing them into another PGP client, and re-establishing trust with every external contact. A useful encrypted email definition includes the operational reality of key portability, not only the algorithm. See how to send encrypted email for the practical workflow comparison.

[mh_example]

Free ProtonMail Accounts Have Real Limits for Business Use

The free tier gives one address, 1 GB of storage, and 150 messages per day. Custom domain support is not available. Support is community-based. No BAA is offered.

Those limits work for a personal user. They fail for a clinic. A three-person practice will hit the daily message cap by mid-morning during a normal appointment cycle.

Paid business plans start with more storage, custom domain support, more addresses per user, and access to the BAA. Pricing tiers change over time, so verify current pricing on the Proton for Business page before quoting internally.

Common free-tier gaps that surface later:

  • No custom domain, so all mail sends from a proton.me address
  • No BAA, blocking any legitimate PHI use
  • 150-message daily cap on outbound
  • 1 GB total storage across mail, calendar, and drive
  • No priority support when delivery fails
protonmail encrypted email in article illustration two

Proton for Business Supports Custom Domains

A professional healthcare practice needs to send from clinic-name.com, not a shared proton.me address. Proton for Business plans support custom domains through standard DNS records.

Setup runs through the Proton admin console. The admin adds the domain, receives an ownership TXT record, and adds MX, SPF, DKIM, and DMARC records at the DNS provider. Propagation takes minutes to hours depending on the registrar.

Google sender guidelines for Gmail and Microsoft Exchange Online guidance both call for aligned SPF and DKIM. A Proton-hosted domain with correct SPF, DKIM, and DMARC lands in the inbox for most recipients on the first send.

Existing tenants on Google Workspace or Microsoft 365 face a migration decision when moving to Proton. Mailboxes, calendars, contacts, and delegation rules all have to move. That migration cost is a common reason practices keep Google or Microsoft and add a HIPAA gateway on top instead.

ProtonMail Versus Standard TLS-Only Email

Regular Gmail and Outlook use TLS between mail servers when both sides support it. TLS protects the message in transit. The provider holds the plaintext at rest and can decrypt any stored mail.

ProtonMail adds zero-access encryption at rest. That is the meaningful difference for a privacy-focused user. If Proton is subpoenaed, it can turn over ciphertext but not readable content of stored mail.

For a HIPAA workflow, both models can qualify with the right BAA and configuration. The security posture of the whole stack matters more than any single layer. Email is one component of the PHI chain, alongside EHR, storage, and endpoint controls.

What TLS-only fails to cover is external delivery to a non-secure recipient. That is where a portal-based or gateway-based encryption layer becomes necessary regardless of which mail provider the practice uses.

[mh_protip]

Encrypted Email Meaning Depends on the Threat Model

Encrypted email is a broad label. The encrypted email meaning shifts based on what the sender is protecting against and who they consider a threat.

Against a passive network snoop, TLS in transit is often enough. Against a compromised provider or a lawful order, only end-to-end or zero-access encryption keeps content sealed. Against a phishing attack on the recipient, no encryption model helps because the recipient hands over the credentials voluntarily.

A useful encrypted email definition for healthcare covers three layers:

  • Encryption in transit between mail servers, usually TLS 1.2 or 1.3
  • Encryption at rest on the provider, either provider-held or zero-access
  • Encrypted delivery to external recipients through a portal or S/MIME

ProtonMail covers layers two and three natively. See how to send an encrypted email for the walk-through on the portal step from a sender view. A gateway product covers layer three on top of Gmail or Microsoft 365 without moving the mailbox.

Feature Comparison Across Common Encrypted Email Options

The table below summarizes how ProtonMail compares to a native Microsoft 365 or Google Workspace tenant with encryption features enabled.

Feature ProtonMail Business Microsoft 365 with Purview Google Workspace with S/MIME
End-to-end encryption inside org Yes, native OpenPGP Optional with S/MIME Optional with S/MIME
Zero-access at rest Yes No, provider holds keys No, provider holds keys
External recipient delivery Password portal Portal or one-time passcode S/MIME certificate exchange
Custom domain support Yes on paid plans Yes Yes
BAA offered Yes on Business plans Yes on Business Premium and above Yes on Business Standard and above
Third-party app ecosystem Limited Broad Broad

A practice already invested in Microsoft or Google will find the migration cost of a full switch to Proton hard to justify unless zero-access at rest is a stated requirement.

When ProtonMail Fits and When a Gateway Fits Better

ProtonMail fits a solo practitioner or a small clinic starting from scratch on email. The account, the BAA, and the encryption story all come from one vendor. Setup is fast.

It fits any user whose threat model includes the provider itself. Zero-access at rest is what Proton offers that Microsoft and Google do not.

A gateway on top of Gmail or Outlook fits a practice already running on Google Workspace or Microsoft 365. The mailbox does not move. Users keep their existing inbox and their existing threading. The gateway handles encrypted delivery to external recipients. See how to troubleshoot encrypted email when deliverability fails.

Mailhippo operates as this kind of gateway. It sits alongside Gmail or Outlook, includes a BAA in the base plan, and handles the external recipient step with one click. For practices comparing options, the deciding factor is usually whether the existing mail platform is going to move. If it is not, a gateway is the lower-friction path. Practices that also need a compliant public-facing site can pair this with HIPAA-conscious healthcare website design so the whole intake chain stays consistent.

[mh_faqs]

Posted on

Encryption and Email Security in a Layered Stack

encryption and email guide featured image

[mh_key_takeaways]

Encryption is a checkbox item on most email security procurement forms. It sits next to inbound filtering, DLP, archiving, and identity controls. Buyers who focus on one checkbox at a time miss how the layers depend on each other.

This guide covers how encryption and email security fit together in a working stack. Where a healthcare team needs the outbound layer without integrating four vendors, a dedicated secure email service with a BAA in the base plan often solves the immediate compliance gap.

Read the sections in order. Each layer covers a different threat and a different auditor concern.

The Email Security Stack Has Five Layers

A complete email security posture combines five functional layers. Each addresses a different risk.

  • Inbound filtering removes phishing, malware, and business email compromise before delivery.
  • Identity controls including MFA and conditional access stop credential theft at the mailbox.
  • DLP scans outbound messages for sensitive content and enforces policy actions.
  • Outbound encryption protects message content in transit and at rest for regulated data.
  • Archiving preserves all inbound and outbound mail in tamper-evident storage for compliance.

Skipping any layer creates a gap. Filtering without encryption leaves outbound leakage. Encryption without filtering leaves the inbox exposed to the phishing that steals the credentials that bypass the encryption.

Buyers evaluating a single feature should confirm what covers the other four.

encryption and email in article illustration one

Encryption Handles Outbound Confidentiality

Email encryption operates on outbound messages. It transforms the body and attachments into ciphertext readable only by the intended recipient.

TLS handles server-to-server transport encryption. S/MIME or hosted portal services handle content encryption end to end. Both layers combine to protect messages from interception and unauthorized access.

Related guide: email encryption covers the methods and standards in depth. See also encryption for email and files.

Encryption does not protect against outbound errors. A workforce member emailing PHI to the wrong recipient still commits a HIPAA breach even when the message is encrypted correctly to that wrong address.

The DLP layer catches that case. Encryption alone does not.

Inbound Filtering Blocks Threats Before Delivery

Inbound filtering scans every incoming message against spam signatures, malware analysis, URL reputation, and behavioral indicators of business email compromise.

Microsoft Defender for Office 365 and Google Workspace Security Sandbox both bundle inbound filtering with their mail platforms. Third-party vendors like Proofpoint, Mimecast, and Barracuda offer specialized inbound protection.

Filtering catches most commodity threats. Sophisticated targeted attacks still get through occasionally. That is why the layer above it, identity controls, matters.

The CISA guidance on phishing and ransomware covers the current threat landscape that inbound filtering has to handle.

Healthcare senders face specific targeting because PHI has direct resale value. Filtering configuration for healthcare typically runs stricter than for general business.

[mh_example]

DLP Enforces Policy on Sensitive Content

Data loss prevention scans outbound content for defined patterns and enforces automatic policy actions.

Common patterns include Social Security numbers, credit card numbers, medical record numbers, ICD-10 codes, and custom keyword lists specific to the organization.

Policy actions include block and notify the sender, quarantine for admin review, redirect to a manager, or apply encryption automatically. That last option closes the gap between manual encryption decisions and consistent compliance.

Microsoft Purview DLP and Google Workspace Data Loss Prevention both include predefined content types. Custom rules cover organization-specific patterns.

Test DLP rules against a monitored test mailbox before pushing to production. False positives on internal messages create friction that pushes users toward personal accounts.

encryption and email in article illustration two

VPNs Add a Network Layer That Overlaps Partially

A VPN encrypts the network path between a client device and the VPN provider. It matters when workforce members send email from public Wi-Fi or shared networks.

The VPN protects the traffic from the coffee shop to the VPN endpoint. From there, the traffic exits to the mail server as normal internet traffic protected by the mail platform TLS.

Once the message leaves the sender mail server and travels to the recipient mail server, the VPN provides no protection. The message needs TLS between the mail servers and content encryption for the body itself.

A VPN is not a substitute for email encryption. It protects the first mile only. HIPAA-regulated content still requires end-to-end encryption on the message itself.

Practices deploying VPNs should still deploy email encryption. The layers cover different segments of the message journey.

Archiving Preserves Compliance Evidence

Archiving captures every inbound and outbound message at the gateway and stores it in tamper-evident form for defined retention periods.

HIPAA calls for six-year retention of documentation supporting security policies, which includes evidence of PHI communications. SOX requires seven years of financial records. FINRA requires three years of broker communications with clients.

The archive protects against message tampering after delivery, which matters during litigation and audit. Users cannot delete archived copies from their mailbox to hide activity.

Some vendors bundle archiving with encryption in one product. Others sell them separately. Buyers should confirm which vendor covers each function to avoid gaps or duplicate contracts.

The archive itself must also be encrypted at rest. Vendors typically use AES-256 with keys managed by the customer or the vendor per contract.

[mh_protip]

Identity Controls Guard the Mailbox Access Point

Encryption and filtering both fail when an attacker holds the legitimate mailbox credentials. Identity controls prevent that scenario.

Multi-factor authentication blocks most credential theft attacks. Conditional access rules restrict logins to known devices, networks, or geographies. Session timeout controls limit exposure when devices are left unattended.

Microsoft Entra ID and Google Workspace identity both include MFA and conditional access as core features. Enforce MFA for every workforce member with mailbox access.

Compromised mailbox credentials are the entry point for most business email compromise attacks. See the Microsoft business email compromise guidance for attack patterns and defenses.

Identity controls are cheap compared to the breach cost they prevent. Deploy them before adding more expensive encryption or filtering products.

HIPAA Requires the Full Stack for Covered Entities

HIPAA covered entities need every layer of the stack for the Security Rule and Privacy Rule requirements.

Encryption meets the transmission security safeguard. Inbound filtering supports the malicious software safeguard. DLP supports the administrative safeguard against workforce error. Archiving supports the six-year documentation retention requirement.

Each vendor that touches PHI signs a business associate agreement. Consolidated platforms simplify BAA management by putting encryption, filtering, and archiving under one contract. Specialized services require separate BAAs.

The HHS Security Rule guidance lists every safeguard the covered entity must implement.

Practices running patient-facing websites face parallel obligations. See healthcare website security features for the site-side controls that pair with the email stack.

Choosing Between Consolidated and Best-of-Breed Vendors

Buyers face a decision between one platform that covers every layer and multiple specialized vendors that each cover one layer well.

Consolidated platforms from Microsoft, Google, or major security vendors deliver encryption, filtering, DLP, and archiving through one console. Reporting is unified. One contract covers everything. Small practices favor this model for administrative simplicity.

Specialized vendors focus on one layer and often deliver a better recipient experience or specific compliance feature. Larger organizations mix a consolidated inbound filter with a specialized outbound encryption service like Mailhippo that delivers encrypted email without portal friction.

Related guides: email encryption solutions comparison, email encryption solutions for Outlook and Gmail, and HIPAA compliant texting and email.

Match the vendor mix to the operational team size. A one-person IT department cannot maintain four separate consoles. A dedicated security team can extract value from specialized products that a consolidated platform cannot match.

Neither approach is wrong. The wrong choice is buying encryption in isolation and ignoring the other four layers.

[mh_faqs]

Posted on

How Do I Send an Encrypted Email in Outlook, Gmail, and Yahoo

how do i send an encrypted email guide featured image

[mh_key_takeaways]

Sending an encrypted email looks different in every mail client. The button is in a different place in Outlook, Gmail, Yahoo, and Apple Mail. Some clients offer true end-to-end encryption while others offer a portal-based feature that looks similar but works differently.

This guide walks through the exact steps for each major provider. It also flags the HIPAA implications for practices sending PHI. For a gateway option that works across all of them, Mailhippo offers encrypted email as a portal service with a BAA in the base plan.

Start with the client you already use. Every section stands on its own with the buttons and menu paths named directly.

Sending Encrypted Email in Outlook 365

Outlook on Microsoft 365 Business Standard and above has an Encrypt button in the compose window. It uses Microsoft Purview Message Encryption underneath.

Open a new message. Click the Options tab in the ribbon. Click Encrypt. Choose Encrypt-Only or Do Not Forward from the dropdown menu that appears.

Write the message and click Send. The recipient receives an email with a link. They authenticate with Microsoft, Google, or a one-time passcode and read the message in a browser.

Business Basic and free personal Outlook.com do not have the Encrypt button. Upgrading to Business Standard or higher unlocks it. Related linked topic: how do you encrypt an email in outlook for the setup on older versions.

Sending Encrypted Email in Gmail With Confidential Mode

Gmail confidential mode is available on personal Gmail and every paid Google Workspace tier. Open a new message. Click the lock and clock icon at the bottom of the compose window.

Set an expiration date. Choose whether to require a passcode. Click Save. Write the message and click Send. The recipient receives a link and reads the message in a hosted view.

Confidential mode is not end-to-end encryption. Google holds the keys. The mode adds an extra step for the recipient and prevents forwarding, but the content is not sealed against the provider.

For a HIPAA workflow, confidential mode alone is not sufficient even with a BAA. Practices sending PHI need either hosted S/MIME on the Enterprise tier or a third-party gateway. See Google confidential mode documentation for the current feature list.

how do i send an encrypted email in article illustration one

Sending Encrypted Email in Gmail With Hosted S/MIME

Hosted S/MIME is the Gmail path to true end-to-end encryption. It requires Google Workspace Enterprise Standard, Enterprise Plus, Education Standard, or Education Plus.

The admin uploads root and intermediate CA certificates in the Google Admin console. They enable S/MIME for the organizational unit. Each user then uploads their personal certificate through Gmail settings under Accounts.

Once configured, a lock icon appears next to the recipient field in the compose window. Green means encryption is possible because the recipient certificate is cached. Gray means the recipient certificate is missing.

Recipients on personal Gmail, Business Standard, or Business Plus cannot receive hosted S/MIME encrypted messages. The encrypted content arrives as an unopenable attachment. This is the main operational limit of S/MIME in a mixed environment.

Sending Encrypted Email in Yahoo Mail

Yahoo Mail has no native encrypted email feature. There is no Encrypt button, no confidential mode, and no hosted S/MIME. Yahoo Mail Plus adds ad-free browsing and more storage but no encryption.

To send encrypted email from a Yahoo address, the practical options are limited. Connect the Yahoo account to Thunderbird by IMAP. Install an S/MIME certificate in Thunderbird. Send encrypted mail from Thunderbird using the Yahoo address as the From address.

The other option is a gateway service that authenticates against the Yahoo account and sends portal-delivered encrypted mail on its behalf. This is a workaround, not a supported feature.

Yahoo does not offer a Business Associate Agreement. Yahoo is not appropriate for HIPAA use. Practices on Yahoo should migrate to Google Workspace, Microsoft 365, or a dedicated healthcare mail provider before starting a real encryption program.

[mh_example]

Sending Encrypted Email in Apple Mail

Apple Mail on macOS and iOS supports S/MIME natively. The user installs an S/MIME certificate in the system keychain. Mail detects the certificate automatically.

On macOS, install the certificate through Keychain Access by opening the PKCS 12 file. On iOS, install through a configuration profile or by tapping the .p12 file in Files or Mail. Trust the certificate in Settings.

Once installed, a lock icon appears in the compose window when the recipient certificate is available. Click the lock to encrypt. A signed message from a recipient adds their public key to the local keychain automatically.

Apple Mail also opens Outlook Encrypt messages and portal-delivered messages from third-party gateways. Cross-platform S/MIME between Apple Mail and Outlook works reliably when both sides use the same certificate authority.

how do i send an encrypted email in article illustration two

Sending Encrypted Email With a Gateway Service

A gateway service sits between the sender mail client and the recipient. The sender writes the message in the normal client. A trigger word in the subject or a plugin button triggers encryption.

The service uploads the message to a hosted portal. The recipient receives a notification with a link. They authenticate with a passcode or SSO and read the message in a browser.

Gateway services work with any mail provider. They add a BAA when the underlying mail provider does not offer one. Setup takes minutes for a single user and hours for a full team.

Related linked topics: how to send an encrypted email for a broader walkthrough and how do I send encrypted email for cross-provider notes.

HIPAA Requirements for Encrypted Email Sending

Sending PHI over email requires a signed Business Associate Agreement with the mail provider and technical safeguards under the Security Rule. Encryption alone does not equal compliance.

Microsoft 365 Business Standard and above and Google Workspace Business Standard and above both offer BAAs. Personal Outlook.com, personal Gmail, personal Yahoo, and personal iCloud do not.

The HHS Security Rule requires access controls, audit logging, session timeouts, and workforce training in addition to encryption. Documentation of policies is required for a defensible program.

Verify recipient identity before sending PHI. A wrong email address is a HIPAA breach even when the message is encrypted. Related: security features for healthcare websites for how email fits inside the wider stack.

[mh_protip]

Encrypted Email Feature Comparison Across Providers

The table below summarizes what each major mail provider offers natively.

Provider Native Encryption Feature End-to-End BAA Available Free Tier Encrypted Send
Outlook 365 Business Standard+ Encrypt button, Purview No, portal-based Yes No
Gmail Workspace Business Confidential mode No Yes on Business Standard+ Confidential mode only
Gmail Workspace Enterprise Hosted S/MIME Yes Yes Not on personal
Yahoo Mail None native No No No
Apple Mail on iCloud+ Manual S/MIME Yes with certificate No Manual setup only
ProtonMail Business Password-protected portal Yes to Proton, portal to others Yes on Business Free tier has portal send

Common Sending Problems and Their Fixes

The Encrypt button is missing in Outlook. This happens on Business Basic or free personal Outlook.com. Upgrade to Business Standard or above, or use a gateway service.

The S/MIME lock icon is gray in Gmail. This means the recipient certificate is not cached. Ask the recipient to send you a signed message first. The certificate cache populates automatically from signed inbound mail.

The recipient cannot open the encrypted message. Common causes:

  • Recipient client does not support S/MIME (personal Gmail, Business Standard Workspace)
  • Notification email landed in spam
  • Recipient failed the passcode step
  • Certificate address mismatch on the sender side
  • Corporate firewall blocks the portal domain

Related linked topic: how do I open an encrypted email in outlook for recipient-side fixes.

Picking the Right Sending Path for Your Practice

Practices already on Microsoft 365 Business Standard or above should use the native Encrypt button for external mail. Setup is minutes. The BAA is already in place.

Practices on Google Workspace Business Standard should use confidential mode for casual privacy and add a gateway service for HIPAA-scoped mail. Upgrading to Enterprise for hosted S/MIME is often costlier than the gateway approach.

Practices on Yahoo, iCloud, or free personal accounts need to migrate to a business mail provider before starting a real encrypted email program. No workaround makes those tiers HIPAA-appropriate.

Mailhippo works as the gateway option across all of these providers. It sits alongside Gmail or Outlook, includes a BAA in the base plan, and requires no per-user certificate management. Practices building a compliant public site alongside their email program can pair this with HIPAA-conscious website design so the whole intake chain stays inside the same compliance boundary.

[mh_faqs]

Posted on

Encrypted Email Guide for Business and HIPAA Workflows

encrypted email guide featured image

[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.

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.

[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.

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.

[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]

Posted on

Email Encryption Programs Explained for Small Practices and Solo Providers

email encryption programs guide featured image

[mh_key_takeaways]

Email encryption programs protect messages that carry protected health information, financial records, or legal documents as they travel between mail servers and inboxes. The category covers native features built into Outlook and Gmail, browser plugins, and dedicated gateway services that route mail through a policy layer.

Choosing between them looks simple until a practice tries to deploy one across a staff of ten and a rotating list of referral partners. This guide compares the real options, explains what each protocol actually does, and covers the HIPAA rules that shape the decision. For clinics sending patient data every day, a HIPAA-ready encrypted email service removes most of the friction.

The wrong program does not just leak data. It also produces a workflow so awkward that staff bypass it to finish the day. Below is what actually works.

Native client encryption is the starting point for most offices

Outlook, Apple Mail, and iOS Mail all support S/MIME natively. Once an IT team installs an X.509 certificate on the user device, the Encrypt button appears in the compose window and the mail app handles the cryptographic work.

Gmail supports S/MIME on Google Workspace Enterprise and Education plans. Confidential mode is a separate feature that adds expiration and passcode gating but is not true end-to-end encryption. The message still sits on Google servers in a form Google can read.

Microsoft 365 Business Premium and higher include Purview Message Encryption. Staff click Encrypt in the Options ribbon, pick a policy, and Outlook handles the rest. External recipients get a portal link and sign in with Microsoft, Google, or a one-time passcode.

Native features work when everyone uses the same platform. The moment referrals cross between Outlook, Gmail, and older Exchange servers, gaps appear. That is where dedicated encryption for email gateway tools earn their subscription cost.

Free email encryption programs have real limits for HIPAA workflows

Mailvelope, an OpenPGP browser extension, encrypts Gmail and Outlook Web messages from inside the browser. Enigmail forks and GnuPG add PGP to desktop clients like Thunderbird. Both are free and technically strong.

The problem is not the cryptography. It is the operational model. Every recipient needs a keypair, a way to publish the public key, and a habit of protecting the private key. Patients and small billing partners rarely meet any of those requirements.

Free tools also do not sign a Business Associate Agreement. HHS makes the BAA a hard requirement at 45 CFR 164.308(b) for any vendor that processes PHI. Without that document on file, a covered entity carries the compliance risk alone.

Practices that want a free email encryption service for personal correspondence can use these tools safely. For clinical email, the missing BAA rules them out. This is the single most common mistake in small-office HIPAA audits.

email encryption programs in article illustration one

S/MIME and OpenPGP handle key management differently

S/MIME relies on a hierarchy of certificate authorities. A trusted CA issues each user a certificate, mail clients verify certificates against a root store, and revocation lists let administrators kill a compromised key. The model matches how corporate IT already thinks about identity.

OpenPGP uses a decentralized web of trust. Users sign each other keys, publish public keys to a keyserver, and rely on personal verification rather than a central authority. It is powerful for technical users and painful for everyone else.

Neither protocol encrypts the subject line or the To and From headers. Metadata leaks through both. NIST covers key management requirements in Special Publication 800-175B, available at nist.gov/publications.

Practices adopting S/MIME need a plan for certificate renewal, mobile provisioning, and revocation. Practices adopting OpenPGP need a plan for user training. Both are legitimate paths, but neither is a low-effort choice.

Gateway encryption services remove the recipient key problem

A gateway service sits between the practice mail server and the wider internet. When the outbound message matches a policy, the gateway diverts it to a secure web portal and sends the recipient a notification with a link.

The recipient clicks the link, verifies identity through a one-time code or federated login, and reads the message in a browser. No plugin, no certificate, no keypair. This is the pattern behind Microsoft Purview, Google client-side encryption, and dedicated HIPAA services.

Gateway tools also produce audit logs that show when the recipient opened the message, when the link expired, and whether the message was forwarded. Those logs feed directly into the HIPAA risk analysis process.

For practices comparing options, the deciding question is usually recipient experience. If patients reply from phones, gateway wins. If all recipients are corporate IT-managed staff, native S/MIME works. A more detailed best free email encryption solution comparison can help narrow the shortlist.

[mh_example]

Deployment paths differ across Outlook, Gmail, and Apple Mail

For Microsoft 365 Business Premium and Enterprise plans, administrators enable Purview Message Encryption in the Exchange admin center, publish rights management templates, and the Encrypt button appears in Outlook for every user. Microsoft documents the full path at learn.microsoft.com/purview.

For Google Workspace, S/MIME requires the Enterprise plan. Administrators upload each user certificate to the admin console, and Gmail activates the encrypt option in compose. Confidential mode works on all plans but is not a HIPAA control by itself.

For Apple Mail on macOS and iOS, users import certificates into the keychain and the Encrypt lock icon appears in the compose window. Mobile device management profiles can push certificates automatically to staff phones.

Deployment complexity grows with the mix of platforms. A practice on a single Microsoft tenant has the easiest path. A practice with staff on Gmail, Outlook, and personal iPhones needs either uniform S/MIME provisioning or a gateway service to bridge the gap.

Comparison of common email encryption programs

The table below shows how the three main categories compare on cost, recipient experience, and HIPAA fit. Practices should treat this as a starting point rather than a purchasing rule.

Program type Cost model Recipient experience BAA available
Native S/MIME (Outlook, Apple Mail) Included in Microsoft 365 Business Premium or Google Workspace Enterprise Requires recipient certificate Through Microsoft or Google BAA
OpenPGP plugin (Mailvelope, GnuPG) Free Requires recipient PGP keypair No
Gateway service (Microsoft Purview, dedicated HIPAA) Per user per month Portal login with one-time passcode Yes, included in HIPAA plans
Confidential mode (Gmail) Included in Google Workspace Passcode or in-Gmail preview Not sufficient alone

Cost per seat rarely tells the full story. Total cost also includes support tickets when recipients cannot open a message, certificate renewal work, and the compliance risk of a program that does not sign a BAA.

email encryption programs in article illustration two

HIPAA rules that shape the encryption program decision

The HIPAA Security Rule at 45 CFR 164.312(e)(1) treats transmission security as an addressable standard. Addressable does not mean optional. It means the practice must implement the safeguard or document why an equivalent alternative works.

HHS guidance points to NIST 800-52 Rev. 2 for TLS baselines and NIST 800-175B for cryptographic key management. Both documents are free at csrc.nist.gov/publications. Auditors expect to see specific citations in the practice policy documents.

The Business Associate Agreement requirement at 45 CFR 164.308(b) covers any vendor that creates, receives, maintains, or transmits PHI. That includes the email encryption vendor. A signed BAA on file before go-live is not negotiable.

Practices building a HIPAA-compliant patient communications program should also review healthcare website security features that carry the same rigor into the web layer where patient forms and portals live.

User training determines whether encryption actually gets used

Buying an encryption program is one line item. Getting staff to use it every time PHI leaves the office is a different project. Training programs that focus on when to encrypt work better than training that focuses on how.

Effective training covers the practical scenarios. A referral letter to another clinic, a claim to a billing partner, an intake form sent back to a patient, a lab report forwarded to a specialist. Each one is a moment where a staff member decides to encrypt.

Policy-based gateway services reduce the training burden by making the decision automatic. If the message contains a subject keyword, a policy trigger, or goes to a domain on the encryption list, the gateway encrypts without a manual click.

  • Train new hires in the first week, not the first month
  • Include encryption steps in the intake and referral workflows
  • Test the process quarterly with a live send to a personal address
  • Document exceptions where encryption was skipped and why

[mh_protip]

Cost breakdown across common encryption program tiers

Free tools cost nothing but time. Staff spend hours provisioning keypairs, and IT spends hours resolving recipient errors. For a two-person clinic that sends encrypted mail twice a week, that math might still work.

Microsoft 365 Business Premium runs about $22 per user per month and includes Purview Message Encryption. Google Workspace Enterprise Standard starts higher but includes S/MIME and client-side encryption controls.

Dedicated HIPAA email services typically price between $5 and $15 per user per month with the BAA included. That range covers the encryption itself, the portal, audit logs, and support. For a five-person office, the total sits around $50 to $75 a month.

Practices that also invest in HIPAA-compliant website design and encrypted email together get consistent controls across the patient-facing surface and the back-office communication layer.

Migration paths from a free tool to a HIPAA-ready service

Practices already using Mailvelope or a similar free tool can migrate in a phased plan. Start by identifying which mail flows carry PHI and which do not. Only the PHI flows need the paid service.

Next, run the new service in parallel for two weeks. Staff send a copy of each encrypted message through both tools and confirm the recipient can open it. This catches configuration errors before the free tool gets turned off.

After the parallel period, publish a written cutover date, decommission the free tool, and export any archived messages the practice needs to retain. HIPAA retention rules at 45 CFR 164.316(b)(2) require six years for policy documentation.

Services designed for healthcare use, including a HIPAA-compliant secure email service, plug into existing Gmail or Outlook accounts and remove the recipient key problem in a single onboarding step.

Ongoing controls that keep an encryption program compliant

Encryption controls decay over time. Certificates expire, staff turn over, recipient domains change hands, and vendors update their portals. A control that worked last year may not work this year.

NIST recommends quarterly verification of encryption controls as part of the risk analysis process. A simple test send to an external address, review of the message headers, and confirmation of the portal login flow catches most drift issues.

  • Review the BAA renewal date with each vendor annually
  • Rotate S/MIME certificates before expiration, not after
  • Audit access logs quarterly for portal-based services
  • Update the risk analysis document after any material change
  • Test disaster recovery for encrypted mail at least once a year

Practices that pair encryption controls with strong healthcare website maintenance keep the entire patient communications stack aligned. Encryption is one layer. The web layer, the endpoint layer, and the training layer all need the same maintenance rhythm to hold up under audit.

The HHS Office for Civil Rights publishes enforcement actions at hhs.gov/hipaa/enforcement. Reading the recent cases shows which encryption gaps trigger investigations. Almost every settlement includes a missing or outdated risk analysis.

[mh_faqs]

Posted on

How to Enable Email Encryption in Office 365 for Healthcare Teams

enable email encryption office 365 guide featured image

[mh_key_takeaways]

Healthcare teams running Microsoft 365 already own most of the tools they need to send encrypted email. The Encrypt button in Outlook, mail flow rules in Exchange, and rights management services in Azure combine into a working encryption stack that meets HIPAA transmission requirements.

The gap is configuration. Most practices discover that the default Office 365 tenant does not enable email encryption until an administrator turns it on, assigns the right licenses, and writes a mail flow rule. Teams that want a simpler path often pair Microsoft 365 with a dedicated encrypted email service to skip the per-user setup work.

This guide walks through the exact steps to enable email encryption in Office 365 from the admin center, PowerShell, and Outlook. It also covers S/MIME setup, mail flow rules, DLP policies, and the license checks that trip up first-time deployments.

Confirm your Office 365 license includes encryption

License verification comes first. Microsoft Purview Message Encryption ships with Microsoft 365 E3, E5, A3, A5, G3, G5, Business Premium, and Office 365 E3 and E5 plans.

Business Basic and Business Standard do not include Purview by default. Administrators on those plans add Azure Information Protection Premium P1 as an add-on license, upgrade the tenant, or route encryption through a third-party service.

To check coverage, sign in to the Microsoft 365 admin center, open Billing, then Licenses. Confirm that assigned licenses include Azure Rights Management Service and Microsoft Purview Message Encryption entitlements.

Users without the correct license see the Encrypt button greyed out in Outlook. Fixing that means assigning the license, waiting for the tenant to provision, then having the user sign out and back in to refresh the token.

Activate Azure Rights Management in the admin center

Azure Rights Management is the underlying service that Purview Message Encryption depends on. New tenants have it enabled by default, but tenants created before 2018 or tenants that were manually disabled need activation.

Open the Microsoft 365 admin center. Go to Settings, then Org settings, then Services. Find Microsoft Azure Information Protection and select it. Click Manage Microsoft Azure Information Protection settings, then Activate.

The activation runs in the background. After a few minutes, the service shows as Activated and the tenant is ready for message encryption policies.

Administrators who prefer to script this step run Enable-AadrmService or the newer Set-IRMConfiguration cmdlet through Exchange Online PowerShell. Both approaches produce the same result and are documented in Microsoft Purview Message Encryption setup guides at learn.microsoft.com.

enable email encryption office 365 in article illustration one

Create a mail flow rule to trigger encryption automatically

Manual encryption depends on staff clicking the Encrypt button on every sensitive message. Mail flow rules remove that dependency by triggering encryption based on message content, sender, recipient, or attached sensitivity labels.

Open the Exchange admin center. Go to Mail flow, then Rules. Click the plus icon and select Apply Office 365 Message Encryption and rights protection to messages.

Set the condition to match the trigger you want. Common conditions include the subject or body containing terms like PHI, patient, or diagnosis, or messages sent to external recipients from clinical users.

Choose the RMS template. Encrypt-Only lets recipients forward, while Do Not Forward blocks reply-all, forwarding, and printing. Save the rule and send a test message to confirm the recipient portal loads as expected.

Enable email encryption in Office 365 with PowerShell

PowerShell is the fastest path for IT teams managing multiple tenants or scripted deployments. Install the Exchange Online Management module, then connect with the appropriate global admin credentials.

Run Install-Module with the name ExchangeOnlineManagement once per machine. Then connect with Connect-ExchangeOnline and the global admin user principal name.

Enable the service with Set-IRMConfiguration and the AutomaticServiceUpdateEnabled parameter set to true. Verify state with Get-IRMConfiguration. The output should show ServiceLocation, LicensingLocation, and InternalLicensingEnabled populated with valid values.

Create mail flow rules with New-TransportRule. Bulk operations save hours when standing up encryption across acquired practices, new subsidiaries, or lab environments where a repeatable baseline matters more than a one-time click-through.

[mh_example]

Use the Encrypt button in Outlook desktop and web

Once the tenant is configured, individual senders trigger encryption from Outlook without additional setup. In Outlook desktop, open a new message, click the Options tab, then click Encrypt.

Choose the protection template from the drop-down. Encrypt applies default protection, Do Not Forward blocks reply-all and forwarding, and any custom labels created by the tenant appear alongside the built-in options.

In Outlook on the web, the Encrypt button lives at the top of the new message pane. The behavior is identical to the desktop version, and messages appear in the recipient portal with the same experience.

Mobile users on the Outlook iOS and Android apps get the same Encrypt option under the three-dot menu when composing a message. Recipients open the encrypted message through a portal link and sign in with Microsoft, Google, or a one-time passcode.

enable email encryption office 365 in article illustration two

Configure S/MIME for regulated communications

S/MIME provides cryptographic identity verification on top of encryption. It requires certificate distribution to every user and device, which raises the operational cost but delivers sender authentication for compliance-critical exchanges.

Deploy a certificate authority or use a public CA. Push user certificates through Group Policy, Intune, or manual import into the personal certificate store. Confirm the store shows the certificate under Trusted Publishers.

In Outlook 2007 and later, open File, Options, Trust Center, Trust Center Settings, Email Security. Under Encrypted Email, select the S/MIME certificate. Check the boxes to sign outgoing messages and encrypt content and attachments.

S/MIME becomes practical for teams with an existing PKI. Small practices without one usually get better outcomes from Purview Message Encryption or a third-party secure email service that handles keys behind the scenes.

Layer DLP policies on top of encryption rules

Data loss prevention policies inspect messages for regulated content patterns. When a match hits, the policy applies encryption automatically or blocks the message and notifies the sender.

Open the Microsoft Purview compliance portal. Go to Data loss prevention, then Policies. Click Create policy and choose the U.S. Health Insurance Act (HIPAA) template as a starting point.

The template detects patterns like Social Security numbers, ICD-10 codes, DEA numbers, and insurance member IDs. Set the action to apply Purview Message Encryption when the policy matches an outbound message.

Tune the policy over the first two weeks. Review the DLP alert dashboard, adjust match confidence thresholds, and add exceptions for internal training data or test accounts. A tuned policy catches PHI leaks without blocking legitimate clinical email.

[mh_protip]

Test the encryption workflow end to end

Testing catches misconfigured rules before staff sends real PHI through a broken flow. Set up two accounts. Use one licensed Office 365 mailbox as the sender and one external Gmail or Yahoo account as the recipient.

Send a test message with the word PHI in the subject line to trigger the mail flow rule. The external recipient should receive a wrapper message with a link to view the encrypted content.

Open the portal link. Sign in with a Microsoft account, a Google account, or request a one-time passcode. Confirm the message body renders correctly, and reply from the portal to test round-trip encryption.

Document each step with screenshots. Save the DLP report, the mail flow rule configuration, and the PowerShell output. This documentation becomes evidence during HIPAA audits, business associate reviews, and internal security assessments.

Match encryption with the HIPAA Security Rule

The HIPAA Security Rule addresses transmission security under 45 CFR 164.312(e). Encryption is an addressable standard, which means covered entities either implement it or document a reasonable alternative.

Office 365 encryption meets the transmission standard when configured with the mail flow rules and DLP policies described above. Practices should also enable multi-factor authentication, conditional access, and audit logging to satisfy access control and integrity standards.

The HHS Security Rule guidance outlines the full set of technical safeguards. Encryption alone does not satisfy the rule, but it addresses one of the more visible controls that auditors ask about first.

Healthcare organizations also need a signed business associate agreement (BAA) with Microsoft. The BAA is available through the Microsoft Service Trust Portal and covers Office 365, Exchange Online, and Purview Message Encryption when configured for HIPAA workloads. Compliance also depends on healthcare website security features that protect the public-facing side of the practice.

Choose between native encryption and a dedicated service

Native Office 365 encryption works well for organizations that already run on Microsoft 365 E3 or Business Premium and have IT staff to manage mail flow rules, license assignments, and Purview policies.

Small practices without dedicated IT often find the setup and ongoing maintenance costly. Every license change, tenant migration, or Outlook update creates a potential point of failure that a solo IT contractor needs to troubleshoot.

Mailhippo works alongside existing Gmail or Outlook accounts as a HIPAA-compliant secure email service. The base plan includes a business associate agreement and applies TLS with client-side encryption without requiring PGP keys or separate client software. Recipients open messages with one click.

Teams building the workflow further may want to look at enable office 365 email encryption, review outlook 365 enable encryption email options, or benchmark against email encryption office 365 business premium to confirm the plan level covers the needed features.

  • Confirm license coverage before touching mail flow rules.
  • Activate Azure Rights Management once per tenant.
  • Script repeat deployments with PowerShell instead of the admin UI.
  • Layer DLP policies on top of manual encryption for PHI patterns.
  • Document the full configuration for HIPAA audit evidence.

[mh_faqs]

Posted on

Proton Mail Encrypted Email Explained for 2026

proton mail encrypted email guide featured image

[mh_key_takeaways]

Proton Mail encrypted email uses end-to-end encryption by default on every message stored on its servers. The sender private key stays on the sender device, and the recipient private key stays on the recipient device.

Proton positioned the service as a privacy-first alternative to Gmail and Outlook. The cryptographic model attracted journalists, security researchers, and privacy-conscious individuals first, then expanded into business plans that include a business associate agreement for regulated users. Practices evaluating encrypted email options often compare Proton Mail against portal-based services and zero-step alternatives.

This guide walks through how Proton Mail encryption actually works on the wire, what the different Proton Mail plans cover, and where practices with heavy external mail volume face friction.

Proton Mail encrypted email cryptographic model

Proton Mail generates a key pair on the user device at account creation. The public key uploads to Proton servers and appears in the user profile. The private key stays on the device, encrypted with a hash of the account password.

Every message stored on Proton servers uses one of two encryption states. Messages between Proton accounts encrypt with the recipient public key, decrypt only with the recipient private key. Messages from external senders encrypt at rest with the recipient public key after arrival.

The model means Proton Mail cannot read stored messages even under legal request. The Swiss court can subpoena the metadata and any unencrypted account information, but not the message body of encrypted messages.

The tradeoff is account recovery. Losing the account password without an active recovery method also loses access to every encrypted message in the mailbox. Proton warns about this state at signup and offers a recovery phrase to mitigate the risk.

Proton Mail encrypted email to Proton Mail recipients

Messages between two Proton Mail accounts encrypt automatically without any sender action. The composer detects the recipient Proton public key and applies encryption in the browser or app before the message leaves the sender device.

The recipient sees a lock icon at the top of the message. Clicking the lock shows the cryptographic details, including the signing key fingerprint and the encryption algorithm.

Reply and forward inside Proton Mail also stay encrypted end to end. The sender does not need to remember to enable encryption because the default is on for every Proton-to-Proton exchange.

This flow gives Proton Mail its strongest security guarantee. Practices with a homogeneous Proton Mail user base get end-to-end encryption without any user education or password sharing step.

proton mail encrypted email in article illustration one

Proton Mail encrypted email to non-Proton recipients

Messages to Gmail, Outlook, or other non-Proton recipients require the sender to enable password-based encryption in the composer. The sender picks a password and shares it out of band with the recipient.

Proton Mail sends a notification email to the recipient with a portal link. The recipient clicks the link, enters the shared password, and reads the message inside the browser. The portal supports reply, which sends the reply back through the same portal encrypted with the same password.

The portal step is the biggest source of friction for high-volume senders. A patient who forgets the password calls the office. A patient who does not read the notification email misses the message entirely.

The reply to encrypted email workflow describes how the portal reply flow handles common cases like attachments, quoted text, and multi-message threads.

Proton Mail encrypted email PGP interoperability

Proton Mail supports PGP for interoperability with other encrypted email systems. Senders upload a recipient PGP public key to a Proton contact card. Outbound messages to that contact encrypt with the recipient key.

Inbound PGP messages decrypt with the Proton Mail private key when the external sender used the Proton public key. Proton Mail publishes its public keys through the Proton Web Key Directory endpoint at proton.me/.well-known/openpgpkey.

PGP interoperability makes Proton Mail workable for security researchers, journalists, and technical users who already exchange keys. Configuring PGP takes patience and a working understanding of key management.

For general healthcare use, PGP key exchange is too complex to scale across a patient population. Most patients cannot generate a PGP key, and asking them to do so violates the reasonable and appropriate standard in the HIPAA Security Rule.

[mh_example]

Proton Mail Business plans and HIPAA eligibility

Proton Mail Free at $0 per month and Proton Mail Plus at $4.99 per user per month do not include a business associate agreement. Neither plan can be used for PHI.

Proton Business Suite at $12.99 per user per month includes a signed BAA. The BAA covers Proton Mail, Proton Drive, Proton Calendar, and Proton VPN. Practices accept the BAA in the admin console during onboarding.

Configure the required admin settings after accepting the BAA. Enable two-factor authentication on every account. Set the Proton retention window to meet the six-year Privacy Rule requirement. Disable Bridge access for accounts that do not need IMAP or SMTP relay through desktop clients.

Reference the current plan matrix at Proton Business plans and the sample BAA provisions at HHS sample BAA provisions before adoption.

proton mail encrypted email in article illustration two

Google Mail encrypted email comparison

Gmail encrypts every message in transit with TLS on every Workspace tier. That is the baseline layer. Confidential mode adds link expiry and passcode options on every tier as a second layer, though the message content stays readable to Google.

Gmail S/MIME on Enterprise Plus adds certificate-based encryption. Users install an S/MIME certificate in the Workspace admin console. Outbound messages to recipients with a public certificate encrypt automatically.

Gmail signs a BAA on paid Workspace plans configured for HIPAA. The BAA covers Gmail, Drive, Calendar, Meet, and other core services. Practices sending real PHI usually stack a portal-based encryption service on top for cases when the recipient does not have S/MIME.

Compared with Proton Mail, Gmail treats encryption as opt-in. Proton Mail treats encryption as the default. See encrypted email service by proton for a deeper feature comparison against alternatives.

Canary Mail and third party encrypted email clients

Canary Mail is a third party mail client for iOS, Mac, and Windows that adds S/MIME and PGP encryption on top of any IMAP or Exchange account. Users install Canary Mail, connect their Gmail or Outlook account, and generate keys inside the client.

Canary Mail does not run its own mail server. The underlying mail service handles storage and BAA obligations. Canary Mail is a UI layer on top of the existing account.

Canary Mail Pro at $49 per year adds unlimited encryption features and read receipts. The free tier limits encryption to a small number of messages per month.

Users on apple mail encrypted email setups sometimes prefer Canary Mail for the tighter S/MIME integration. Canary Mail on the desktop bridges to iOS through iCloud sync of the certificate store.

[mh_protip]

Encrypted zip as a fallback for encrypted mail

Encrypted zip attaches a password-protected archive to a normal email. The sender shares the password through a separate channel like SMS or phone. The recipient extracts the archive with the password.

The pattern works everywhere and does not require any special mail server or client. Security depends on password strength and the out-of-band password channel.

HIPAA compliance treats encrypted zip as a reasonable and appropriate safeguard when configured with AES-256 encryption and a strong password. The Windows built-in zip does not support AES. Use 7-Zip or WinZip Pro to produce AES-256 archives.

Encrypted zip does not scale. Every message requires manual password sharing. Every recipient needs zip software that supports AES. Automated services like Mailhippo remove the manual step and standardize the recipient experience.

Proton Mail encrypted email limitations and workarounds

Proton Mail encryption breaks in a few common scenarios. Auto-forwarding rules to non-Proton accounts strip the end-to-end encryption on the forwarded copy. Legacy mail clients that connect through Bridge lose the automatic encryption in the client display.

Search inside Proton Mail runs against the client-side decrypted copy. Server-side search is not possible because the server cannot read the content. On large mailboxes, search performance drops compared to Gmail or Outlook server search.

Common workarounds:

  • Disable auto-forwarding on any account that carries PHI
  • Use the Proton Mail app rather than a legacy IMAP client
  • Set a longer local search index window on the app
  • Enable Bridge only for accounts that require it
  • Rotate the account password on the standard 60 to 90 day cycle

When to pick a HIPAA alternative to Proton Mail encrypted email

Practices with heavy external patient mail volume often face portal password support tickets. A five-person practice sending 200 encrypted messages per week to 200 unique patients handles 200 password sessions per week.

A zero-step encryption service like Mailhippo removes the portal step. Encrypted messages arrive directly in the recipient normal Gmail or Outlook inbox and open like any other message. The sender picks Mailhippo in the toolbar for messages that need encryption and skips it for messages that do not.

Practices running HIPAA compliant website design already understand the reasonable and appropriate standard. Applying the same standard to email means picking the tool that keeps compliance tight while dropping recipient friction. See also security features for healthcare websites for the parallel web guidance.

For further reference, review NIST SP 800-177 Trustworthy Email and the HIPAA Journal guide to compliant email before finalizing the encrypted mail stack. See encrypted email and send encrypted email for related walkthroughs.

[mh_faqs]

Posted on

HIPAA Secure Email Explained (Requirements, Providers, Setup)

hipaa secure email guide featured image

[mh_key_takeaways]

Every provider claiming to sell HIPAA secure email is technically selling a set of features and a legal agreement. HIPAA does not certify products.

The practice buys tools that let it meet the Security Rule, and the practice remains responsible for how those tools are used. A HIPAA-compliant email service like Mailhippo covers the encryption, the BAA, and the audit logging in one bundle so the practice does not have to assemble three separate products.

This guide walks through what actually makes an email service HIPAA secure, the provider options at each price tier, and the setup steps that separate a compliant workflow from a technically encrypted mess.

The Security Rule sets the requirements, not the vendor

The HIPAA Security Rule lists administrative, physical, and technical safeguards for electronic protected health information. Email falls under transmission security, access control, and audit control.

Encryption is an addressable specification, which means the covered entity has to implement it if it is reasonable and appropriate. In practice, HHS treats encryption as the default expectation for external PHI transmission.

No product carries a HIPAA certification. Any provider claiming to be HIPAA-certified is misrepresenting how the law works. Products can be HIPAA-ready or HIPAA-eligible, meaning they support the features a covered entity needs.

The covered entity is responsible for the workflow around the product. Buying compliant software and using it non-compliantly still produces a breach.

Three requirements separate secure email from ordinary email

Encryption is the first requirement. TLS 1.2 or higher for transit, AES-128 or AES-256 for content and storage. The exact ciphers and key lengths are documented in NIST Special Publication 800-52 Rev. 2 and NIST 800-111.

A signed business associate agreement is the second. The BAA makes the provider legally responsible as a business associate under HIPAA. Without it, sharing PHI with the provider is unauthorized regardless of the encryption.

Audit logging is the third. Administrators need to pull records showing who sent what, when, to whom, and whether the message was encrypted. Logs need to be retained for at least six years to match HIPAA’s records requirement.

Missing any of the three disqualifies the product. Practices that focus only on encryption discover during an incident that they cannot pull logs or that the provider never signed a BAA.

hipaa secure email in article illustration one

Big platform providers work if the plan tier is right

Google Workspace signs BAAs on all paid plans starting at Business Starter. The BAA covers Gmail, Calendar, Drive, Meet, and several other core services.

Microsoft 365 signs BAAs on business and enterprise plans. Business Basic and higher qualify. Outlook.com consumer accounts do not.

Both platforms encrypt messages at rest with provider-managed keys and use TLS 1.2 or higher for transit whenever the receiving server supports it. External delivery is the gap. Neither guarantees TLS on outbound if the receiver does not enforce it.

For full external encryption, Google Workspace practices need Enterprise Plus for native S/MIME or a third-party gateway. Microsoft 365 practices need Business Premium for the Purview Encrypt button or a similar gateway.

Dedicated healthcare email services simplify the setup

Dedicated HIPAA email services focus on the healthcare workflow specifically. Mailhippo, Paubox, LuxSci, Hushmail, TrueVault, and Enguard all fit this category.

The common pattern is a BAA in the base plan, encryption on every outbound message by default, and a simpler admin interface than the big platforms. Prices typically run $5 to $30 per user per month depending on the feature set.

Some services replace the mailbox entirely. Enguard, Hushmail, and Paubox on their hosted-mailbox tiers provide a full mail service including the mailbox, the encryption, and the compliance controls.

Others layer over existing Gmail or Outlook. Mailhippo and Paubox both offer gateway options that let the practice keep its current email address and inbox while the service handles the encryption and BAA.

[mh_example]

Enterprise appliances suit large hospital systems

Cisco Secure Email Encryption Service, Barracuda Email Protection, and Proofpoint Email Encryption serve large healthcare organizations. Each integrates with the organization’s broader security stack and its email security gateway.

These products cost more per user, require dedicated administration, and typically involve a services engagement to deploy. In return, they deliver deep integration with SIEM, DLP, and identity systems.

For a solo practice or small group, enterprise appliances are overkill. For a 500-provider hospital system with existing Cisco infrastructure, they are usually the right tier. Practices comparing options often review the enterprise secure email encryption service cisco tier alongside the smaller-practice choices.

All three enterprise vendors sign BAAs and support the technical safeguards HIPAA requires. The differentiators are scale, integration, and administrative model.

hipaa secure email in article illustration two

Free HIPAA secure email is not a real category

Every provider that signs a BAA charges for the service. The BAA carries legal liability, and the vendor prices that liability into the plan.

Free encrypted email tiers exist for personal use. ProtonMail, Tutanota, and CounterMail all offer free tiers. None of them sign a BAA at the free level.

The lowest-cost real HIPAA secure email starts around $5 per user per month. Google Workspace Business Starter, Microsoft 365 Business Basic, and small-practice-tier Mailhippo all fall in that range.

Practices that try to build a compliant workflow on free tools spend the savings on incident response the first time a message leaks. The math favors paying for a base plan.

The four-step setup workflow

Step one is signing the BAA. On Google Workspace, that lives in the Admin console under Account, Legal and compliance. On Microsoft 365, it is in the Service Trust Portal. Dedicated services usually include the BAA in the sign-up flow.

Step two is configuring encryption for outbound external mail. That is either native S/MIME, a portal-based product like Purview or Mailhippo, or a gateway that enforces encryption on all outbound.

Step three is access control. Enforce multi-factor authentication, disable legacy protocols like POP and IMAP unless required, and set role-based permissions so only staff who need PHI access have it.

Step four is documentation. A two-page policy covering the tool, the trigger, the recipient handling, and the annual review satisfies OCR expectations. The HHS Security Rule guidance and NIST SP 800-66 Rev. 2 outline the documentation elements.

[mh_protip]

What providers include and what they leave to the practice

Every provider handles the technical safeguards on their infrastructure. Encryption in transit and at rest, physical security of the data centers, redundancy, and platform-level access controls are the vendor’s job.

The practice handles the administrative safeguards. Staff training, policies and procedures, workforce clearance, sanctions for policy violations, and the risk analysis all sit with the covered entity.

The practice also handles the workforce-level access decisions. Who has an email account, what role they have, what content they are authorized to send, and how they authenticate.

A provider signing a BAA does not transfer the practice’s obligations. It shares the technical burden and it creates a legally responsible partner for the covered entity’s transmissions.

Common configuration mistakes that fail an audit

Forgetting to sign the BAA is the most common mistake. Practices that subscribe to Google Workspace or Microsoft 365 assume the BAA is automatic. It is not. A super administrator has to accept the BAA explicitly.

Leaving legacy protocols enabled is the second common mistake. POP and IMAP predate modern authentication and often bypass multi-factor requirements. Disable them for any account that does not need them.

Skipping audit log configuration is the third. Both Google and Microsoft log by default, but retention settings often need to be extended to meet HIPAA’s six-year record requirement.

Practices comparing options often check hipaa compliant secure email reviews and is email hipaa secure explainers before making the final call, because vendor marketing pages rarely surface these configuration details.

Choosing a provider based on the practice’s size and stack

A solo practitioner or small clinic usually gets the best fit from a dedicated healthcare service like Mailhippo. Setup takes an hour, the BAA is in the base plan, and the monthly cost is under $20.

A group practice already on Google Workspace or Microsoft 365 usually stays on the big platform and adds a gateway. Switching mail providers for a 30-person practice is a bigger project than adding an encryption layer.

A large hospital system with existing enterprise security infrastructure typically routes email through Cisco, Barracuda, or Proofpoint. The scale justifies the appliance cost and the administrative overhead.

Whichever provider fits, the practice’s marketing and patient acquisition side should match the security posture. Agencies specializing in healthcare marketing and healthcare website maintenance keep the intake forms, appointment reminders, and outbound clinical mail on a consistent compliance track.

  • Verify the BAA is signed and current for every service that touches PHI.
  • Confirm encryption for internal, external, transit, and at-rest paths.
  • Enforce multi-factor authentication and disable legacy protocols.
  • Enable and retain audit logs for at least six years.
  • Document the workflow, train annually, and review the setup once a year.

A HIPAA secure email service is a combination of encryption, a signed BAA, audit logging, and a documented workflow. Any product that delivers the four pieces qualifies. The differentiator between providers is how much of the setup the vendor handles and how much stays with the practice.

[mh_faqs]

Posted on

How Do I Send Encrypted Email in Outlook, Gmail, and Yahoo

how do i send encrypted email guide featured image

[mh_key_takeaways]

Sending encrypted email is straightforward once you know which method your client supports. Outlook 365, Outlook 2010 through 2016, Gmail, and Yahoo each handle encryption differently, and the right method depends on both your sender platform and your recipient.

This guide walks through each client step by step, then compares the methods. If you need a service that layers on top of any of these clients with a signed business associate agreement, see the overview of encrypted email options.

The audience assumed here is a business user or clinician who wants to send an encrypted message today, not a developer building an integration.

How to send encrypted email in Outlook 365

Outlook 365 on Business Premium, Enterprise E3, or Enterprise E5 includes the Encrypt button in the Options ribbon. This is the fastest path if your account is on a qualifying plan.

Compose a new message. Click Options in the ribbon. Click Encrypt. Choose Encrypt-Only for a message the recipient can reply and forward. Choose Do Not Forward for a message where you want to restrict sharing.

Send the message. The recipient on your own tenant sees the message inline in Outlook with a lock icon. External recipients see a notification email with a Read the message button. Clicking the button opens the Office 365 message encryption portal in a browser.

Setup requires an admin to enable Azure Rights Management on the tenant. Full guidance is published by Microsoft in the Microsoft Purview Message Encryption reference. If Encrypt is missing from your ribbon, your tenant or license does not have Purview enabled.

How to send encrypted email in Outlook 2010, 2013, and 2016

These versions do not include the modern Encrypt button that appears in Outlook 365. Encryption uses S/MIME certificates and works well for organizations where both sender and recipient have certificates issued through corporate PKI or a public certificate authority.

Import your certificate through File, Options, Trust Center, Trust Center Settings, Email Security. Click Import Export and load your certificate file. Enter the password and complete the import. Outlook now has your certificate bound to your mailbox.

Compose a new message. In the message window, click Options in the ribbon, then click the small dialog launcher in the More Options group. In the Properties dialog, click Security Settings. Check Encrypt message contents and attachments. Click OK. Send.

The recipient needs a matching certificate to decrypt. This is where S/MIME breaks down for ad hoc external mail. For enterprise-to-enterprise and government correspondence, S/MIME works well. For consumer mail, use portal-based encryption instead. The how do I send an encrypted email in Outlook guide covers additional edge cases.

how do i send encrypted email in article illustration one

How to send encrypted email in Gmail

Gmail on Google Workspace offers two paths. Gmail on a personal account has no HIPAA-grade encryption option at all.

Confidential mode is available on every Gmail account. Click the padlock and clock icon in the compose window, set an expiration and a passcode option, and send. This restricts forwarding, printing, downloading, and copying. It does not encrypt content at rest inside Gmail systems.

Google Workspace client-side encryption applies true end-to-end encryption for qualifying tiers. An admin configures a client-side encryption identity for the account. Once configured, the sender can toggle client-side encryption on a message. Recipients must also be configured for client-side encryption to decrypt.

For the widest recipient reach and healthcare use, a dedicated secure email service that installs as a Gmail add-on gives you a Send Encrypted button that routes the message through the vendor. The recipient reads it in a portal. This is the simplest path for a solo practice or small clinic.

How to send encrypted email in Yahoo Mail

Yahoo Mail does not offer a built-in message encryption feature. There is no Send Encrypted button in Yahoo, and Yahoo does not sign a business associate agreement for HIPAA use.

Yahoo servers use TLS between mail servers, which protects messages in transit when the receiving server supports TLS. This is a baseline measure that any modern mail provider offers. TLS alone is not equivalent to end-to-end or message-level encryption.

To send encrypted email from a Yahoo address, you have two practical options. Use a third-party encryption service that can send on your behalf and reply through a portal. Or move the encrypted correspondence to a provider that supports encryption natively.

Yahoo is not a supported platform for HIPAA-covered mail. A therapist or medical office running client communications through a Yahoo address is not compliant regardless of what encryption is added on top of the sending experience. Change providers first.

[mh_example]

Comparing the encryption methods across clients

The methods trade off between ease of use, recipient reach, and compliance strength. This table lays out the practical differences.

MethodSender platformRecipient reachCompliance-grade
Outlook 365 Encrypt buttonBusiness Premium and upAny recipient via portalYes with BAA on tenant
S/MIME certificateOutlook 2010 to 2016 and 365Recipients with certificatesYes when configured
Gmail confidential modeAny Gmail accountAny recipientNo, not on its own
Gmail client-side encryptionQualifying Workspace tiersWorkspace with CSE identityYes with BAA on tenant
Yahoo nativeNone availableNot applicableNo
Dedicated encrypted email serviceAny client with plug-in or webAny recipient via portalYes with vendor BAA

Portal-based methods reach any recipient. Certificate-based methods only work between correspondents with matching PKI infrastructure. Choose based on who you actually send to.

For solo practices sending to patients on consumer email, portal-based encryption is the reliable default. The how to send encrypted email guide covers the sender workflow in more detail.

how do i send encrypted email in article illustration two

Choosing between Encrypt-Only and Do Not Forward in Outlook

Outlook’s Encrypt button gives two options that trip up new users. The right choice depends on how much control you need after the message leaves your outbox.

Encrypt-Only encrypts the message content and attachments. The recipient can reply and forward. Any forwarded copy remains encrypted. This is the right choice for a normal sensitive message where the recipient may legitimately need to share it with a colleague.

Do Not Forward encrypts the message and also blocks forwarding, reply-all, printing, copying, and attachment download. This is the right choice for a legal notice, an executive communication, or a message where you want tight distribution control.

Both options use Microsoft Purview Message Encryption underneath. The distinction is in the rights template applied to the message. Guidance on rights templates is in the Microsoft Azure Rights Management documentation.

Recipient experience across encryption methods

The sender picks the method. The recipient lives with it. Understanding the recipient experience for each method helps a sender choose the right one for the audience.

Portal-based encryption gives the recipient a notification email with a link. The recipient clicks, signs in with a one-time passcode or a linked account, and reads the message in a browser. First-time recipients often need a short explanation of the flow.

S/MIME opens the message inline in the recipient mail client once the recipient certificate is installed. There is no portal step. If the certificate is missing, the message body appears garbled or refuses to open.

Confidential mode from Gmail sends the recipient a link to a Google-hosted view where the message opens after optional passcode verification. Downloads and forwarding are blocked but the underlying storage is not encrypted at rest.

[mh_protip]

When each method is the right choice

Method choice comes down to who you send to and what compliance obligation applies. The following patterns match methods to typical use cases.

  • Sending to patients on any consumer email: portal-based encryption from Outlook 365 or a dedicated encrypted email service
  • Sending to another business on Microsoft 365: Outlook 365 Encrypt button, message opens inline for the recipient
  • Sending to a corporate or government recipient with existing S/MIME: import certificates and use S/MIME
  • Sending non-PHI internal-sensitive mail inside Google Workspace: Gmail confidential mode is acceptable for the sensitivity but not for HIPAA
  • Sending high-volume transactional email programmatically: a HIPAA-eligible email API through a vendor with a BAA

Match the method to the strictest requirement in the message flow. A healthcare practice that sends both internal-sensitive and patient-covered mail needs the patient-covered method for both, not the internal-sensitive method for the mix.

Practices with a website that also collects sensitive information should align their web infrastructure with the email choice. Redefine Web covers relevant patterns in the overview of healthcare website security features.

Troubleshooting common send failures

Encryption send failures usually trace back to configuration rather than the message itself. The following symptoms map to specific fixes.

Missing Encrypt button in Outlook 365 means the account is not on a qualifying plan or the tenant has not enabled Azure Rights Management. The fix is either a license upgrade or an admin action on the tenant.

S/MIME send fails with a certificate error means the recipient certificate is not available. Outlook cannot encrypt to a recipient whose public certificate has not been previously received. Ask the recipient to send you a signed message first so their certificate is captured.

Recipient reports the portal login fails with a one-time passcode. Passcodes expire after fifteen minutes. Ask the recipient to request a fresh code and use it immediately. Some corporate spam filters delay the passcode delivery past the expiration window, in which case an alternate email address is needed. The National Institute of Standards and Technology publishes recommended email security guidance in NIST SP 800-177 Rev. 1.

Setting up encrypted email once so future sends are easier

Sending encrypted email should not be a per-message decision. Configure the account once so the workflow is consistent across all correspondence.

For Outlook 365, ask your admin to set default encryption on messages to certain external domains through a mail flow rule. This means messages to patient addresses or partner accounts are always encrypted without the sender toggling the button.

For dedicated encrypted email services, install the Gmail or Outlook plug-in on every workstation used by clinical or administrative staff. Enable the default-encrypt behavior in the service settings so no untrained sender accidentally sends plain text.

Document the workflow in a one-page internal reference. Include screenshots of the Encrypt button, the confidential mode toggle, or the plug-in send button as appropriate. New staff can then reach compliant sending on their first day rather than after weeks of trial and error.

[mh_faqs]

2637 E. Atlantic Blvd.
#1063 Pompano Beach, FL 33062

© 2026 MailHippo, Inc.

View our Privacy Policy or contact our Customer Service team.

Optometrist Marketing Agency – Web Design, SEO, PPC & Maintenance