HorizLogoSm.fw_.png
Start Trial

Tag: tls

Posted on

How to Send Encrypted Email Across Any Client

how to send encrypted email guide featured image

[mh_key_takeaways]

Every modern mail client can send encrypted email, but the definition of encrypted varies across methods. Some protect only the connection between mail servers. Others protect the message content itself. The difference matters for compliance and for real security.

This guide covers how to send encrypted email across Gmail, Outlook, Apple Mail, and portal-based services. Each method has a specific use case, a specific setup cost, and a specific recipient experience.

The right method depends on the sensitivity of the content and the technical setup of the recipient. Match the tool to the message.

TLS Is the Default Encryption Layer for Every Modern Mail Server

Transport Layer Security, or TLS, protects the connection between two mail servers. When Gmail sends to Outlook, both servers negotiate a TLS handshake and encrypt the traffic in flight. Any observer on the network path sees only ciphertext.

TLS is on by default in Gmail, Outlook, Apple Mail, Yahoo Mail, and every other major provider. Users do not enable it. Administrators do not configure it. It happens automatically when both servers support it.

The problem is fallback. If the receiving server does not support TLS, the sending server delivers the message in plaintext by default. There is no warning. The message reaches the recipient. The sender assumes it was encrypted because their client showed a padlock.

For any content that is regulated, the opportunistic fallback rules out TLS as a standalone protection. You cannot verify that every recipient server supports TLS. According to NIST SP 800-45, verified end-to-end encryption is the required protection for sensitive email.

S/MIME Provides Message-Level Encryption in Outlook and Apple Mail

S/MIME uses X.509 certificates to encrypt the message content itself, not just the transport. Once encrypted, only the recipient with the matching private key can read it. The mail provider stores ciphertext and cannot decrypt.

Outlook supports S/MIME on all Microsoft 365 plans that include the desktop apps. Apple Mail supports S/MIME natively on macOS and iOS. Gmail supports S/MIME on Workspace Enterprise Plus, Education Standard, and Education Plus.

Setup requires a certificate for the sender and a certificate for the recipient. Both must come from a trusted certificate authority. The public key gets attached to signed emails, so correspondents can build up a keyring by receiving signed messages from each other.

S/MIME suits organizations that can deploy certificates across all their staff and partners. It does not suit external correspondents like patients, vendors, or one-off recipients who do not have a certificate installed.

how to send encrypted email in article illustration one

PGP Delivers the Same Protection with a Different Key Model

PGP, or Pretty Good Privacy, is the open-source alternative to S/MIME. It uses a public-private key pair generated locally by the user. The public key is shared. The private key is protected with a passphrase and stays on the sender machine.

Thunderbird includes PGP support by default. Mailvelope adds PGP to Gmail and Outlook Web through a browser extension. GPG Suite adds it to Apple Mail. The GNU Privacy Guard command-line tool underlies most implementations.

PGP does not require a certificate authority. Users trust each other public keys directly, either through personal verification or through a web-of-trust model where mutual acquaintances sign each other keys. This is more flexible than S/MIME but harder for non-technical users to manage.

PGP suits technical teams, security researchers, and correspondents who exchange keys manually. It does not suit a healthcare workflow where a receptionist needs to email a lab result to a patient who has never generated a key pair.

Outlook Encrypt Button Uses Microsoft Purview Message Encryption

Outlook 365 users on Business Premium, E3, E5, and comparable Education plans get an Encrypt button in the Options ribbon of the compose window. Behind the scenes, this triggers Microsoft Purview Message Encryption.

External recipients receive a portal link and sign in with Microsoft, Google, or a one-time passcode. Internal recipients on the same tenant see the message inline in Outlook or Outlook on the web without the portal step.

Setup takes minutes if Azure Rights Management is already enabled on the tenant. For tenants that have not activated it, an administrator must enable Rights Management under the Microsoft 365 Admin Center before the Encrypt button appears in Outlook.

According to Microsoft documentation, Purview Message Encryption meets HIPAA transmission requirements when combined with a signed business associate agreement, available on Microsoft 365 Business plans and higher.

[mh_example]

Portal-Based Services Remove the Recipient Setup Barrier

Portal-based encrypted email services solve the biggest problem with S/MIME and PGP. The recipient does not need to install anything, configure anything, or generate any keys. They receive a notification, click a link, and read the message in a browser.

Mailhippo works as an SMTP relay. The sender continues to write and send from Gmail, Outlook, or any other client. Mailhippo intercepts the message, encrypts it, and delivers over TLS when the recipient server supports it or through a portal link when it does not.

The recipient experience is one click. They receive a notification email, click the link, authenticate with a one-time passcode sent to their phone or email, and read the message in a browser. No account creation. No software.

For HIPAA, the service includes a signed BAA in the base plan and logs every message access. Healthcare organizations use this model because patient recipients cannot be expected to manage keys or install plug-ins.

how to send encrypted email in article illustration two

Comparison Across the Main Methods

Each method has a specific fit. The table below summarizes the practical tradeoffs.

Method End-to-End Recipient Setup HIPAA Ready Best For
TLS No None No, opportunistic fallback Non-sensitive routine mail
S/MIME Yes Certificate install Yes, with BAA Internal certified teams
PGP Yes Key pair generation Yes, with process controls Technical correspondents
Purview Message Encryption Yes Portal or Microsoft login Yes, with M365 BAA Microsoft 365 users
Portal-based service Yes Click and passcode Yes, with BAA in base plan External recipients, patients

The clearest divide is recipient friction. S/MIME and PGP are excellent when both parties are set up. Portal-based services and Purview handle every recipient without setup, which matters for healthcare and any business email compliance workflow.

Gmail Encryption Steps Depend on the Workspace Tier

Personal Gmail supports TLS by default and Confidential Mode as an inbox-level access control. It does not support S/MIME. For encryption beyond TLS, personal Gmail users need a browser plug-in for PGP or a third-party service.

Workspace Business tiers support TLS and Confidential Mode. S/MIME hosted encryption is unavailable at these tiers. Healthcare organizations on Business Standard or Business Plus typically layer a HIPAA-compliant service to close the gap.

Workspace Enterprise Plus, Education Standard, and Education Plus include S/MIME hosted encryption. Administrators enable it in the Admin console under Apps, Google Workspace, Gmail, User settings.

Full step-by-step for the Gmail path is covered in the sibling guide how to send encrypted email in Gmail and the tier-specific instructions in how to send encrypted email using Gmail.

[mh_protip]

Outlook Encryption Steps Depend on the Microsoft 365 Plan

Outlook desktop supports S/MIME on all Microsoft 365 plans that include the desktop apps, provided the user has a certificate installed. The certificate goes into the Windows certificate store or the macOS keychain.

The Encrypt button in the Outlook ribbon requires Microsoft 365 Business Premium or Enterprise E3, E5, or higher. Lower Business tiers do not include Purview Message Encryption. This is the most common gap that surprises small-business owners after a plan upgrade.

For lower Microsoft 365 tiers, the practical path is a portal-based service that adds encryption without requiring the plan upgrade. This suits solo practitioners, small clinics, and small-business teams that need HIPAA-covered email but not the enterprise feature stack.

Verification Steps for Every Sensitive Send

Before sending regulated content, verify the method for that specific send. Do not assume. TLS may have dropped to plaintext. S/MIME may have fallen back because the recipient certificate expired. Purview may have failed to trigger because the tenant setting changed.

  • Check the encryption indicator in the compose window before sending.
  • Confirm the recipient will receive the intended experience by sending a test message with non-sensitive content.
  • For portal-based services, verify the audit log records access after the recipient opens the message.
  • For S/MIME, confirm the padlock or lock icon shows green in the sent copy.

According to HIPAA Journal, the most common documented compliance failure is a sender assuming TLS was in effect when the recipient server had disabled it. Verify per send.

Choose the Method by Recipient and Content

The decision framework is simple. Match the recipient technical setup and the content sensitivity to the encryption method with the lowest friction that still meets the security bar.

  • Internal team, routine content, no regulated data: TLS is sufficient.
  • Internal or partner team with certified users, regulated data: S/MIME or PGP.
  • Microsoft 365 users sending to external recipients: Purview Message Encryption.
  • Any recipient without technical setup, regulated data, HIPAA scope: portal-based service with a BAA.

For healthcare providers coordinating email with website and patient acquisition, encrypted email pairs with HIPAA-compliant website design as part of a broader compliance stack.

The last practical point is that the wrong method causes friction for the recipient, and friction becomes a security risk. Recipients who cannot open an encrypted message will ask for it in plaintext. Pick the method that removes that pressure.

[mh_faqs]

Posted on

Email Encryption Explained (Methods, Standards, and Costs)

email encryption guide featured image

[mh_key_takeaways]

Email encryption sounds like one feature. It is actually a stack of choices about transport, content, keys, licensing, and recipient experience. Getting the stack wrong leaves gaps that compliance auditors find.

This guide covers email encryption methods, the standards that back them, the platforms that implement each one, and the price ranges buyers see. For HIPAA senders who want to skip the license tier upgrade, a dedicated secure email service often removes the portal step and includes a BAA in the base plan.

Read the sections in order. Each layer builds on the one before it.

Transport and Content Encryption Are Different Layers

Two encryption layers cover email. Buyers often confuse them, which leads to gaps.

Transport encryption uses TLS between mail servers. When Gmail sends to Outlook, both servers negotiate TLS 1.2 or 1.3 and the message travels encrypted. Neither user takes any action.

Content encryption protects the message body and attachments themselves. S/MIME, PGP, and hosted portal encryption all fit here. The message remains encrypted at rest in the recipient mailbox until decrypted with a key or portal credential.

TLS alone leaves messages readable at the recipient provider, in server logs, and in backup snapshots. HIPAA and PCI treat that exposure as non-compliant for regulated content. Content encryption fixes it.

Every serious encryption deployment uses both layers together.

email encryption in article illustration one

S/MIME Is the Enterprise Standard for Content Encryption

S/MIME encrypts message bodies using X.509 certificates issued by a certificate authority. It is the default choice for organizations with dedicated IT.

Outlook, Apple Mail, and Google Workspace Enterprise Plus all support S/MIME natively. No plugin required. The mail client handles encryption and decryption behind the compose window.

Setup requires purchasing a personal certificate from a public CA like DigiCert, Sectigo, or GlobalSign, installing it in the local certificate store, and exchanging signed messages with each recipient to share public keys.

Certificates typically expire after twelve months. Renewal happens through the CA portal. Expired certificates block new encrypted sends until reissued.

Related guide: S/MIME email encryption covers the certificate model in detail.

OpenPGP Serves Technical and Journalism Communities

OpenPGP is the alternative content encryption standard. It uses locally generated key pairs instead of CA-issued certificates.

Users install GPG Suite on macOS, Gpg4win on Windows, or Mailvelope in the browser. The tool generates a key pair with a passphrase. The user shares the public key with recipients through a keyserver or direct email.

Trust builds through key signing rather than a central authority. Security researchers, journalists, and open source maintainers use PGP heavily because it does not depend on any CA infrastructure.

Business adoption of PGP stays limited. Recipients cannot install extensions on locked-down corporate systems. Healthcare and financial senders skip PGP for that reason.

The technical strength of PGP is not the barrier. The recipient-side friction is.

[mh_example]

Hosted Encryption Services Handle the Recipient Portal

Hosted encryption trades certificate management for a portal step at the recipient end. Microsoft Purview Message Encryption, Google Workspace Confidential Mode, and many third-party vendors follow this pattern.

The sender clicks Encrypt in the mail client. The service routes the message body to its own storage and sends the recipient a notification email with a link. The recipient signs in with an existing account or enters a one-time passcode to read the message.

Vendor gateways from Fortinet, Cisco, Trustifi, Datamotion, and others all follow the same portal pattern with different admin interfaces and reporting.

The recipient friction depends on the vendor. Some services allow one-click reading through a signed URL. Others require full account creation. Test each with a real recipient before committing.

Related guide: email encryption service compares vendor options in depth.

email encryption in article illustration two

Encryption Techniques and Algorithms in Use Today

The math behind email encryption uses proven algorithms defined in published standards.

  • AES-256 handles symmetric encryption of the message body itself. It appears in every current standard.
  • RSA-2048 or elliptic curve algorithms handle the key exchange that carries the symmetric key to the recipient.
  • SHA-256 or SHA-384 handles integrity hashing so recipients can detect tampering.
  • TLS 1.2 with strong cipher suites, or TLS 1.3 without weak fallback, handles transport between servers.
  • Message authentication codes bind sender identity to the message so recipients can verify origin.

Buyers rarely choose algorithms directly. Every modern platform defaults to combinations aligned with NIST guidance. See the NIST cryptographic guidance publications for the current recommended parameters.

Platform-by-Platform Encryption Options

Each mail platform ships different encryption features at different price tiers.

Microsoft 365 Business Premium and higher include Purview Message Encryption behind the Encrypt button. Business Basic and Business Standard do not.

Google Workspace Enterprise Plus and Education Plus include hosted S/MIME. Business Standard and Business Plus include Confidential Mode but not hosted S/MIME.

Apple Mail supports S/MIME natively on macOS and iOS provided the user installs a certificate through Keychain or MDM configuration profile.

Yahoo, AOL, and older ISP webmail platforms do not offer S/MIME or hosted encryption. Users on those platforms rely on TLS transport plus optional PGP through browser extensions.

Match the plan tier to the required feature before rolling out an encryption program.

[mh_protip]

HIPAA Compliance Requires More Than Encryption

Encryption satisfies one HIPAA Security Rule addressable specification. Full compliance requires several additional safeguards.

The covered entity signs a business associate agreement with the email provider. Microsoft and Google both offer BAAs on eligible plans. The HHS Security Rule guidance lists every safeguard.

Administrative safeguards include workforce training on PHI handling, sanction policies for violations, and periodic risk assessments. Physical safeguards include facility access controls on the workstations that send email.

Technical safeguards beyond encryption include unique user identification, automatic logoff on idle sessions, and audit controls that record message access.

Practices that clip on encryption software without addressing the surrounding safeguards are not compliant. Encryption is one piece of a larger program.

Cost Comparison Across Encryption Approaches

Price often decides the buying question more than features. A ten-person practice compares real annual numbers.

Approach Per user per month Annual cost (10 users)
Microsoft 365 Business Premium (Purview) 22 USD 2,640 USD
Google Workspace Enterprise Plus (hosted S/MIME) 30 USD 3,600 USD
Public CA S/MIME certificates (annual) 2 to 5 USD (amortized) 240 to 600 USD plus mail plan
Dedicated encrypted email service with BAA 5 to 15 USD 600 to 1,800 USD

Numbers exclude staff training, audit review time, and the recipient-side support calls that portal-based encryption generates. Practices measuring hidden costs often find dedicated services cheaper end to end.

How to Choose the Right Encryption Approach

The decision comes down to three questions about the sending organization.

First, does the organization already run Microsoft 365 Business Premium or Google Workspace Enterprise Plus? If yes, native S/MIME or Purview cover the encryption need with no additional software.

Second, does the recipient list change frequently, as with a healthcare practice adding new patients weekly? If yes, hosted encryption or a dedicated service avoids the S/MIME public-key exchange step.

Third, is the recipient experience business-critical? If patients or referring physicians will abandon messages that require a portal sign-in, a dedicated service like Mailhippo delivers encrypted email that opens in one click without a portal.

Practices running healthcare marketing sites pair encrypted email with a compliant patient-facing web presence. See healthcare website security features for the site-side controls.

Related guides: email encryption software, secure email encryption service, and encryption for email techniques.

[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

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

How to Encrypt Email Across Common Clients and Compliance Cases

encrypt email guide featured image

[mh_key_takeaways]

Encrypt email covers four different technical methods that each solve a different problem. Transport Layer Security handles the connection layer. S/MIME and PGP handle the message content. Portal-based services handle the recipient experience for external contacts.

This guide covers how to encrypt email across the major clients and use cases. Each method has a specific fit. Match the tool to the sensitivity of the content and the recipient environment.

The right choice depends on plan level, staff count, and how often external recipients change. Read each section for the fit and decide based on the actual send flow.

TLS Is the Baseline Encryption Every Modern Mail Server Uses

Transport Layer Security protects the connection between two mail servers. When one server sends to another, both negotiate a TLS handshake and encrypt the traffic in flight. Any observer on the network path sees only ciphertext.

TLS is on by default in Gmail, Outlook, Apple Mail, Yahoo, and every other major provider. Users do not turn it on. Administrators do not configure it per message. It happens automatically when both servers support it.

The catch is opportunistic fallback. If the receiving server does not support TLS, the sending server delivers the message in plaintext by default. No warning, no error. The sender sees a padlock in the client and assumes encryption, but the message reached the recipient over an unencrypted link.

For regulated content, the fallback rules out TLS as a standalone protection. The NIST SP 800-45 guide on email security recommends verified end-to-end encryption for sensitive email, not opportunistic TLS.

S/MIME Encrypts Message Content in Outlook and Apple Mail

S/MIME uses X.509 certificates to encrypt the message content itself. Once encrypted, only the recipient with the matching private key can read the message. The mail provider stores ciphertext and cannot decrypt.

Outlook supports S/MIME on all plans that include the desktop apps. Apple Mail supports S/MIME natively on macOS and iOS. Gmail supports S/MIME on Workspace Enterprise Plus, Education Standard, and Education Plus.

Setup requires a certificate for the sender and a certificate for the recipient. Certificates come from a trusted authority like DigiCert, Sectigo, or IdenTrust. Public keys attach to signed messages, so correspondents build up a keyring by receiving signed mail from each other.

S/MIME works well between internal users and formal partner organizations with matching PKI. It does not work well for one-off external contacts because most personal accounts do not have S/MIME set up.

encrypt email in article illustration one

PGP Uses an Open-Source Key Model

PGP is the open-source alternative to S/MIME. It does the same job with a different key management model. Users generate a public and private key pair, share the public key with correspondents, and encrypt messages with the recipient public key.

Thunderbird has built-in PGP support. Mailvelope provides a browser plugin for Gmail. GPG Suite covers Apple Mail on macOS. Outlook needs a third-party add-in like Gpg4win.

PGP has stronger cryptographic flexibility than S/MIME but a steeper learning curve. Key generation, keyserver management, and web-of-trust verification all fall to the user. Recipients unfamiliar with the process will not decrypt a PGP message without help.

PGP fits technical users and organizations where security-conscious sender and recipient both know the tooling. It does not fit patient-facing healthcare communication because most patients cannot manage PGP keys.

Portal Services Handle the External Recipient Case

Portal-based encrypted email services solve the friction problem that S/MIME and PGP create for external recipients. The sender writes the message in the normal client. The service encrypts the message and delivers a notification email with a click-to-open link.

The recipient clicks the link, verifies with a one-time passcode or a portal password, and reads the message in a browser. No key management, no certificate exchange, no software install for the recipient.

This is the model most healthcare practices adopt for patient-facing PHI. It works for patients, external providers, and vendors on any mail platform. The recipient does not need to configure anything on their end.

The tradeoff is that the message content lives on the vendor server. Vendor selection matters because that server becomes part of the compliance boundary. Portal services with a signed BAA and audit logging fit HIPAA. Consumer messaging apps generally do not.

[mh_example]

Encrypting Attachments Follows the Whole-Message Method

Attachments encrypt through the same method as the message body when using Purview, S/MIME, PGP, or a portal service. The sender does not need to encrypt attachments separately. The whole message envelope carries the encryption to the recipient.

Practices that need a separate attachment method have three options:

  • Save the file as a password-protected PDF and share the password through a different channel
  • Place the file in an encrypted ZIP archive using 7-Zip or WinZip with AES-256
  • Use a HIPAA-compliant file transfer service for very large files that exceed mail size limits

The whole-message method is easier for recipients and less error-prone than juggling separate passwords. Password-protected PDFs and ZIP files also fail when the sender emails the password in the same conversation, which happens frequently.

Once a recipient decrypts and downloads an attachment, the local copy is no longer covered by the sender-side encryption. HIPAA rules on the local file remain in force. That is a downstream concern for the recipient environment.

encrypt email in article illustration two

HIPAA Requires More Than the Encrypt Button

HIPAA compliance for email transmission requires four things: a signed business associate agreement with the mail platform, verified encryption in transit and at rest, access logs for six years, and workforce training on when to send PHI over email.

The Encrypt button alone does not cover all four. It covers the transmission layer. The BAA, the logging, and the training all fall to the covered entity to configure and maintain.

Microsoft 365 and Google Workspace both include HIPAA-eligible configurations with signed BAAs. Administrators accept the BAA in the admin center. The BAA applies to the tenant from that point forward. The covered entity handles the rest.

Dedicated HIPAA email services like Mailhippo include the BAA in the base plan without requiring plan upgrades on the underlying mail platform. This matches practices that need HIPAA-safe email but do not want to reconfigure the whole tenant.

Mobile Clients Support the Same Methods

Encrypt email on mobile works through the same methods as desktop. Outlook mobile supports Microsoft Purview Encrypt-Only and Do Not Forward through the same Encrypt option in the compose menu. Recipients open messages in the browser tab or in the Outlook mobile app.

Apple Mail on iOS supports S/MIME natively. Certificates install through a Configuration Profile pushed by mobile device management. The Encrypt icon appears in the compose window once the certificate is available.

Gmail mobile supports Confidential Mode through the standard compose interface. Portal-based encrypted email services provide mobile apps or work through the mobile browser. Mailhippo, Proofpoint, and other vendors all support mobile recipient flows.

The mobile recipient experience matters for patient-facing mail. Many patients read email on a phone. The service should present a clean mobile view of the decrypted message with tap-friendly buttons.

[mh_protip]

Cost Varies From Free to Enterprise Tier

Encrypted email cost ranges widely. TLS is free and included in every mail platform. Gmail Confidential Mode is free with any Gmail account. S/MIME certificates cost fifty to several hundred dollars per user per year depending on the authority and support level.

Microsoft Purview Message Encryption requires Business Premium at around twenty-two dollars per user per month, up from Business Basic at six dollars. That is a plan-wide upgrade, not a per-message cost. Dedicated HIPAA services typically run five to twenty dollars per user per month depending on plan tier.

Practices on Business Basic or Business Standard often find a dedicated HIPAA service costs less than upgrading every seat to Business Premium. The math depends on how many seats need to encrypt versus how many just handle general mail.

Compare total cost of ownership, not just per-seat rate. Setup time, training, and ongoing configuration also count. A simpler service with a higher per-seat rate can cost less overall.

The Recipient Experience Determines Adoption

The single largest factor in encrypted email adoption is the recipient experience. Every step the recipient has to take lowers the open rate on regulated messages. Every extra sign-in or password reset lowers it further.

The rough order from easiest to hardest recipient experience is:

  • TLS message that arrives inline with no extra step
  • Portal service with a one-click link and one-time passcode
  • Portal service with account registration and password
  • S/MIME message that requires certificate pre-install
  • PGP message that requires key pair generation

Practices should match the method to the recipient population. Patient-facing mail needs the simplest recipient path. Internal mail between staff can use a more complex path because the setup is done once during onboarding.

Measure the open rate on encrypted messages. If the rate drops significantly compared to regular mail, the recipient path is too long. Switch to a shorter path.

Mailhippo Handles the HIPAA Case With One-Click Recipient

Mailhippo secure email service works with existing Gmail or Outlook accounts and includes a signed BAA in the base plan. There are no PGP keys, no S/MIME certificates, and no license upgrades on the underlying mail platform.

The sender writes the message in a browser interface or through an add-in. Mailhippo encrypts the content and delivers a notification email to the recipient. The recipient clicks the link, enters a one-time passcode delivered to the same email address, and reads the message.

This is the shortest recipient path among common HIPAA options. Patients on any mail platform can open the message on desktop or mobile. Attachments open inline. Replies encrypt automatically back to the sender.

The broader compliance stack includes healthcare website security features, patient portal configuration, and internal access controls. Encrypted email is one layer. The full stack covers the practice end to end.

[mh_faqs]

Posted on

O365 Email Encryption Explained for Admins

o365 email encryption guide featured image

[mh_key_takeaways]

O365 email encryption is a bundle of features under Microsoft Purview Message Encryption, formerly known as Office 365 Message Encryption. It covers transport encryption, at-rest encryption on Exchange Online, and message-level encryption through a portal delivery model.

This guide walks through the licensing, setup, and known limits. If your tenant needs a supplementary encrypted email path for specific recipient groups or vertical compliance requirements, the vendor-neutral overview is a useful reference.

The audience assumed here is an IT admin or Microsoft 365 tenant owner setting up encryption for the first time or reviewing an existing configuration.

What O365 email encryption covers by default

Every Microsoft 365 tenant gets some encryption automatically. Exchange Online encrypts mail in transit using TLS 1.2 or higher between mail servers when both sides support it. This is the baseline any modern mail provider offers.

Exchange Online also encrypts mail at rest using BitLocker on the underlying storage and per-message encryption keys. This protects mail on disk against a physical theft or storage-layer attack.

The piece that is not on by default is the end-user Encrypt button. On-demand message-level protection requires a licensed feature, either Purview Message Encryption or S/MIME. Both are available on qualifying subscription tiers.

Compliance-covered communication requires the message-level layer in addition to the automatic transport and at-rest layers. Practices sending patient email cannot rely on the default alone. The Encrypt button is what makes the outbound message protected from server to recipient.

Licensing tiers and encryption features

Licensing determines which encryption features are available. The mapping is not obvious from the marketing pages, and admins routinely encounter tenants where the Encrypt button is missing because the license is wrong.

  • Business Basic and Business Standard: TLS and at-rest encryption only, no Encrypt button
  • Business Premium: full Purview Message Encryption including the Encrypt button
  • Enterprise E3: full Purview Message Encryption including the Encrypt button
  • Enterprise E5: Purview plus Advanced Message Encryption for branding, expiration, and revocation
  • Standalone add-on: Azure Information Protection Plan 1 or 2 adds Purview to lower tiers
  • Government: GCC and GCC High tenants have equivalent tiers with same feature mapping

Adding Purview to a Business Basic tenant through Azure Information Protection is technically possible but administratively awkward. Most tenants upgrade to Business Premium instead.

Confirm current licensing through the Microsoft 365 admin center before enabling encryption rules. Microsoft publishes the current feature mapping in the Microsoft Purview Message Encryption documentation.

o365 email encryption in article illustration one

Enabling Purview Message Encryption on the tenant

Enabling Purview requires a few specific steps. On new tenants provisioned after February 2019, Azure Rights Management is enabled by default. On older tenants, an admin needs to enable it through Exchange Online PowerShell.

Connect to Exchange Online PowerShell as a global admin. Run Enable-AadrmService to activate Rights Management on the tenant. Verify the state with Get-AadrmConfiguration. Once active, Purview Message Encryption is available to eligible users.

Assign Azure Information Protection or Message Encryption licenses to users through the admin center. Users see the Encrypt button in the Options ribbon in Outlook the next time they compose a message. Outlook on the web shows the same button in the compose interface.

Test with a compose to an external Gmail or Yahoo address before rolling out to end users. The test verifies the notification email arrives, the portal login works, and the message body renders correctly on the recipient side.

Automating encryption with mail flow rules

Mail flow rules in the Exchange admin center apply encryption automatically based on conditions. This removes the per-message decision from the sender and prevents the plaintext accident.

Common conditions include keyword lists in the subject or body, sender group membership, recipient domain matching, and attachment content patterns. A healthcare practice might trigger encryption on any outbound message to a patient domain list or containing terms like DOB, MRN, or diagnosis.

Configure the rule under Mail flow in the Exchange admin center. Add a new rule. Select Apply Office 365 Message Encryption and rights protection to the message. Choose the encryption template such as Encrypt or Do Not Forward. Save.

Test the rule with a message that matches the condition. Confirm the message is delivered encrypted. Then move on to the next rule. Complex mail flow with many rules can produce order-of-evaluation issues, so keep the rule set small and documented.

[mh_example]

Comparing Purview Message Encryption to S/MIME in O365

Both Purview and S/MIME are supported in O365. They solve different problems and are often deployed together in the same tenant for different use cases.

Attribute Purview Message Encryption S/MIME
Recipient prerequisites None, portal-based Public certificate installed
Setup complexity Tenant-side only Sender and recipient certificate exchange
Recipient experience Portal login Inline in mail client
Reach to any address Yes Only PKI-equipped recipients
Typical fit Business to consumer Government, defense, enterprise PKI
Branding Portal branded on Enterprise E5 No portal to brand

Purview is the modern default for reaching external recipients on any platform. S/MIME is the preferred path when both sides already run PKI and inline decryption is required by policy.

Practices comparing broader alternatives can review the email encryption category overview alongside the Purview and S/MIME options.

Signing and encrypting in the same message

Signing and encryption are separate operations. Some organizations require both on the same message. O365 supports this through S/MIME with certificates installed in Outlook Trust Center.

Signing uses the sender’s signing certificate to hash the message and encrypt the hash with the sender’s private key. The recipient uses the sender’s public certificate to verify the signature. This proves sender identity and message integrity.

Encryption uses the recipient’s public certificate to encrypt the message content. Only the recipient’s private key can decrypt. Applying both operations on the same message provides authenticity and confidentiality together.

Sign-only, encrypt-only, and sign-and-encrypt are all valid options. Government and financial services organizations often mandate sign-and-encrypt as the default. Healthcare practices sending patient email usually apply encryption without signing because recipients are not verifying certificate chains.

o365 email encryption in article illustration two

Branding the recipient portal experience

Advanced Message Encryption on Enterprise E5 supports portal branding. This changes what an external recipient sees when they open the portal to read the encrypted message.

Configure branding through Exchange Online PowerShell using Set-OMEConfiguration. Parameters include OMEConfiguration for logo URL, background color hex, disclaimer text, portal text, and email text. Multiple configurations can be created and mapped to different mail flow rules.

Branding appears when external recipients open the portal. It does not appear on messages viewed inline in Outlook by internal recipients on the same tenant. Branding does not change the encryption itself. It changes the recipient trust signal.

Practices with a website and consistent visual identity often extend the same branding to the encrypted portal. Redefine Web covers the underlying identity work in the overview of healthcare web design.

Encryption at rest and mailbox-level protection

At-rest encryption in Exchange Online uses BitLocker on the underlying storage. This is transparent to admins and users. Every stored mail item is encrypted at the storage layer.

Customer Key is an option on Enterprise E5 and Advanced Compliance add-ons. It allows the customer to provide their own encryption keys used alongside Microsoft-managed keys. Losing the customer key results in permanent data loss, so key management overhead is significant.

Customer Key is a control for regulated industries that require key custody separate from the platform provider. For most healthcare and business use cases, Microsoft-managed keys are sufficient and much easier to operate.

Microsoft publishes the at-rest encryption architecture in the Microsoft Purview encryption reference. The design is aligned with NIST cryptographic guidance in NIST SP 800-52 Rev. 2.

[mh_protip]

Known limitations and workarounds

Every encryption system has limits. Documenting them in advance saves helpdesk hours later.

  • Branding does not appear on messages viewed inline in Outlook, only in the portal view
  • External recipients occasionally lose the portal notification to spam filtering
  • Outlook 2013 requires patching and the Message Encryption add-in for the Protect button
  • S/MIME needs certificate pre-exchange, which is not practical for ad hoc external sends
  • Some compliance frameworks require signing in addition to encryption, doubling the setup work

Workarounds include publishing a short recipient guide, allowlisting the Microsoft notification domain on partner mail servers, and upgrading beyond Outlook 2013. Each mitigation is small individually and adds up to a smoother user experience.

Some organizations supplement O365 encryption with a dedicated email encryption service for specific use cases where the portal experience is not suitable. The two can coexist through mail flow rules that route matching messages through the vertical vendor.

Operational monitoring and audit trails

Encryption is only useful if it stays on. Operational monitoring catches drift, misconfiguration, and user error before they turn into compliance events.

Enable audit log retention for at least six years in the Microsoft Purview compliance portal. HIPAA record-keeping applies to policies and procedures, and the audit log is the evidence trail during any Office for Civil Rights inquiry.

Monitor the Encrypt button usage through Message Trace and Advanced Message Encryption reports. Users who never use the button after a rollout are either not sending sensitive mail or are bypassing the encryption workflow. Both cases warrant follow-up.

Review mail flow rule hits monthly. A rule that produced regular hits then stopped may indicate an upstream change that broke the trigger. Diagnosing early prevents a silent gap in encryption coverage.

Practical rollout plan for a new O365 encryption deployment

A first-time O365 encryption deployment can run in one afternoon for a small tenant or across two weeks for a larger organization. The key stages are the same.

Confirm licenses cover the target user population. Enable Azure Rights Management if not already active. Configure mail flow rules for the initial triggers, such as external mail with specific keywords. Assign encryption-eligible licenses to pilot users.

Pilot with five to ten users for two to three weeks. Collect feedback on the sender workflow and the recipient portal experience. Adjust mail flow rules and branding based on the pilot findings. Roll out to remaining users in staggered groups.

Publish a one-page recipient guide for external partners describing the portal login process. Practices with a broader compliance program should coordinate the rollout with related work such as healthcare website maintenance to keep the whole patient communication stack aligned.

[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

What Is an Encrypted Email

what is an encrypted email guide featured image

[mh_key_takeaways]

An encrypted email is a message that has been scrambled with a cryptographic key so only the intended recipient can read it. The sender applies encryption, the message travels as ciphertext, and the recipient decrypts it back to readable form.

This matters because standard email was designed in the 1980s without built-in encryption. Anyone with access to the network path or the mail server could read the content. Encryption fixes that gap.

Understanding what an encrypted email is starts with two questions. What is being encrypted, and who holds the keys?

Encryption Converts a Message into Unreadable Ciphertext

Encryption takes plaintext, the readable message, and applies a mathematical function called a cipher along with a key. The output is ciphertext, a sequence of bytes that looks like random noise to anyone without the key.

Modern email encryption uses algorithms like AES-256 for symmetric encryption and RSA-2048 or higher for asymmetric encryption. These are the same algorithms that protect online banking, government communications, and enterprise data storage.

The recipient reverses the process. They apply the matching decryption function with the correct key, and the ciphertext becomes readable plaintext again. Without the key, the ciphertext is effectively random data that cannot be reversed by brute force with current computing.

The security of the whole system depends on protecting the key. If an attacker steals the recipient private key, the attacker can decrypt every message sent to that recipient. Key management is why encrypted email deployments require careful setup.

Two Layers of Email Encryption Exist

Email encryption operates at two layers. The transport layer protects the connection between mail servers. The message layer protects the content of the message itself.

Transport encryption uses TLS, the same protocol that protects HTTPS websites. When two mail servers connect, they negotiate a TLS handshake and encrypt the traffic in flight. An observer on the network sees only ciphertext.

Message encryption uses S/MIME, PGP, or a portal-based service. The sender encrypts the message content before it leaves their client. The mail server stores ciphertext. Only the recipient with the matching key can decrypt.

The difference matters for compliance. Transport encryption protects the connection but not the stored copy. Message encryption protects both. For regulated content, message encryption is the standard because it removes the mail server from the trust boundary.

what is an encrypted email in article illustration one

TLS Is the Default Transport Encryption for Modern Email

Every major mail provider, Gmail, Outlook, Yahoo, Apple, and the rest, uses TLS by default. When a sending server contacts a receiving server, it attempts a TLS handshake. If both sides support it, the connection is encrypted.

The user does not enable TLS. The client shows a padlock icon when it is in effect. Gmail shows a gray padlock for TLS, green for S/MIME, red for unencrypted.

TLS has a critical weakness. It is opportunistic. If the receiving server does not support TLS, the sending server delivers the message in plaintext by default. The sender may not see any warning, and the client padlock may still show as green in the Sent folder because the initial hop was encrypted.

This behavior means TLS alone cannot guarantee an encrypted send. For regulated content, opportunistic TLS is not sufficient. According to NIST SP 800-45, verified end-to-end encryption is required for sensitive email.

S/MIME Uses Certificates from a Trusted Authority

S/MIME, or Secure/Multipurpose Internet Mail Extensions, is the built-in message encryption standard for Outlook, Apple Mail, and Gmail on Workspace Enterprise. It uses X.509 certificates issued by a trusted certificate authority.

Each user has a public key certificate that is shared with correspondents and a private key that stays local. When someone sends an encrypted message, they encrypt with the recipient public key. Only the recipient private key can decrypt.

Signing is a separate function that uses the same certificates. A signed message includes a signature computed with the sender private key. Any recipient can verify the signature using the sender public key. This proves the message came from the claimed sender and was not modified in transit.

S/MIME suits organizations that can coordinate certificate deployment across all users. Certificate authorities such as DigiCert, Sectigo, and IdenTrust issue certificates for annual fees between roughly $20 and $100 per user.

[mh_example]

PGP Uses Locally Generated Keys and Personal Trust

PGP, or Pretty Good Privacy, is the open-source alternative to S/MIME. It uses public-private key pairs generated locally by the user. There is no certificate authority. Users trust each other keys directly.

The sender exchanges public keys with the recipient through a side channel, verifies the key fingerprint, and then encrypts messages with the recipient public key. The recipient decrypts with their private key. The private key is protected with a passphrase.

PGP has stronger algorithmic flexibility than S/MIME but a steeper learning curve. Recipients unfamiliar with key exchange will not decrypt a PGP message without setup. Thunderbird, Mailvelope, and GPG Suite provide user interfaces that simplify most of the workflow.

PGP suits technical correspondents, security researchers, journalists working with sources, and internal teams that can standardize on key exchange procedures. It is the wrong tool for reaching general external recipients like patients.

what is an encrypted email in article illustration two

Portal-Based Encrypted Email Removes Recipient Setup

Portal-based services solve the recipient friction problem. The sender writes and sends from their normal client. The service intercepts the message, encrypts it, and delivers over TLS when supported or through a portal link when TLS is unavailable.

Mailhippo works this way. The recipient receives a notification email with a click-to-open link. They enter a one-time passcode sent to their phone or email, and they read the message in a browser. No account creation. No key management. No software install.

For HIPAA, the service includes a signed BAA in the base plan and logs every message access. This is the model most healthcare organizations use because patients and external providers cannot be expected to manage keys or install plug-ins.

The tradeoff is that the encryption happens at the service, not on the sender client. For most healthcare and business contexts, this is acceptable because the service holds a BAA and provides audit logs. For extremely sensitive content, S/MIME with local keys remains the highest-assurance model.

Encrypted Email Is Required for Regulated Content

HIPAA, the US health privacy law, requires encryption in transit for any electronic transmission of protected health information across public networks. The rule is technology-neutral, but auditors expect a verified encryption method with a signed business associate agreement.

GLBA, the financial-services privacy law, imposes similar transmission requirements for customer financial data. PCI DSS covers card data. State privacy laws such as CCPA and NYDFS add their own requirements.

Native TLS in Gmail or Outlook does not automatically meet these standards because of the opportunistic fallback. A HIPAA-compliant service closes the gap by refusing to send in plaintext and delivering through a portal fallback when TLS is unavailable.

For healthcare organizations, this pairs with broader compliance work covered in healthcare website security features and healthcare marketing services.

[mh_protip]

Recipient Experience Varies by Encryption Method

The recipient sees a different experience for each method. TLS is invisible when it works. The message arrives in the inbox looking normal. Nothing signals that transport encryption was applied.

S/MIME shows a lock icon in supported clients. The client decrypts using the recipient certificate and displays the plaintext inline. In an unsupported client, the recipient sees ciphertext or an unopenable attachment.

PGP requires a supported client with the recipient private key installed. Thunderbird, Mailvelope, and GPG Suite decrypt inline. Without the tools, the recipient sees a PGP-formatted block of ciphertext.

Portal-based services deliver a notification email with a click-to-open link. The recipient clicks, authenticates with a one-time passcode, and reads in a browser. This is the lowest-friction path for any recipient without prior setup.

Key Management Is the Practical Security Boundary

The mathematics of modern encryption are resistant to brute force with current computing. AES-256 and RSA-2048 are considered secure through the near future. The practical attack surface is key management, not cipher-breaking.

An attacker who steals a private key can decrypt every message sent to that recipient. Key protection includes strong passphrases on private keys, hardware-backed key storage such as smart cards or hardware security modules, and prompt revocation of keys when a device is lost or an employee leaves.

  • Store private keys in hardware-backed storage when possible.
  • Use strong passphrases on private key files.
  • Revoke certificates and PGP keys promptly on departure or device loss.
  • Log and monitor key access for anomalous activity.

For portal-based services, the equivalent controls are account access management, multi-factor authentication, and audit logging. The service holds the encryption keys, so the sender must trust the service and verify the audit trail.

Choose an Encryption Method Based on Recipient and Content

The right encryption method depends on the recipient technical setup and the content sensitivity. Match the method to the practical situation.

  • Internal team, no regulated content: TLS is sufficient.
  • Internal team, regulated content, certified users: S/MIME.
  • Technical external correspondents, high sensitivity: PGP.
  • External recipients without technical setup, regulated content, HIPAA scope: portal-based service.

For deeper coverage on specific methods, see the sibling guides what does encrypted email mean, what does it mean to encrypt an email, and what happens when you encrypt an email in Outlook.

The one-line summary is that an encrypted email is a message only the intended recipient can read. The method behind that outcome shapes the setup cost, the compliance posture, and the recipient friction. Choose deliberately.

[mh_faqs]

Posted on

What Are Encrypted Emails and How They Actually Work

what are encrypted emails guide featured image

[mh_key_takeaways]

Encrypted emails are messages you cannot read without the right key or credential. The concept is simple. The specific methods, recipient experiences, and edge cases behind it are where confusion starts.

This guide covers what encrypted emails actually are, how Gmail and Outlook handle them, whether they can be forwarded, and how to tell a legitimate encrypted message from a phishing attempt. For senders evaluating an encrypted email service, the recipient experience is often more important than the technical specs.

Read the sections in order. Each one covers a specific question users typically ask.

Encrypted Emails Turn Message Content Into Unreadable Ciphertext

An encrypted email is a message where the content has been transformed into ciphertext that only the intended recipient can decode. Encryption applies at one or more layers of the email delivery path.

Transport encryption using TLS protects the message between mail servers. The message body is readable at the servers themselves but not on the network between them.

Content encryption using S/MIME or PGP protects the message body itself. The message stays encrypted at the recipient mail provider until decrypted by the recipient with a matching key.

Portal-based encryption stores the message on a vendor server and delivers a sign-in link. The recipient authenticates to the vendor portal and reads the message in a browser.

Each method covers different threats. Best practice layers TLS with content or portal encryption rather than relying on transport alone.

Gmail and Encrypted Email Behavior

Gmail encrypts messages automatically for transport but not for content by default. Understanding the difference clears up common questions about Gmail encryption.

Google Workspace uses TLS 1.2 or 1.3 when connecting to receiving servers that support it. Standard consumer Gmail does the same. This transport encryption prevents interception on the network path.

Content encryption in Gmail requires Google Workspace Enterprise Plus for S/MIME. The administrator provisions certificates for users and enables encrypted sending inside the workspace policy.

Add-ons like FlowCrypt and Mailvelope bring PGP-based encryption to any Gmail account. The user installs the browser extension, generates a key pair, and encrypts messages one at a time.

Google Confidential Mode is not content encryption. It adds expiration and access controls but Google retains access to the underlying content. Practices should not treat Confidential Mode as HIPAA-compliant encryption.

what are encrypted emails in article illustration one

Outlook and Encrypted Email Behavior

Outlook supports S/MIME natively across Microsoft 365 Business Premium and higher tiers. The certificate installs into the local certificate store and enables signed and encrypted sending.

Microsoft Purview Message Encryption adds a policy-based layer that triggers on rules configured by the administrator. External recipients receive a portal link and sign in with Microsoft, Google, or a one-time passcode.

Third-party add-ins from Virtru, Mailhippo, and other vendors add another encryption path that works across Microsoft 365 tiers without requiring Business Premium.

Outlook shows encrypted messages with a padlock icon in the header. The message properties confirm the encryption method and certificate details.

Users can verify a sent message was encrypted by checking the Sent Items folder for the same padlock indicator. Related coverage in encrypted emails Outlook covers the specific configuration steps.

Forwarding Encrypted Emails Changes the Encryption Context

Encrypted emails can sometimes be forwarded but the encryption context often changes depending on the method and sender policy.

S/MIME messages forwarded from Outlook typically get decrypted with the original recipient key and re-encrypted for the forward recipient if forwarding is permitted. The forward recipient must have a matching certificate or the message will not decrypt on their end.

Portal-based encrypted messages usually cannot be forwarded because the recipient holds a portal access link, not the underlying content. Some vendors allow the recipient to share the portal link with another user, subject to sender policy.

Sender-set rights management controls decide what forwarding is allowed. Microsoft Purview Message Encryption supports Do Not Forward as a rights template that blocks forwarding entirely.

Practices sending regulated content should default to Do Not Forward and enable forwarding only when the sender explicitly permits it. Blanket forwarding permissions undermine the sender control that encryption otherwise provides.

[mh_example]

Encrypted Email Comparison Across Common Methods

The table below compares four common encryption methods across the fields that decide recipient experience and security posture.

MethodRecipient StepsContent Encrypted at RestForwarding BehaviorTypical Use
TLS Transport OnlyNoneNoFreely forwardableStandard business email
S/MIMECertificate installedYesRe-encrypted per recipientEnterprise between certificate holders
PGPKey installedYesRe-encrypted per recipientTechnical users, journalists
Portal EncryptionClick link, sign inYes on vendor serverUsually blockedHealthcare, finance to external recipients

Real-world deployments often layer TLS with either content or portal encryption. The layered approach covers more threats than any single method alone.

Why You Might Be Getting Encrypted Emails

Recipients often receive encrypted emails without expecting them. The reasons are usually straightforward.

A healthcare provider sending PHI encrypts to protect patient information under HIPAA. Test results, appointment details, and billing statements often arrive encrypted.

A financial services firm sending account details encrypts to protect against fraud and to meet GLBA requirements. Statements, tax documents, and account changes often arrive encrypted.

A legal counterparty sending privileged material encrypts to protect attorney-client privilege. Settlement documents, court filings, and case correspondence often arrive encrypted.

An employer sending HR content encrypts to protect employee records. Offer letters, tax forms, and performance reviews often arrive encrypted.

Legitimate encrypted messages come from known senders and route through recognizable vendors like Microsoft, Google, Mailhippo, Virtru, or Barracuda. Suspicious encrypted messages from unknown senders should be treated as potential phishing.

what are encrypted emails in article illustration two

Phishing Increasingly Mimics Encrypted Email Delivery

Phishing campaigns increasingly use fake encryption portals to harvest credentials. Recognizing the pattern reduces the risk of falling for one.

Fake encrypted email notifications typically arrive from unfamiliar senders and reference a document you did not expect. The link goes to a domain that looks similar to a real vendor but does not match.

The fake portal asks for the email password or a Microsoft account sign-in. Legitimate portals ask for a one-time passcode sent to your address or a sign-in with an existing account you recognize.

The CISA phishing guidance covers common patterns and what to do if you suspect a phishing attempt.

Best practice verifies the sender through a separate channel before clicking any encrypted email link from an unfamiliar source. A phone call to a known number is worth thirty seconds of caution.

Are Encrypted Emails Actually Safe

Encrypted emails are safer than unencrypted emails against interception and provider-side access. They do not defend against every threat.

Phishing attacks that steal mail credentials bypass encryption by giving the attacker legitimate access to the inbox. The attacker sees the plaintext through the same interface as the real user.

Malware on the sender or recipient device captures plaintext before encryption or after decryption. Keyloggers, screen scrapers, and clipboard monitors all bypass the encryption layer.

Weak recipient portal passwords make encryption meaningless. A message encrypted with AES-256 protected by a password of qwerty is not protected in any meaningful sense.

Real security posture layers encryption with multi-factor authentication, endpoint protection, phishing training, and incident response. Each layer covers threats the others miss.

[mh_protip]

Shared Mailboxes and Encrypted Messages

Shared mailboxes complicate encrypted email handling. The complications matter more for regulated content than for general business email.

S/MIME-encrypted messages in a shared mailbox require the mailbox owner or delegated user to have a matching certificate. If the certificate is tied to an individual account, other delegates cannot decrypt.

Portal-encrypted messages in a shared mailbox arrive as notification emails. Anyone with credentials to the portal can sign in and read the content. This model preserves recipient anonymity at the cost of audit clarity.

Best practice restricts encrypted PHI or sensitive content to named individual mailboxes rather than shared ones. The audit trail stays clean, and inadvertent access by delegated users does not happen.

Practices with shared inboxes for reception or billing should route PHI through a named clinical inbox and reserve the shared inbox for non-PHI communication.

Related Encrypted Email Reading

Encrypted emails cover multiple adjacent topics. The companion guides below add depth on specific questions.

Users trying to open a specific encrypted message can review how to open encrypted emails in Outlook and how to view encrypted emails. Both guides cover the recipient-side workflow across common vendors.

Senders configuring encrypted sending in Outlook benefit from encrypting emails in Outlook. The guide covers S/MIME setup and the ribbon controls.

Users comparing encryption providers can review ProtonMail encrypted email for a specific vendor deep-dive. ProtonMail illustrates a pure E2EE approach.

Broader coverage of whether standard email is encrypted at all lives in are emails encrypted. The guide covers the transport-only default across major providers.

Where Redefine Web Fits the Healthcare Email Stack

Encrypted email covers the message pipeline. Website contact forms, patient portals, and marketing platforms carry PHI that must reach the same encryption controls.

A contact form on the practice website that emails PHI to a generic Gmail address bypasses every encryption control the practice buys. The submission arrives unencrypted, and the audit trail does not exist.

Redefine Web builds HIPAA-aware healthcare websites and integrates the forms with encrypted delivery paths. Details on the healthcare marketing agency practice cover the surface area that sits alongside encrypted email.

A closed-loop review across website, forms, email, and portal reduces the risk that a PHI leak lands in an unencrypted channel by mistake.

Mailhippo fits senders that want encrypted email delivery with the BAA, audit logging, and simple recipient experience in one product. The service integrates with existing Gmail or Outlook accounts and keeps the recipient path to a single click for most messages, whether the recipient is on Gmail, Outlook, or another provider. Understanding what encrypted emails are makes the vendor conversation shorter and the buying decision more defensible.

[mh_faqs]

Posted on

Smarsh Email Encryption Explained for Compliance Teams

smarsh email encryption guide featured image

[mh_key_takeaways]

Smarsh email encryption is one part of a wider compliance platform rather than a standalone encryption product. Firms in financial services, healthcare, and insurance use it when they need encryption, archiving, and supervision under one contract.

This guide covers what Smarsh encryption actually does, how the platform is set up, and when a lighter encrypted email service covers the same compliance ground with less overhead. Comparing honestly matters because the fit varies with firm size and use case.

The audience for this article is a compliance officer, IT lead, or practice manager evaluating Smarsh against alternatives. The details focus on functional behavior rather than sales positioning.

What Smarsh email encryption actually is

Smarsh is a communications compliance company that acquired Actiance in 2017 and expanded through further acquisitions to become a broad archiving and supervision vendor. Email encryption sits inside the Smarsh Professional Archive and Enterprise Archive product families.

The encryption piece is not sold as a standalone product for most customers. Firms that buy Smarsh for encryption alone are rare. The typical purchase includes archiving, supervision, and encryption together to satisfy a regulatory obligation that spans all three.

Transport encryption uses TLS 1.2 or higher between mail servers. Message-level encryption uses a portal delivery model where the recipient reads the message inside a Smarsh-hosted web view after authenticating with a one-time passcode.

The architecture is designed for compliance-heavy environments where messages must be retained, searchable, and reviewable by a supervisor. Encryption alone does not require this depth of infrastructure, which explains the fit question for smaller firms.

Which regulations Smarsh encryption is designed to satisfy

The primary compliance drivers for Smarsh customers are FINRA Rule 3110, SEC Rule 17a-4, and HIPAA. Each of these regulations imposes obligations that extend beyond encryption itself.

  • FINRA Rule 3110 requires broker-dealers to supervise associated persons and review certain communications
  • SEC Rule 17a-4 requires certain records to be retained in a non-erasable, non-rewritable format for defined periods
  • HIPAA requires encryption of protected health information in transit and at rest, plus audit logging and access controls
  • State privacy laws such as CCPA add breach notification and data subject rights obligations on top of federal rules

A pure email encryption service covers HIPAA on its own. Adding supervision and non-rewritable archiving is what makes Smarsh a fit for a broker-dealer rather than a therapy practice.

Compliance officers evaluating Smarsh should map their specific regulatory obligations against the platform’s features rather than buying the full stack by default. A single-rule requirement rarely justifies the full stack.

smarsh email encryption in article illustration one

Smarsh email encryption setup end to end

Smarsh onboarding is not a self-service signup. A prospective customer talks to a sales engineer, scopes the deployment, and works with a Smarsh implementation team through provisioning.

The customer connects their email platform to Smarsh through mail flow rules on Exchange Online, Google Workspace, or on-premises Exchange. The connection routes outbound messages through Smarsh gateways for policy inspection.

Encryption policies are defined using keyword lists, sender groups, subject line patterns, or attachment content matching. A common example is triggering encryption on any outbound message containing an account number pattern or specific medical terminology.

Once policies are active, supervisors are configured for review queues, archive retention is set to match the regulation, and users are onboarded. A typical mid-sized firm rollout runs four to eight weeks. Microsoft’s own Exchange mail flow rule documentation is published in the Microsoft Exchange documentation.

Accessing a Smarsh encryption account as an end user

Two different login experiences exist. Firm employees log into a Smarsh admin portal to manage archives, run searches, or handle supervision queues. Message recipients log into a separate portal to read encrypted messages.

Firm users receive credentials from their internal compliance administrator during onboarding. Password resets and access changes are handled through the firm’s admin, not through Smarsh support directly. This model protects segregation of duties.

Message recipients receive an email notification with a secure link. Clicking the link opens a login prompt on the Smarsh portal domain. First-time recipients set a passcode. Return recipients enter the credentials they set previously.

Recipients who lose the passcode can request a reset from the same portal. The reset flow uses email verification back to the original recipient address, which is the standard model for portal-based encrypted delivery across most vendors.

[mh_example]

How Smarsh compares to lighter encrypted email services

The comparison matters most for practices that need encrypted email without the wider supervision and archiving stack. The tradeoffs are real, and neither option is universally better.

CapabilitySmarshDedicated encrypted email service
TLS transport encryptionYesYes
Portal-based message encryptionYesYes
FINRA-grade archiving and supervisionYes, core featureNot the primary use case
Business associate agreement for HIPAAYes, on requestYes, in base subscription
Typical onboarding timeFour to eight weeksSame day to one week
Fit for solo practice or two-person firmHeavy for the use caseWell-matched

A broker-dealer that must supervise communications across email, chat, and social media benefits from Smarsh as one contract covering all channels. A four-clinician therapy office that only needs encrypted email to patients does not.

The email encryption service category has matured to the point where dedicated products handle HIPAA well without archiving depth that a small practice will never use.

Smarsh email encryption reviews from compliance teams

Reviews from Smarsh customers cluster around a few consistent themes. The archiving and supervision are strong. The encryption is a supporting feature rather than a headline capability. Support quality depends on the tier.

Broker-dealers and registered investment advisers give positive reviews on the ability to search across email, chat, social, and voice channels from one interface. FINRA examiners are familiar with the platform, which reduces friction during exams.

Healthcare customers on the mid-market end of the range report solid HIPAA coverage. Smaller practices sometimes report that the platform’s breadth is more than they need for encrypted patient communication alone.

Onboarding time is the most common negative theme in reviews. A multi-week implementation is normal for a compliance platform of this scope, but it can be a surprise to teams expecting a faster start.

smarsh email encryption in article illustration two

Deliverability and spam concerns with portal-based encryption

Portal-based encryption sends the recipient a notification email with a link to a secure portal. This model is standard across Smarsh, Microsoft Purview Message Encryption, and most enterprise-grade encrypted email services.

The deliverability question is whether the notification lands in the recipient inbox. Aggressive spam filters on the recipient side occasionally flag portal notifications because the message is short, contains a login link, and comes from a domain the recipient may not recognize.

The fix is on the recipient side. A mail flow rule that allowlists the Smarsh notification domain resolves the flagging. Firms with a large recipient base sometimes publish a one-page guide for external counterparties explaining the setup.

Sender-side deliverability issues almost always trace back to DMARC, SPF, or DKIM misconfiguration on the customer’s own domain. The National Institute of Standards and Technology publishes email authentication guidance in NIST SP 800-177 Rev. 1.

Signing the business associate agreement for HIPAA coverage

Healthcare customers using Smarsh for HIPAA-covered communications need a signed business associate agreement in the compliance file. Smarsh signs BAAs with covered entities, but the process is not automatic on sign-up.

The BAA is requested through the Smarsh account team during onboarding. The signed document is returned to the customer for records retention. HIPAA does not accept a BAA that is only stored on the vendor’s side.

The HHS Office for Civil Rights publishes a sample BAA at HHS.gov sample BAA provisions. Vendors typically use their own template that covers the required clauses.

The BAA is the legal piece. The technical piece is configuring mail flow rules that force encryption on any outbound message containing protected health information. Both pieces are required for HIPAA coverage, not just one.

[mh_protip]

Integrating Smarsh with Microsoft 365 and Google Workspace

Most Smarsh customers run either Microsoft 365 or Google Workspace as their primary mail platform. Both platforms integrate with Smarsh through mail flow connectors and journal rules.

On Microsoft 365, the connector routes outbound messages through Smarsh for policy inspection, and a journal rule copies messages to the Smarsh archive for retention. The Exchange admin center handles the connector configuration.

On Google Workspace, the routing setup uses content compliance rules and an outbound gateway configuration. Google publishes admin guidance in the Google Workspace admin help center.

Configuration errors during the connector setup are the most common source of incident tickets during onboarding. Testing the flow with a small pilot group before rolling out firm-wide catches most issues before they affect production traffic.

When a firm should look at alternatives to Smarsh

Alternatives to Smarsh fall into two groups. Full compliance platforms compete with Smarsh directly for broker-dealer and hospital-scale customers. Dedicated encrypted email services target smaller practices where archiving and supervision are not the primary need.

  • Solo therapy practices, two-person insurance offices, and small clinics rarely need Smarsh-level archiving depth
  • Broker-dealers, registered investment advisers, and hospital systems usually do need it and stay with a platform like Smarsh
  • Firms that only need encrypted patient email save time and cost with a dedicated secure email service that ships the BAA in the base plan
  • Firms that need full-stack supervision across email, chat, social, and voice cannot replicate that with a dedicated encryption service

The decision is not about which platform is better in the abstract. It is about which platform matches the regulatory footprint of the specific firm.

Compliance officers who inherit a Smarsh contract at a smaller organization should review whether the full stack is still needed. Compliance officers at growing firms should confirm the current encryption service will scale to the archiving and supervision requirements the firm is heading toward.

Practical next steps for a compliance officer evaluating Smarsh

Start with the regulatory map. List every rule the firm must satisfy and mark which of them require encryption, archiving, supervision, or all three. This grid drives the platform choice.

Request a scoped Smarsh quote alongside a quote from at least one dedicated encrypted email service. Comparing pricing at the same feature scope is more useful than comparing full-stack Smarsh against encryption-only alternatives.

Run a small pilot before committing. A two-week test with a handful of users on real message flows reveals deliverability, portal experience, and administrator workflow issues that a demo cannot surface.

For healthcare organizations building a website that will collect protected health information alongside encrypted email, the HIPAA-compliant website design considerations pair naturally with the email compliance decision. Both belong on the same risk register.

[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