HorizLogoSm.fw_.png
Start Trial

Tag: email encryption

Posted on

What It Means to Encrypt an Email in Plain Terms

what does it mean to encrypt an email guide featured image

[mh_key_takeaways]

To encrypt an email is to convert the message body and attachments into ciphertext before sending. The mail servers in between see only scrambled data. Only a recipient with the correct key or credential can read the content.

This guide explains what encryption means in practical terms, how an encrypted email looks to sender and recipient, and when a dedicated encrypted email service fits better than the built-in options in Outlook or Gmail.

The details vary by platform. The underlying protection is the same. Content is unreadable to anyone without the correct decryption key or authentication credential.

Encryption Converts Message Content Into Ciphertext

Encryption applies a mathematical algorithm to the message body and attachments. The algorithm uses a key to scramble the content into ciphertext. Only a matching key or credential can reverse the process and produce readable content.

The sender does not see the ciphertext. The compose window looks the same as a normal message. The encryption applies at send time, either automatically based on a policy or manually by clicking an Encrypt option.

The recipient does not see the ciphertext either. The mail client or portal decrypts before display. What both parties see is a normal-looking message with a lock icon or policy label that confirms encryption was applied.

The ciphertext exists on the wire between servers and at rest on the sending platform. Anyone who intercepts the traffic or gains access to the storage sees only scrambled data.

Three Layers of Encryption Cover Different Threats

Email encryption applies at three possible layers. Transport encryption between mail servers uses TLS. Message-level encryption uses S/MIME or PGP. Portal-based encryption stores encrypted messages on a server and delivers a link to the recipient.

TLS protects the message during network transmission. It does not protect the message at rest on the sending or receiving mail server. TLS is the baseline, not the full solution for regulated content.

Message-level encryption protects the content from the sender client to the recipient client. Servers in between see ciphertext. This is true end-to-end encryption and it fits scenarios where both parties can hold cryptographic keys.

Portal-based encryption sits between the two. The sending platform holds the encrypted content and manages authentication. The recipient reads the message in a browser session after signing in or entering a one-time passcode.

what does it mean to encrypt an email in article illustration one

The Sender View Looks Almost Identical to Regular Mail

The sender view of an encrypted email is nearly the same as a normal email. The compose window uses the same fields, the same formatting, and the same attachment controls. The one difference is a lock icon or a policy label on the message.

In Outlook, the sender clicks Options, then Encrypt, and picks a policy. In Gmail on Workspace with client-side encryption, the sender clicks a lock icon in the compose bar. In a HIPAA email service, the sender either clicks a Send Secure button or the encryption applies automatically to every outbound message.

The Send button behaves the same way. The message enters the outbound queue. The encryption applies before or during the send. The sender does not see any technical change.

The Sent folder shows the encrypted message under its subject line, the same as any other sent message. The sender can preview the content because the sender is a party to the encryption.

The Recipient View Depends on Platform and Method

The recipient view varies. Internal recipients on the same mail platform typically see the message inline. External recipients on other platforms follow a different path depending on the encryption method.

A Purview-encrypted message to a Gmail recipient arrives as a notification email with a Read the message button. The button opens outlook.office365.com in a browser. The recipient signs in with a Microsoft or Google account or requests a one-time passcode.

An S/MIME message decrypts inside the recipient mail client if the client has the correct certificate. Otherwise the recipient sees an unreadable attachment. This is why S/MIME works well for internal or business partner scenarios and poorly for patient communication.

A HIPAA email service typically shows the recipient a branded notification with a Read Message button. The button opens a portal where the recipient reads the decrypted content. Some services deliver the message directly to the recipient inbox if the recipient is on a compatible platform.

[mh_example]

Unencrypted Email Exposes Content to Anyone on the Path

An unencrypted email travels as plain text or under opportunistic TLS only. Opportunistic TLS drops back to cleartext if the receiving server does not support TLS. Any mail relay along the path can read the content.

The mail servers at each end store the message in cleartext. A breach of a mail server exposes the content of every stored message. Backups of mail servers also carry the cleartext content.

For casual content this is often acceptable. Personal mail, meeting confirmations, and general business correspondence typically travel unencrypted. The exposure risk is low relative to the content sensitivity.

For regulated content, the exposure changes the calculus. PHI, financial records, legal work product, and trade secrets in unencrypted mail create compliance exposure under HIPAA, GLBA, HITECH, and similar frameworks. The HHS Security Rule treats encryption as an addressable specification for transmission and at-rest storage.

Encryption Methods Compared at a Glance

The four common methods differ in setup complexity, recipient experience, and threat coverage. The table below summarizes the trade-offs.

Method Setup Complexity Recipient Experience Fits Best For
TLS Low, on by default No change Baseline transit protection
S/MIME High, needs certificates Automatic in-client decrypt Internal and B2B mail
Microsoft Purview Medium, needs license Portal sign-in or passcode Outlook tenants on Business Premium
HIPAA Email Service Low, gateway configured One-click portal Patient and PHI communication

The right choice depends on the recipient environment, the license already in place, and the compliance requirements. Practices sending to patients almost always want the one-click portal experience because patient tech literacy varies.

what does it mean to encrypt an email in article illustration two

Encrypting an Email in Outlook Uses Microsoft Purview

In Outlook on Microsoft 365 Business Premium and higher, encrypting an email means clicking Options, then Encrypt, in the compose ribbon of a new message. Two policies are available: Encrypt-Only and Do Not Forward.

Encrypt-Only encrypts the content and lets the recipient reply, forward, and print. Do Not Forward encrypts the content and blocks forward, print, and download. The sender picks the policy at send time.

Microsoft Purview handles the delivery. Internal Microsoft 365 recipients see the message inline. External recipients receive a notification with a Read the message button that opens a browser portal for decryption.

The detailed sender steps are in the Microsoft support guide for encrypted messages in Outlook. Tenants on Business Basic or Business Standard do not have the button and need a license upgrade or a separate service.

Encrypting an Email in Gmail Depends on Workspace Plan

Gmail encryption depends on the Workspace plan. Enterprise Plus and Education Plus support client-side encryption. Other plans support confidential mode, which is not the same thing.

Client-side encryption encrypts the message content in the browser before it reaches Google servers. The keys stay with the customer through an external key service. Google cannot decrypt the message.

Confidential mode sets an expiration and disables forward, copy, print, and download. It does not encrypt the message body in a way that meets HIPAA transmission requirements. Google can still access the content.

Standard Workspace plans that need encryption for HIPAA use a HIPAA email service that routes outbound mail through a gateway. The Gmail interface stays the same. Encryption applies at the service layer.

[mh_protip]

Encryption Is One Layer of HIPAA Compliance

Sending an encrypted email is not the same as being HIPAA-compliant. The Security Rule requires administrative, physical, and technical safeguards. Encryption covers part of the technical safeguards.

The covered entity also needs a signed business associate agreement with the email provider, access logs on message activity, workforce training on when to encrypt, and a documented incident response plan.

Common gaps in the compliance picture include:

  • Sending encrypted mail without a signed BAA in place with the provider.
  • Encrypting outbound mail but leaving stored copies unencrypted at rest.
  • Missing workforce training that leaves staff unsure of when to encrypt.
  • No incident response plan for a mail account compromise scenario.
  • No access logs on message activity for audit review.

Each of these gaps is a real audit finding, not a theoretical concern. Practices building out the wider security posture around encrypted mail also need to cover the website, patient portal, and intake forms. See the guide on healthcare website security features for the site-side controls that pair with encrypted email.

When a HIPAA Email Service Simplifies the Encryption Decision

A dedicated HIPAA email service handles the encryption, the BAA, the access logs, and the recipient portal in a single plan. The sender writes mail in a familiar Gmail or Outlook interface. Outbound mail routes through the service gateway.

Mailhippo is one option in this category. It works with existing Gmail and Outlook accounts. The BAA is included in the base plan. Encryption applies to every outbound message. Recipients open messages with one click and no account creation.

The secure email service approach fits practices that need HIPAA compliance without adding license overhead or IT complexity. The trade-off is a routing dependency on the service.

Related reading covers what encrypted mail actually looks like and how it behaves in specific tools: what does encrypt an email mean, what does encrypting an email do, what happens when you encrypt an email outlook, what is an encrypted email mean, what does an encrypted email look like, and encrypt an email.

The Practical Decision Comes Down to Three Questions

The practical decision on how to encrypt an email comes down to three questions. Who is the recipient. What license is already in place. What compliance framework applies.

If the recipient is another employee or a business partner with technical staff, S/MIME or Purview inline delivery works well. If the recipient is a patient or a member of the public, a portal experience with one-click access is the realistic path.

If the license is Microsoft 365 Business Premium or higher, Purview is the built-in option. If the license is a lower Business plan or a Workspace plan without Enterprise Plus, a HIPAA email service fills the gap without an upgrade.

If HIPAA applies, the choice must include a BAA with the provider handling encryption. A dedicated HIPAA email service handles the BAA by default. The wider healthcare digital footprint, including site and portal, can be coordinated by a healthcare marketing agency that pairs the compliance stack with the marketing stack.

[mh_faqs]

Posted on

Outlook 365 Encrypt Email Setup and Sending Guide

outlook 365 encrypt email guide featured image

[mh_key_takeaways]

Outlook 365 encrypt email works through Microsoft Purview Message Encryption, a service built into Business Premium and Enterprise plans. Clicking the Encrypt button in the Options ribbon triggers the flow, and the recipient reads the message inline or through a branded portal.

This guide walks through desktop, web, and mobile steps, the two default encryption templates, mail flow rule automation, and HIPAA fit. Practices that need a simpler option can layer a dedicated encrypted email service on top of the existing Outlook account.

Every step below reflects the Microsoft 365 admin experience as of 2026. Feature names shift year to year, so cross-check the Microsoft learn documentation before a large rollout.

Licensing decides whether the Encrypt button appears

The Encrypt button appears in Outlook only when the mailbox license includes Purview Message Encryption. Business Premium, E3, E5, and equivalent education, nonprofit, and government plans include it by default.

Business Standard, Business Basic, E1, and Apps-only plans do not include it. Users on those plans see no Encrypt option in the Options ribbon, and the compose window offers no sensitivity label picker.

Two paths fix the gap. Upgrade specific seats to Business Premium, or add the Microsoft 365 E5 Compliance license per user. Both carry a monthly cost that scales with headcount.

A third path skips the Microsoft licensing question entirely by routing sensitive mail through a dedicated service that owns the encryption layer. That approach fits smaller practices that resist the per-seat cost of Business Premium.

The Encrypt button in Outlook desktop lives inside the Options ribbon

Open a new message in Outlook for Windows or Mac. Click the Options tab at the top of the compose window. Look for the Encrypt button in the Permission group next to the sensitivity label picker.

Click Encrypt, then pick Encrypt-Only or Do Not Forward from the dropdown. A blue banner appears above the recipient field confirming the message is encrypted.

The dropdown may show additional custom templates if the tenant administrator created them. Common examples include Confidential, Highly Confidential, or a template branded with the practice name.

Attachments follow the same encryption policy as the message body. Office files stay protected after download for recipients who use Microsoft 365, and PDFs open through the portal viewer.

outlook 365 encrypt email in article illustration one

Outlook on the web uses a different menu path

The web app hides the Encrypt option under the three-dot menu at the top of the compose window. Click the three dots, hover on Encrypt, and pick a template.

The Encrypt icon shows a lock next to the recipient field once the setting applies. Removing the encryption before send requires clicking Change permissions and picking No Restriction.

Outlook on the web does not support switching from Encrypt-Only to Do Not Forward after the setting is applied without recomposing. Pick the template first, then finish the message body.

The web experience matches the desktop flow for external recipients. The link and portal path stay identical regardless of which Outlook client sent the message.

Mobile Outlook supports encryption on both iOS and Android

Open the Outlook mobile app and start a new message. Tap the arrow icon at the top right of the compose window to expand the options. Tap Encrypt and pick a template.

The mobile flow requires Outlook version 4.2338 or later on iOS and 4.2337 or later on Android. Older builds show the Encrypt option grayed out even on Business Premium tenants.

Attachments compose the same way as on desktop. Files pulled from OneDrive or SharePoint apply their existing sensitivity labels, and files uploaded from the device follow the message-level template.

Reading an encrypted message on mobile works inline for internal recipients. External recipients tap the Read the message button, which opens the browser to the Office 365 Message Encryption portal.

[mh_example]

Encrypt-Only and Do Not Forward templates behave differently

Encrypt-Only encrypts the message body and attachments during transit and at rest. The recipient reads, replies, forwards, prints, and copies content without restriction. This template fits routine sensitive mail like invoices or draft contracts.

Do Not Forward encrypts the same content and adds usage rights. The recipient reads and replies, but the client blocks Forward, Copy, and Print actions. The portal viewer hides the download button.

Neither template can be changed after the message is sent. Recall works only for internal Microsoft 365 recipients, so external messages stay in the recipient inbox until the mailbox owner deletes them.

Custom templates built in the Microsoft 365 admin center support intermediate policies. A template can allow reply but block forward, or allow reply-all but block print. Setup takes 10 minutes in the Purview compliance portal.

Mail flow rules automate encryption for sensitive messages

Automatic encryption removes the burden from staff who forget to click Encrypt. Open the Exchange admin center, go to Mail flow, then Rules, and click Add rule.

Set the condition to match a keyword in the subject or body. Common patterns include patient ID, DOB, MRN, SSN, and the word confidential. Regex matching handles credit card and Social Security number patterns.

Add the action Apply Office 365 Message Encryption and rights protection. Pick Encrypt or Do Not Forward from the dropdown. Save the rule in preview mode first.

Review the message tracking log after a week. False matches on routine internal replies signal that the keyword list is too broad. Refine the list, then flip the rule to enforced mode.

outlook 365 encrypt email in article illustration two

External recipient experience depends on the recipient mail provider

Microsoft 365 and Outlook.com recipients read the message inline without a portal step. The reading pane shows the encrypted content, and Reply works normally.

Gmail recipients see a preview and click Read the message to open the Office 365 Message Encryption viewer. Signing in with a Google account skips the passcode step.

Every other provider, including Yahoo, AOL, and consumer ISP addresses, hits the branded portal and requests a one-time passcode. The code arrives at the same email address within seconds and stays valid for 15 minutes.

Branding the portal with practice logo, header text, and disclaimer content builds trust with first-time recipients. Setup takes two minutes under Microsoft 365 admin center, Settings, Org settings, Organization profile.

HIPAA compliance requires more than the Encrypt button

Purview Message Encryption meets the HIPAA Security Rule technical safeguard for encryption in transit and at rest. That single control is necessary but not sufficient for a compliant email workflow.

The covered entity must sign the Microsoft Business Associate Agreement through the Service Trust Portal. The BAA covers Microsoft 365, Azure, and Dynamics 365 at no extra cost.

Workforce training documents that staff know when to click Encrypt and how to explain the portal to a patient. The Security Rule administrative safeguards require annual training records.

Practices building a broader patient communication stack should also review the healthcare website security features that intake forms and patient portals should meet.

[mh_protip]

Related Microsoft encryption paths cover different scenarios

Purview Message Encryption is the modern default for outbound message encryption. Older tenants may still see references to Azure Information Protection, which is now merged into Purview.

S/MIME remains available for tenants that manage certificates and want end-to-end encryption where Microsoft servers cannot decrypt content. Setup takes hours per user and fits regulated industries that require certificate control.

The broader encrypt 365 email workflow spans licensing, sensitivity labels, mail flow rules, and DLP policies. Practices with a compliance officer often build the full stack, and small offices pick the two or three features that fit daily use.

For a step-by-step tour of the classic Encrypt button experience, the how to encrypt email in outlook 365 guide walks through the same flow with additional screenshots and troubleshooting tips.

Alternatives fit practices without Business Premium licensing

Practices on Business Standard or Business Basic face a real cost decision. Upgrading every seat to Business Premium runs about $22 per user per month, which adds up quickly for a 20-person practice.

The Microsoft 365 E5 Compliance add-on costs less per seat but still requires an existing Business or Enterprise base license. Both paths keep encryption inside the Microsoft ecosystem.

Dedicated encrypted email services layer on top of any Outlook or Gmail account with no licensing changes. A HIPAA-compliant secure email service like Mailhippo includes a BAA in the base plan and adds no portal step for common recipient providers.

The decision comes down to team size, existing licensing, and how often mail flows to Gmail and non-Microsoft recipients. Larger tenants with Business Premium already in place stay with Outlook encryption, and smaller offices often pick a dedicated service for simpler daily use.

Common pitfalls slow down early rollouts

The most common early problem is missing licensing. A staff member sees no Encrypt button, tickets IT, and IT confirms the seat is on Business Standard. Audit licensing before training rollout.

The second most common problem is recipient confusion during the first message. The portal step surprises patients and referring providers who expect inline mail. A short cover message explaining what to expect cuts support calls.

Mail flow rules that match too broadly encrypt normal internal replies. Staff read the encrypted format as a signal that something is confidential, which trains them to distrust routine mail. Refine keywords in preview mode.

Attachment size limits still apply. Purview encryption does not raise the 150 MB Exchange Online message ceiling. Large radiology or imaging files still need a separate transfer path with a signed BAA.

  • Confirm Business Premium, E3, E5, or E5 Compliance licensing on every seat that sends encrypted mail.
  • Brand the recipient portal with practice logo, header text, and support contact before the first external send.
  • Default clinical staff to Do Not Forward and administrative staff to Encrypt-Only, then adjust based on real use.
  • Test mail flow rules in preview mode for a full week before enforcing them tenant-wide.
  • Document workforce training records annually to meet the HIPAA Security Rule administrative safeguards.

The Outlook 365 encrypt email flow is production-ready for practices on the right licensing tier. Practices outside that tier have three real options, and the right pick depends on team size, mail volume, and how often sensitive messages cross into Gmail and consumer inboxes.

[mh_faqs]

Posted on

Barracuda Email Encryption Service Review for 2026

barracuda email encryption service guide featured image

[mh_key_takeaways]

Barracuda Email Encryption Service is one of the older cloud-based email encryption products in the market. Barracuda Networks launched the service in 2003 and has iterated the recipient portal, admin console, and pricing model steadily since then.

The service targets mid-market organizations that want encryption bundled with spam filtering and Advanced Threat Protection. Healthcare practices adopt Barracuda when they already run Microsoft 365 or Google Workspace and want an enterprise gateway that signs a BAA. Buyers evaluating a secure email encryption service often compare Barracuda against Cisco, Proofpoint, and lower-friction alternatives.

This review walks through what the service actually delivers, how the pricing tiers stack up, and where the recipient portal step becomes a workflow bottleneck.

What is Barracuda Email Encryption Service

Barracuda Email Encryption Service is a cloud-based encryption gateway. Messages that match a policy trigger route through Barracuda cloud servers before delivery to the recipient.

The service supports three trigger types. Subject line keywords like [encrypt] applied by the sender. Content policies that scan the message body for regulated patterns like credit card numbers or Social Security numbers. Sensitivity labels applied by a Purview or Google Workspace policy.

Barracuda encrypts triggered messages at rest with AES-256. Recipients get a notification email with a portal link. First-time recipients register an account. Returning recipients log in with the existing password.

The service integrates with Microsoft 365 and Google Workspace through connector configuration. The barracuda encrypted email guide walks through the connector setup on both platforms.

barracuda email encryption service in article illustration one

Barracuda Email Encryption Service cost breakdown

Barracuda sells encryption inside Email Protection bundles. Standalone encryption pricing is not published anymore because the modern purchase path always includes the broader spam and malware filtering stack.

The bundle tiers below reflect list pricing at the time of writing. Actual pricing from a Barracuda partner is often 10 to 20 percent below list, and multi-year commitments drop pricing further.

Barracuda tier Price per user per month Encryption included Best fit
Email Protection Essentials $4 Yes Basic spam and encryption
Email Protection Advanced $6 Yes plus link protection Small business phishing defense
Email Protection Premium $10 Yes plus ATP sandboxing Mid-market compliance
Total Email Protection $12 Yes plus backup and archiving Regulated industries with retention

Nonprofit and education customers get 20 to 40 percent below list on all four tiers. Confirm the current price with a Barracuda partner because published pricing shifts quarterly.

Barracuda Email Encryption Service login and portal experience

Recipients of a Barracuda-encrypted message get a notification email with a portal link. The notification email includes the sender name, subject line, and a call-to-action button that opens the portal.

First-time recipients click the button, land on the Barracuda portal, and register an account with an email address and a password. The registration step takes about 60 seconds if the recipient reads the on-screen instructions.

Returning recipients see the login page instead of the registration page. Login with the existing password unlocks every previous message from the same sender organization.

Password reset uses the standard email link flow. Recipients who forget the password click Reset, receive a new email, and set a new password. The reset flow works but adds another 90 seconds to the average message open time.

[mh_example]

Barracuda Email Encryption Service uptime and outage handling

Barracuda publishes a 99.999 percent SLA on Email Protection. In practice the service hits close to that number, with occasional short outages affecting the encryption or portal layer.

When users search for barracuda email encryption service down, they most often hit an outage that clears within an hour. Check status.barracuda.com for the current service state. Barracuda posts incident summaries after resolution.

Outbound messages queued for encryption pause during the outage. Depending on the connector configuration, messages either sit in the sender mail queue or route through a fallback path that skips encryption.

The fallback that skips encryption creates HIPAA exposure. Configure the connector to block delivery rather than skip encryption when the service is down. Document the outage protocol in the risk analysis.

barracuda email encryption service in article illustration two

Barracuda Email Encryption Service phishing and spam handling

Barracuda combines encryption with the broader Email Protection spam filtering stack. Inbound mail routes through Barracuda spam and malware filters before delivery to the mailbox.

Outbound mail routes through the encryption engine when the sender or a content policy triggers encryption. The two functions share the same admin console and message log. Configure the spam threshold in the admin console under Email Protection, Anti-Spam.

Attackers sometimes clone the Barracuda notification email template to send phishing messages that look like real encrypted mail. The cloned message points to a fake portal that steals credentials.

Train recipients to hover over the portal link and confirm the domain is barracudanetworks.com before entering credentials. Reference the CISA phishing advisories for the current threat patterns.

Barracuda Email Encryption Service legitimacy verification

Barracuda Networks is a publicly traded email security vendor headquartered in Campbell, California. The company has sold email encryption products since 2003.

Legitimate portal notifications come from a barracudanetworks.com domain. The portal itself lives at the same domain. Verify legitimacy by hovering over the link before clicking.

Barracuda publishes trust and compliance documentation at trust.barracuda.com. The documentation includes SOC 2 reports, HIPAA business associate agreement details, and the current security whitepaper.

Healthcare practices adopting the service should download the SOC 2 report and the HIPAA whitepaper as part of the vendor due diligence process. Store both documents in the compliance evidence folder.

[mh_protip]

Barracuda Email Encryption Service agentless variant

Barracuda offers an agentless email encryption variant that skips the client-side integration entirely. All encryption happens in the cloud gateway, so users do not install any extension in Outlook or Chrome.

The agentless model works well for organizations with many different mail clients and mobile users. There is nothing to install on iPhones, iPads, personal laptops, or bring-your-own devices.

The tradeoff is the sender loses the button-click encrypt option in Outlook. Encryption triggers only on subject line keywords or content policy matches. Senders who need explicit control per message add [encrypt] to the subject line.

See barracuda agentless email encryption for the full configuration walkthrough and connector setup. The agentless variant works with both Microsoft 365 and Google Workspace tenants.

Barracuda compared with Cisco and general email encryption alternatives

Barracuda competes head-to-head with Cisco Secure Email in the mid-market. Both use a portal-based delivery model, both bundle encryption with spam filtering, and both sign a BAA on healthcare accounts.

Cisco pricing runs higher per seat but includes deeper phishing analytics and stronger URL rewriting. Barracuda pricing runs lower per seat but relies more on the customer to train recipients on the portal flow. See secure email encryption service cisco for a detailed feature comparison.

Buyers looking at general email encryption service options should evaluate at least three vendors before signing. The email encryption service barracuda comparison guide covers Barracuda against Proofpoint and native Microsoft 365 encryption.

Key evaluation criteria:

  • Recipient portal experience and first-time registration friction
  • BAA inclusion in the base plan or as an add-on
  • Fallback behavior during a service outage
  • Admin console usability and message log depth
  • Nonprofit or education pricing availability
  • Multi-year commitment discount schedule

Barracuda Email Encryption Service fit for healthcare practices

Barracuda works well for mid-size healthcare practices with 50 to 500 seats. The bundle price at $10 to $12 per user per month competes with Cisco and Proofpoint, and the admin console handles most day-to-day operations without vendor support.

Small practices under 20 seats often find the bundle price too high for the volume of encrypted messages. A dedicated encryption service like Mailhippo priced per seat at the entry tier fits the small-practice case better.

Practices that also run a patient-facing website need matching safeguards on both channels. HIPAA compliant website design handles the web side while Barracuda or an alternative handles the mail side. See security features for healthcare websites for the aligned web guidance.

Recipient friction remains the primary reason practices switch away from Barracuda. If your patient population struggles with the portal step, evaluate a zero-step alternative before renewing. Mailhippo delivers encrypted messages directly to the recipient normal inbox, removing the portal registration and login entirely. Reference HIPAA Journal on compliant email and NIST SP 800-177 Trustworthy Email for the standards behind these decisions. See email encryption for the broader context.

[mh_faqs]

Posted on

How Do You Encrypt Emails in Outlook, Gmail, and Office 365

how do you encrypt emails guide featured image

[mh_key_takeaways]

Email encryption is not one process. It is a family of methods that apply differently depending on the sender client, the recipient client, and the license tier on both sides. The right method for a given message is the one that lands in a form the recipient can actually read.

This article walks through the three main encryption methods in production use today. Transport-layer TLS, client-level S/MIME, and portal-based encryption through services like Microsoft Purview or a HIPAA-compliant encrypted email service. Each has a role, and the trade-offs matter for healthcare senders in particular.

The three encryption methods you actually have

Every email encryption solution in production use is a variation on one of three methods. Transport Layer Security, client-side S/MIME or PGP, and portal-based encryption through a secure gateway.

Transport Layer Security encrypts the connection between two mail servers. When both servers support TLS 1.2 or higher and negotiate a session, the message content travels encrypted between them. TLS is invisible to the sender and recipient. It does not require any action to enable and does not require any client-side setup.

Client-side encryption using S/MIME or PGP encrypts the message body itself with a key that only the recipient can decrypt. The encrypted content is safe even if the mail server storing it is breached. S/MIME requires certificates on both sender and recipient devices. PGP requires key pairs.

Portal-based encryption uploads the message content to a secure gateway. The recipient receives a notification with a link to authenticate and view the content in a browser. This method removes the need for the recipient to have any specific client or certificate. It is the standard approach for external communications where the sender cannot control what the recipient uses.

how do you encrypt emails in article illustration one

How to encrypt an email in Outlook desktop

Outlook desktop on Microsoft 365 Business Premium and Enterprise E3 or higher includes the Encrypt button in the Options ribbon of a new message. Clicking it applies Microsoft Purview Message Encryption using the sender tenant as the authentication backend.

The steps in Outlook desktop:

  • Compose a new message and address it to the recipient
  • Click the Options tab in the ribbon
  • Click Encrypt in the Permission group
  • Choose Encrypt-Only, Do Not Forward, or a custom policy from the dropdown
  • Complete the message body and click Send

The recipient sees a notification with a Read the Message button. Clicking the button opens a browser session, prompts for sign-in with Microsoft, Google, or a one-time passcode, and displays the decrypted content on the Microsoft encryption portal.

Outlook desktop also supports S/MIME encryption for messages between recipients who have exchanged certificates in advance. The Sign and Encrypt buttons in the Message ribbon apply S/MIME. Certificate management is more complex than portal-based encryption and is typically used only for internal messages between employees on the same tenant.

How to encrypt an email in Outlook on the web

Outlook on the web at outlook.office.com supports the same Purview Message Encryption as the desktop client. The interface is different, but the underlying mechanism is identical.

The steps in Outlook on the web:

  • Compose a new message
  • Click the three-dot More menu at the top of the compose window
  • Select Encrypt from the menu
  • Choose the encryption level and any restrictions
  • Send the message normally

The recipient experience is identical to messages encrypted from the desktop client. The tenant license and Azure Rights Management configuration are the same underlying requirement.

Outlook on the web does not support S/MIME on all account types. Consumer Outlook.com accounts have no S/MIME. Enterprise accounts support S/MIME through a browser extension that must be installed separately. For most healthcare senders, portal-based encryption through Purview is the practical choice regardless of client.

[mh_example]

How to encrypt an email in Office 365 through the admin side

Office 365 administrators can configure mail flow rules that automatically encrypt outbound messages matching specific criteria. This removes the requirement for the sender to click Encrypt on each individual message.

Common auto-encryption triggers:

  • Subject line contains a keyword like Secure or Encrypt
  • Recipient domain matches a specified partner list
  • DLP scanner detects PHI patterns in the message body or attachments
  • Sender is a member of a specified group like clinical staff
  • Attachment contains a specific document classification tag

The rule is configured in the Exchange admin center under Mail flow, Rules. The action is Apply Office 365 Message Encryption and rights protection with a chosen template. Testing the rule in audit mode before enforcing it prevents unexpected encryption of messages that should have gone in plaintext.

The Microsoft Purview Message Encryption documentation is the canonical reference for rule syntax and configuration options.

how do you encrypt emails in article illustration two

How to encrypt an email in Gmail

Gmail encryption depends on the tier. Consumer Gmail at gmail.com uses TLS in transit for all outbound mail but does not support end-to-end encryption directly. Google Workspace Enterprise Plus and Education Plus support client-side S/MIME.

For Enterprise Plus S/MIME:

  • Ensure S/MIME is enabled at the admin console under Apps, Gmail, User Settings
  • Upload S/MIME certificates for users through the admin console or self-service
  • Compose a new message and address it to a recipient whose certificate is on file
  • Click the lock icon in the compose window to see the encryption status
  • Choose Enhanced Encryption from the options
  • Send the message normally

Business Starter, Standard, and Plus tiers do not include S/MIME support. Practices on those tiers that need to send encrypted PHI typically add a HIPAA email service on top of Gmail. Google Workspace signs a Business Associate Agreement on Business Starter and higher, but the BAA alone does not provide the encryption. Sibling coverage of the Gmail-specific workflow is available at how to send encrypted email Gmail.

Confidential Mode is not encryption. It is a Google-specific feature that adds expiration dates and forwarding restrictions to messages, but the message content itself is not encrypted end to end. HHS has not endorsed Confidential Mode as satisfying HIPAA transmission security requirements.

How to encrypt an email on iPhone Mail

Apple Mail on iPhone supports S/MIME encryption once a personal certificate is installed as a configuration profile. Portal-based encryption from Purview or a HIPAA email service works with no iPhone-specific setup.

For S/MIME on iPhone:

  • Email the .p12 certificate file to yourself or obtain it through your organization MDM
  • Install the profile through Settings, General, VPN and Device Management
  • Enter the certificate password when prompted
  • Open Settings, Mail, Accounts, select the account, Advanced
  • Enable S/MIME and select the installed certificate under Sign and Encrypt by Default

Once configured, Apple Mail shows a lock icon on any composition to a recipient whose certificate is on file. The lock indicates encryption is active. Tap the icon to see certificate details or to disable encryption for a specific message.

For portal-based encryption, no iPhone-specific setup is required. The sender initiates encryption at the desktop or in the Outlook mobile app, and the recipient receives the standard notification that works on iPhone as on any other device.

[mh_protip]

Choosing between S/MIME, TLS, and portal encryption

The choice depends on the recipient. Internal messages between employees on the same tenant benefit from S/MIME or tenant-native encryption because certificates are managed centrally and no external portal is needed. External messages to business partners on Microsoft 365 or Google Workspace can use enforced TLS if the receiving domain is known and configured.

External messages to consumer email addresses require portal-based encryption. Patients on gmail.com, yahoo.com, aol.com, and icloud.com will not install S/MIME certificates, and enforced TLS to those providers is not fully reliable across all message paths.

The HHS Security Rule guidance and the NIST SP 800-45 email security guidelines provide the compliance framework for evaluating any specific configuration.

When native encryption is not enough for healthcare

Native encryption in Outlook, Gmail, and iPhone Mail works well for many use cases but leaves gaps for regular PHI transmission. Purview Message Encryption requires a Business Premium or Enterprise license, which is more expensive than most small practices need. Gmail S/MIME requires Enterprise Plus, which is not economical at practice scale. iPhone S/MIME requires certificate management the practice has to run for every clinician.

A dedicated HIPAA email service consolidates the encryption, BAA, audit logging, and archiving into one product that works with the existing Gmail or Outlook mailbox. A HIPAA-compliant secure email service that includes the BAA in the base plan removes the license-tier problem and the certificate-management problem at once. This mention concludes the product context for this article.

Recipient experience is the deciding factor in most healthcare deployments. A patient who cannot easily open the message will call the practice for help, and staff time on password resets and portal walkthroughs adds up. Portal-based encryption with federated sign-in through Microsoft, Google, or a one-time passcode is the pattern that produces the fewest support tickets. Sibling coverage on how do you open an encrypted email in Outlook covers the recipient side.

Related healthcare marketing coverage is available at Redefine Web healthcare website security features and at the healthcare marketing hub for practices coordinating email compliance with website and patient acquisition.

[mh_faqs]

Posted on

HIPAA Compliant Email in Gmail (What Actually Qualifies)

hipaa compliant email gmail guide featured image

[mh_key_takeaways]

Gmail dominates business email, and it dominates small healthcare practice email too. The question is where the line sits between everyday Gmail and HIPAA compliant email Gmail.

The short answer is that personal gmail.com accounts cannot be made compliant. Google Workspace on a paid plan can, with the right configuration and a signed business associate agreement. For senders who want a simpler path, a HIPAA-compliant email service layered over Gmail handles the encryption and the BAA in one step.

This guide walks through the license tiers, the covered services, the encryption options, and the practical setup steps for practices that want to keep Gmail as their day-to-day inbox while meeting the Security Rule.

Personal Gmail cannot carry PHI regardless of encryption

A personal gmail.com address is a consumer account. Google does not sign business associate agreements for consumer accounts, and HIPAA requires a BAA with every business associate that handles protected health information.

Encryption alone does not solve this. A sender who encrypts a message with a third-party tool but sends it from a gmail.com account is still transmitting PHI through a provider that has not agreed to safeguard it.

The Office for Civil Rights has fined practices for exactly this pattern. Small practitioners often assume that adding a padlock icon is enough. The Security Rule looks at both the transmission and the entity handling the transmission.

The compliant path is to move to Google Workspace on a paid plan with the practice’s own domain. That switches the account from a consumer service to a business service that Google will cover under a BAA.

Google Workspace signs a BAA for covered services

Google Workspace administrators can accept a BAA in the Admin console under Account, Legal and compliance. The acceptance is a two-click process for a super administrator.

The agreement covers a defined list of Google services, including Gmail, Calendar, Drive, Meet, Docs, Sheets, Chat, Vault, Keep, Sites, Forms, Slides, and Tasks. Not every Google product is covered.

Non-covered services include Google Groups, third-party marketplace apps, and any Google service the admin has not explicitly enabled for the covered set. Users who share a patient chart in Groups are outside the BAA.

The BAA takes effect at the moment of acceptance and applies to future activity. Past activity is not retroactively covered, so practices should sign the BAA before any staff account touches a patient message.

hipaa compliant email gmail in article illustration one

Encryption in Google Workspace uses TLS and server-side keys

Google Workspace encrypts stored messages at rest with keys Google manages. That protects the mailbox from physical disk theft or unauthorized access to Google infrastructure.

Transport uses TLS 1.2 or higher when the receiving server supports it. Google publishes real-time transparency numbers showing about 95 percent of Gmail traffic uses TLS in both directions.

The 5 percent gap is not random. It reflects small receiving servers, misconfigured domains, and systems that do not support current TLS versions. For a receiving practice on a legacy server, the message may still deliver over plain SMTP.

Enforcing TLS on outbound is a partial fix. Administrators can require TLS to specific recipient domains through the Admin console, but that only works if the receiving side supports it. Otherwise the message bounces.

Native S/MIME requires Enterprise Plus

Google Workspace supports hosted S/MIME on Enterprise Plus, Education Standard, and Education Plus. Business Starter, Standard, and Plus do not include native S/MIME.

Setup requires uploading an S/MIME certificate for each user through the Admin console and configuring the incoming and outgoing S/MIME settings. Certificates come from a certificate authority and typically renew annually.

To send an encrypted message to an external recipient, the sender needs the recipient’s public certificate. That is the friction point. Getting a public certificate from a patient is not a workflow that scales.

For that reason, most practices skip native S/MIME even on plans that support it, and they use a third-party gateway that handles the certificate problem through a portal instead.

[mh_example]

Virtru is a common third-party option for Gmail

Virtru offers a browser extension that adds an encryption toggle to the Gmail compose window. When the toggle is on, the message body and attachments are encrypted before they leave the browser.

External recipients receive a link, open the message in a Virtru portal, and authenticate with a Google or Microsoft account, or with a one-time passcode. The sender can revoke access or set an expiration.

Virtru signs a BAA with covered entities. Pricing is per-user per-month and scales with the size of the practice. Deployment requires the admin to allow the extension through the Chrome policy or install it manually per user.

The trade-off with any browser-based extension is that it depends on the user remembering to toggle the encryption on. A message sent without the toggle goes out in the clear.

hipaa compliant email gmail in article illustration two

Cisco Secure Email Encryption Service works for larger systems

Cisco Secure Email Encryption Service, previously Cisco Registered Envelope Service, is a portal-based product Cisco offers to enterprises. It integrates with the Cisco email security appliance and cloud email security offerings.

Recipients receive an encrypted envelope, click a link, and open the message in a Cisco-hosted portal after authenticating. The sender can require additional verification and can pull the message back after delivery.

Cisco will sign a BAA with covered entities. The service is more common in large hospital systems that already run Cisco email security infrastructure than in solo practices or small groups.

For a small practice on Google Workspace, Cisco is usually more infrastructure than the workflow needs. A smaller gateway or a browser extension delivers the same compliance result with less operational overhead. Practices comparing options often review the broader hipaa compliant email cisco landscape before choosing.

Hosted HIPAA email services layer over Gmail without a plan upgrade

A hosted HIPAA compliant email service handles the encryption, the portal, and the BAA on top of the existing Gmail account. The practice does not need to upgrade to Enterprise Plus or manage S/MIME certificates.

Providers in this category include Mailhippo, Paubox, LuxSci, and Hushmail. Each connects to a Gmail account through OAuth or SMTP relay and encrypts outbound messages before they leave the sender’s device or the relay.

The recipient experience varies. Some services deliver a portal link. Others encrypt via TLS enforcement and pass the message through with no visible portal for recipients whose provider supports it.

Mailhippo takes the middle path. Messages to compliant receiving servers deliver directly, and messages to non-compliant destinations fall back to a portal. That preserves the recipient’s inbox experience wherever the destination server can handle encrypted delivery.

[mh_protip]

Admin console settings that harden a Workspace tenant

Two-step verification should be enforced for every user on the tenant. Enforcement, not just enablement, is the setting that blocks a login without a second factor.

Legacy protocols like POP and IMAP should be disabled for accounts that do not need them. Every enabled legacy protocol is a potential authentication path that bypasses two-step verification.

Data Loss Prevention rules can inspect outbound mail for content patterns like Social Security numbers, credit card numbers, or clinical terms, and either block, warn, or redirect the message. DLP is included on Business Standard and higher.

The Google Workspace HIPAA compliance guide lists the specific settings Google recommends for covered entities. Working through the guide once and documenting the state of each setting is the closest thing to a self-audit for a small practice.

Common breach patterns in Gmail-based practices

Autocomplete misfires cause a large share of email breaches. A clinician types the first two letters of a patient’s name, Gmail suggests the wrong contact, and the message goes to the wrong person.

Forwarded threads are the second common pattern. A patient message gets forwarded to a colleague for consultation, then forwarded again to a family member, and the chain leaves the covered environment somewhere along the way.

Attachment mistakes come next. Staff attach the wrong PDF, or attach the correct PDF to the wrong thread. Google’s undo send window is 30 seconds at most and does not recover a message the recipient has already opened.

The HHS breach portal lists dozens of email incidents per year in the small provider category, and the pattern is consistent. Compliance-grade sending is a combination of platform, encryption, and process, and process is often the weakest link.

What to configure this week if you are on Gmail today

If the practice is on personal Gmail, the immediate step is to purchase a Google Workspace Business Standard plan or higher and migrate the account to the practice’s own domain. Business Basic does not include the security controls needed.

Sign the BAA in the Admin console, enforce two-step verification, disable legacy protocols, and confirm the covered services list matches what staff use for patient communication.

Install a third-party encryption extension or connect a hosted HIPAA email service. Test a message to a personal address on a provider that does not enforce TLS, and confirm the message arrives as a portal link rather than plaintext.

For practices that also need a compliant patient-facing website, forms, and marketing setup around the email service, working with an agency that focuses on HIPAA-compliant website design and the broader healthcare website conversion optimization workflow keeps the email, the intake, and the marketing on the same compliance footing.

  • Sign the Google Workspace BAA in the Admin console.
  • Enforce two-step verification for every user account.
  • Disable POP and IMAP unless a specific workflow requires them.
  • Install a hosted HIPAA email service or S/MIME certificates on Enterprise Plus.
  • Document the covered services list and confirm staff use only those services for PHI.

Setting up hipaa compliant email gmail is a paid Google Workspace plan, a signed BAA, an encryption path for external mail, and staff training. Miss any of those pieces and the account is not compliant no matter how the software looks from the outside.

[mh_faqs]

Posted on

TLS Encryption for Email Explained (How It Works, Where It Fails)

tls encryption email guide featured image

[mh_key_takeaways]

Most email delivery today runs over TLS. That protects the connection between mail servers, but it does not protect the message body itself.

Understanding tls encryption email is the difference between assuming a message is safe and knowing where it is exposed. For compliance-driven senders, TLS alone may not satisfy the requirement, and layering an encrypted email service on top closes the fallback gap that opportunistic TLS leaves open.

This guide covers what TLS actually does, where it falls short, and how to verify a mail flow is using TLS the way the sender expects.

TLS encrypts the connection, not the content

Transport Layer Security is the same protocol that secures HTTPS. In email, it secures the SMTP session between two mail servers.

When a sending server hands a message to a receiving server, both sides negotiate a TLS session. Once negotiated, all traffic on that connection is encrypted, including the message headers and body.

The receiving server decrypts the connection and stores the message. Whatever protection the message had during the transfer ends at that point. If the receiving mailbox is unencrypted at rest, the message sits in cleartext until the recipient reads it.

TLS protects against passive network eavesdropping between servers. It does not protect against the receiving server, an administrator on the receiving side, or anyone with legitimate mailbox access.

Opportunistic TLS is the default and its weakness

The default SMTP delivery model is opportunistic TLS. The sending server offers TLS, and the receiving server accepts if it supports the protocol.

If the receiving server does not support TLS, the message falls back to plain SMTP. The sending server delivers the message in cleartext rather than bouncing it.

The fallback is intentional. It preserves delivery in a world where not every mail server supports current standards. It also opens a downgrade attack path.

A network attacker who can intercept the SMTP conversation can strip the STARTTLS command from the greeting, and both sides will proceed in cleartext. This is called STRIPTLS and is well-documented in the mail security research community.

tls encryption email in article illustration one

MTA-STS and DANE close the fallback gap

MTA-STS publishes a policy in DNS and at a well-known HTTPS URL that tells sending servers to enforce TLS to a specific domain. If the handshake fails, the sender bounces the message rather than falling back to cleartext.

Google, Microsoft, and most large providers publish MTA-STS records and honor them on outbound. Smaller domains often do not, though adoption is climbing.

DANE uses DNSSEC-signed records to publish TLS certificate fingerprints. It provides similar downgrade protection with a different mechanism. DANE requires DNSSEC on the recipient’s domain, which limits deployment.

Both standards are documented in RFCs. MTA-STS is RFC 8461, and SMTP DANE is RFC 7672. Practices sending regulated content to unknown domains should publish MTA-STS on their own domain and consider DANE if their DNS provider supports DNSSEC.

Office 365 uses TLS on both directions with enforcement options

Microsoft 365 supports TLS 1.2 and 1.3 on inbound and outbound mail. TLS 1.0 and 1.1 were disabled across the platform in 2020, and legacy connections that try to use them fail.

Administrators can enforce TLS to specific recipient domains through Exchange Online connectors. A connector configured to require TLS refuses to deliver if the handshake fails, bouncing the message back to the sender.

Enforcement is useful for delivery to known partners and providers. Enforcing TLS globally is not practical, because it would bounce messages to any receiver that does not support current standards.

The Microsoft 365 admin center publishes TLS statistics in the mail flow reports. Practices can see the percentage of outbound and inbound mail using each TLS version and identify low-TLS destinations.

[mh_example]

Outlook covers the client-to-server hop only

Outlook is a mail client, not a mail server. Its TLS coverage is the connection from the desktop or mobile app to the mail server it authenticates against.

Every current version of Outlook enforces TLS 1.2 or higher for that connection. The client-to-server hop is encrypted regardless of what any downstream mail server does.

What happens after the message reaches the Microsoft 365 or Exchange server is out of Outlook’s control. The server handles delivery, and that delivery depends on the sending server’s TLS enforcement and the receiver’s TLS support.

Sending an encrypted-looking message from Outlook does not guarantee end-to-end TLS. It only guarantees the first hop. For full-path assurance, the sender needs message-level encryption or verified TLS enforcement on every hop.

tls encryption email in article illustration two

TLS alone does not fully satisfy HIPAA

The HIPAA Security Rule requires encryption of PHI in transit when reasonable and appropriate. TLS 1.2 or higher meets the technical standard for cipher strength and key length.

The gap is opportunistic delivery. A message sent from a compliant server can still travel in cleartext if the receiving server does not support TLS and the sender does not enforce it.

HHS has never issued a rule that TLS alone is insufficient. It has fined practices for unencrypted PHI transmission when opportunistic TLS was assumed but not verified.

The safer approach is layered. Use TLS for the transit layer, and use message-level encryption for the content. That way the message is protected regardless of what any intermediate server does. Practices reviewing the boundary between the two often look at the difference between tls encryption and email encryption to make the case internally.

How to verify a mail flow is using TLS

The Received header of any email shows the TLS status of the last hop. Look for a line like “using TLSv1.3” or “with STARTTLS.” A missing TLS notation means the hop was cleartext.

Google Postmaster Tools shows outbound TLS percentage per receiving domain. Practices sending large volumes can see which destinations regularly downgrade.

CheckTLS runs an on-demand test against any receiver. Enter a destination address, and CheckTLS attempts a full delivery, reporting the TLS version, cipher, and certificate details.

Microsoft 365 admins can enable connection logging under the Exchange admin center. The logs show per-message TLS status and are useful for troubleshooting a specific destination that keeps downgrading.

[mh_protip]

When a receiver does not support TLS, options are limited

A sender cannot force a receiving server to support TLS. If a specific destination refuses TLS, the sender has to work around it.

Option one is message-level encryption. Send the message through a service that encrypts the body and delivers a portal link. The receiver opens the link in a browser, and the connection to the portal uses HTTPS regardless of the receiving mail server’s capabilities.

Option two is contacting the receiving organization. Ask them to enable TLS 1.2 on their server. Small clinics, universities, and government agencies sometimes run outdated infrastructure and are open to fixing it when asked.

Option three is choosing a different channel for that specific recipient. A patient portal upload, a secure file transfer, or physical mail may be more appropriate than fighting a mail server that will not encrypt.

Configuring outbound TLS enforcement on the sender side

On Microsoft 365, administrators create a partner connector under Exchange admin center, Mail flow, Connectors. The connector points to the recipient domain and enables the option to require TLS.

On Google Workspace, administrators configure Compliance rules under Apps, Google Workspace, Gmail, Compliance. TLS requirements are set per recipient domain.

Enforced connectors bounce messages if TLS fails. That is the trade-off. The bounce is a clear signal that the destination is not honoring TLS, and it prevents the practice from accidentally sending PHI in cleartext.

For frequently-contacted partners, enforced TLS is worth the small operational overhead. For one-off external contacts, message-level encryption is usually simpler than configuring a connector.

Practical setup for a healthcare practice

Start with the inbound side. Confirm the practice’s mail server accepts TLS 1.2 or higher, publishes MTA-STS, and rejects deprecated cipher suites. Test with CheckTLS.

Move to the outbound side. Verify that outbound mail uses TLS 1.2 or higher and honor MTA-STS records from receiving domains. Google and Microsoft handle this automatically for tenants on current versions.

Add message-level encryption for external PHI transmission. Layer a service like Mailhippo or Purview on top of TLS. That way the content is protected even if any hop along the way downgrades to cleartext.

Practices that want the broader security posture to match the email layer often work with an agency familiar with healthcare marketing and healthcare website security features. Consistent security across email, forms, and website matters to auditors and to patients. The NIST SP 800-52 Rev. 2 guidelines outline the cipher and version baselines to match.

  • Confirm inbound and outbound TLS 1.2 or higher on the mail server.
  • Publish MTA-STS on the practice’s own domain.
  • Enforce TLS to known partners through Exchange or Gmail connectors.
  • Add message-level encryption for external PHI mail.
  • Run quarterly TLS verification tests and log the results.

TLS encryption email covers the network path between servers. It does not cover the content once the message lands, and it can fall back to cleartext when a receiver refuses to negotiate. Understanding those limits is what separates a working mail flow from a compliant one.

[mh_faqs]

Posted on

PGP Email Encryption Explained for Gmail and Outlook

pgp email encryption guide featured image

[mh_key_takeaways]

PGP email encryption has been the go-to method for security-conscious technical users since the 1990s. The current OpenPGP standard, RFC 9580, still uses the same public-key model that Phil Zimmermann designed in 1991, refreshed with modern algorithms.

PGP is strong, well-audited, and free in its GnuPG form. It is also famous for being harder to use than any browser-based alternative, which is why enterprises pair it with commercial key management and why patient-facing practices usually reach for a portal-based encrypted email service instead.

This guide covers what PGP actually does, how it fits with Gmail, Outlook, and Symantec Encryption, where it stands next to S/MIME, and when a simpler alternative saves days of key management work.

PGP uses public-key cryptography to protect the message body

PGP encrypts the message body with a symmetric AES key that is itself encrypted with the recipient public key. The recipient decrypts the AES key with their private key, then decrypts the body.

The same message can be signed with the sender private key, which lets the recipient verify the sender identity by checking the signature against the sender public key.

Public keys are shared through key servers, personal websites, or attached to a first message. The recipient can verify the public key belongs to the claimed sender by comparing the key fingerprint out-of-band, typically over a phone call.

The full protocol is defined in RFC 9580. GnuPG on Linux and the command line, GPG Suite on macOS, and Kleopatra on Windows all implement the same standard.

PGP does not protect the subject line or the routing headers. It only encrypts the message body and any attached payloads inside the PGP envelope.

PGP for Gmail requires a browser extension

Gmail does not include native PGP support in either the web client or the mobile apps. A browser extension bridges Gmail and the local PGP toolchain.

Mailvelope is the most widely used extension. It stores keys in a browser-managed keyring, wraps the Gmail compose window with an encrypt and sign toolbar, and outputs an armored OpenPGP block that Gmail sends as normal message text.

FlowCrypt is a paid alternative that adds enterprise features like automatic key discovery, a shared keyring, and Outlook integration. It handles the same PGP protocol under the hood.

The recipient side needs the same extension or another PGP-aware client to decrypt. That works well for developer-to-developer mail but breaks down for patient mail because patients do not install extensions.

Practices already on Google Workspace Enterprise Plus can enable hosted S/MIME instead, which handles encryption at the Gmail server side. S/MIME setup and key management is documented in the guide on S/MIME email encryption.

pgp email encryption in article illustration one

PGP for Outlook uses gpg4win or a commercial add-in

Outlook on Windows integrates with PGP through an add-in. Gpg4win with the GpgOL plug-in is the free option and installs a set of encrypt, sign, and decrypt buttons in the compose ribbon.

The add-in reads keys from the local GnuPG keyring. Enterprise deployments typically populate the keyring through a central key server or a directory that stores each user public key alongside their Active Directory entry.

Symantec Encryption Desktop, sold today under the Broadcom Symantec Encryption product line, is the commercial packaging. It adds central policy control, a Symantec Encryption Management Server for key escrow, and support for Outlook and other clients.

Outlook on macOS does not have an official gpg4win port. Users on macOS typically switch to Apple Mail with GPG Suite for PGP, or they run Outlook in a browser and use a PGP-aware webmail extension.

Outlook on the web does not support PGP add-ins directly. Organizations using OWA for their primary interface generally pick S/MIME or Purview Message Encryption instead, or route mail through a gateway that applies encryption at the transport.

Symantec PGP centralizes key management for the enterprise

Symantec PGP was originally sold by PGP Corporation, acquired by Symantec in 2010, and now sold under the Broadcom umbrella. The product line is Symantec Encryption Desktop and Symantec Encryption Management Server.

The Encryption Management Server is the piece that most GnuPG deployments do not have. It centralizes key generation, escrow, revocation, and policy enforcement across the tenant.

Encryption Desktop installs on each endpoint and handles the Outlook add-in, disk encryption, and file encryption. It reads policy from the management server on start and applies encryption rules to outbound mail.

The commercial packaging removes the key management overhead that stops many teams from adopting PGP. It does not remove the recipient-side requirement, so PGP still fits internal enterprise mail and B2B mail with a matched setup better than it fits patient mail.

Support and licensing are through Broadcom. Pricing is not published publicly, and quotes come through a Broadcom sales contact or an authorized reseller.

[mh_example]

PGP compared to S/MIME on the practical decisions

PGP and S/MIME both use public-key cryptography to encrypt email. They differ on trust model, mail client support, and enterprise integration.

PGP relies on a web of trust, where users sign each other keys directly. S/MIME relies on a certificate authority, where a trusted CA signs each user certificate.

S/MIME is built into Outlook, Apple Mail, and Google Workspace Enterprise Plus without a plug-in. PGP requires an extension or an add-in for every mainstream email client.

Feature PGP S/MIME
Trust model Web of trust Certificate authority
Standard OpenPGP RFC 9580 S/MIME RFC 8551
Native Outlook support Add-in required Built in
Native Gmail support Browser extension Hosted S/MIME on Enterprise Plus
Native iPhone Mail Not supported Built in with configuration profile
Key exchange Manual or key server Certificate exchange in signed messages
Typical use case Developer to developer, B2B security teams Enterprise internal, government

For patient mail, neither PGP nor S/MIME is a great fit because patients do not hold keys. Portal-based encrypted email services skip the key exchange step and are documented in the guide on email encryption.

pgp email encryption in article illustration two

Key management is the hard part of PGP

Generating a PGP key pair takes one command. Managing that key pair across a laptop, a phone, a work desktop, and a home machine, over five years and multiple client switches, is the actual work.

Best practice is to keep the private key on a hardware security module or a YubiKey rather than on the disk. That removes the risk of a stolen laptop exposing years of encrypted mail.

Public keys need to be published somewhere the sender can find them. Options include the personal Keyoxide profile, a personal website, a company directory, or the older SKS keyserver network, which is now mostly deprecated.

Key revocation is the other hard problem. When a private key is compromised, the user needs to publish a revocation certificate so that senders stop encrypting to the old key.

Enterprise deployments handle this through a management server. Individual users typically write the revocation certificate to paper when they generate the key and store it in a safe.

HIPAA compliance needs more than PGP encryption alone

PGP encryption satisfies the transmission security part of the HIPAA Security Rule when applied to messages containing protected health information. That is not the full compliance picture.

HIPAA also requires a signed business associate agreement with any vendor that handles PHI, access controls on the mailbox and the key store, audit logs of who sent and received each message, and an incident response procedure for lost or stolen keys.

Google Workspace and Microsoft 365 offer a BAA on eligible paid plans, but the practice must actively request and sign it. Free consumer Gmail and personal Outlook.com are never covered by a BAA, regardless of whether PGP is layered on top.

The HHS Covered Entities reference covers when a BAA is required. Any vendor that touches, stores, or transmits PHI on the covered entity behalf falls under the rule.

Practices building a full patient communication stack also need to think about the surrounding website. Guidance on security features for healthcare websites covers form handling, SSL, and portal integration alongside encrypted mail.

[mh_protip]

PGP fits developer and B2B mail better than patient mail

PGP shines in two common use cases. The first is developer-to-developer mail, where both sides already have keys, run a PGP-aware mail client, and value the strong cryptography.

The second is B2B mail between two security teams, where the setup cost is paid once and the volume justifies it. Enterprises exchanging incident data, threat intelligence, or contract packages often use PGP over commercial email gateways.

Patient mail rarely fits either shape. Patients do not have keys, do not run a PGP-aware client, and will not install a browser extension on the phone they use to check email.

For patient mail, portal-based encrypted email services deliver a link that the patient opens with a passcode. The message and any attachments live inside the portal, and the recipient reads and replies without installing anything.

Referring providers and insurance carriers usually accept portal-based delivery because it does not depend on their own encryption setup. That decouples the practice mail from every partner IT team.

Automation with PGP uses gpg and Bouncy Castle

Automated PGP encryption for batch mail from a report generator or a lab bridge uses the gpg command line on Linux and the Bouncy Castle PGP API on Java.

The gpg –encrypt –recipient email@example.com command reads the file from stdin, encrypts with the recipient public key, and writes the armored output. A shell script pipes the output into mutt or msmtp for delivery.

Bouncy Castle provides the PGPEncryptedDataGenerator, PGPCompressedDataGenerator, and ArmoredOutputStream classes. The Java code loads the recipient public key from a keyring, wraps the message bytes, and writes the resulting armored OpenPGP block into a MimeBodyPart.

For applications sending PHI at scale, calling a secure email API that handles encryption server-side is usually faster than adding key management inside the application. The API pattern also simplifies deployment because the container image does not carry key files.

The choice comes down to whether the recipients already run PGP. If yes, the code path stays inside the application. If no, a portal delivery service handles the recipient side without asking them to set up anything.

When PGP is the right answer and when to pick something else

PGP is the right answer when both sides already run PGP, the recipient will not accept portal links, and the volume justifies the setup cost. It is also the right answer when the recipient is a security team that expects an armored OpenPGP block in the message body.

S/MIME is the right answer for internal enterprise mail where every mailbox is on the same Outlook or Google Workspace tenant and every user already has a certificate through the corporate PKI.

Portal-based encrypted email is the right answer for patient mail, referring providers, and insurance carriers. The recipient opens a link, signs in with a passcode, and reads the message without any account setup.

For a small practice sending a mix of internal, referring provider, and patient mail from Gmail or Microsoft 365, layering a dedicated encrypted email service on top of the existing mailbox covers all three cases with one setup step.

Whichever method fits, run a round-trip test with a real recipient before rolling it out. The most common cause of failed PGP deployments is that the sender got a green Encrypt button but the recipient never received a readable message.

[mh_faqs]

Posted on

How to Remove Encryption From Outlook Email in 2026

how to remove encryption from outlook email guide featured image

[mh_key_takeaways]

Removing encryption from an Outlook email sounds like a one-click task. In practice the steps depend on which layer of the Microsoft encryption stack applied the encryption in the first place.

Outlook uses three separate encryption layers. Microsoft Purview Message Encryption at the tenant policy layer, S/MIME at the per-message certificate layer, and Information Rights Management at the sensitivity label layer. Each layer has its own removal path. Users trying to manage encrypted email across a mixed environment need to know all three.

This guide walks through removing encryption from an outbound message before you send it, from a received message so you can reuse the content, and from tenant policy when an admin needs to shut off automatic encryption on a specific rule.

Identifying which Outlook encryption layer applied to a message

Open the message. Click the ellipsis or three-dot menu. Choose Message Options or Properties, depending on the Outlook version.

The Properties dialog shows the message class. rpmsg indicates Purview Message Encryption. IPM.Note.SMIME indicates S/MIME. The Sensitivity field shows any active IRM label. This one dialog answers most encryption-source questions in under a minute.

Once you know the layer, you know the removal path. Purview Message Encryption removes at the Encrypt button on the Options ribbon or through a tenant mail flow rule change. S/MIME removes through the Encryption toggle in the Options ribbon. IRM labels remove through the Sensitivity dropdown near the message subject line.

Users who skip the identification step end up clicking every toggle they can find. The wrong toggle often does nothing because it addresses a different layer than the one applying encryption.

Removing encryption from an outbound Outlook message on desktop

Compose the message as usual. Go to the Options ribbon at the top of the composer window. The Encrypt button lives in the Permission group near the middle of the ribbon.

Click the Encrypt button. If encryption was on, the button toggles off and the shield icon disappears from the composer. If the button opens a dropdown, choose No Encryption at the top of the list.

Send the message. The recipient receives the message without any portal link or password step. Verify by checking the sent copy in the Sent Items folder and reviewing the message class in Properties.

If the Encrypt button is grayed out, a tenant mail flow rule is enforcing encryption based on recipient domain, subject line keyword, or content pattern. The user cannot override the rule. Contact the tenant admin or route the message through how to encrypt email from outlook alternative flows if a genuine business need exists.

how to remove encryption from outlook email in article illustration one

Removing encryption from an outbound Outlook message on web

Outlook web uses a slightly different navigation. Compose the message. Click the three-dot menu at the top of the composer, next to the Send button.

Choose Encrypt from the dropdown. A submenu opens with encryption options. Select No Encryption or click the current option again to toggle it off.

Outlook web shows a lock icon at the top of the composer when encryption is active. The icon disappears after you toggle encryption off. Send the message when the icon is gone.

Outlook web hides some encryption options behind the plan tier. Business Basic users see fewer options than Business Premium users. Enterprise E5 users see the most options because Purview features are all included. Reference the current option matrix at Microsoft Learn Purview Message Encryption.

Removing encryption from an outbound Outlook message on mobile

The Outlook mobile app on iOS and Android places the encryption toggle inside the ellipsis menu of the composer. Tap the ellipsis to open the extended menu.

Tap Encrypt Message. A screen appears with the current encryption setting. Choose No Encryption and tap the back arrow to return to the composer.

The lock icon in the composer header disappears when encryption is off. Send the message from the mobile composer. The recipient receives an unencrypted message that opens in any mail client.

Users on personal iPhones sending occasional PHI often struggle with the mobile encryption workflow. A dedicated app like how to encrypt email from iphone guide setups or a service like Mailhippo simplifies the mobile case without requiring native Outlook encryption at all.

[mh_example]

Removing encryption from a received Outlook message

You cannot un-encrypt a message the sender encrypted. Outlook decrypts the message for display, but the encrypted copy stays in the mailbox database.

The workaround is to reply or forward without encryption when the sender policy allows. Open the message. Click Reply or Forward. Check the composer for the encryption toggle and turn it off if it appears.

Some sender policies apply Do Not Forward or block copy and paste at the label level. In that case the received message cannot be extracted at all. Reach out to the sender and ask them to resend without the restrictive label.

For content you need to move to another system, select all text in the decrypted view, copy, and paste into a fresh unencrypted message. Attachments require a separate step because Outlook often keeps attachments encrypted even when the body decrypts.

Removing encryption from Office 365 mail flow rules as an admin

Sign in to the Exchange admin center at admin.exchange.microsoft.com. Open Mail Flow, then Rules.

Review each rule in the list. Rules that apply encryption usually have Apply Office 365 Message Encryption or Apply RMS Template in the action list. Note the rule name and business owner before making any change.

To disable a rule, toggle the Enabled switch to off. To delete a rule, use the three-dot menu and choose Delete. Test the change on a pilot mailbox first. Send five test messages that would have matched the rule and confirm they arrive without encryption.

Common admin steps:

  • Document the business reason for removing the rule
  • Notify the privacy officer if the rule protected PHI
  • Set a change ticket in the tenant change log
  • Wait 30 minutes after disabling before testing
  • Keep an export of the rule XML for rollback
how to remove encryption from outlook email in article illustration two

Removing encryption from an Office 365 sensitivity label

Sensitivity labels in Microsoft Purview apply encryption at the label level. A message tagged with a Confidential label carries encryption for the life of the message.

To remove encryption from a specific label, sign in to purview.microsoft.com. Open Information Protection, then Labels. Select the label. Click Edit Label.

In the encryption settings step, choose None. Save the change. New messages tagged with the label send without encryption. Existing messages already sent with the label keep their encryption because the metadata was baked in at send time.

Removing encryption from a label affects every user who applies that label. Rename the label to avoid user confusion. A label named Confidential that no longer encrypts creates trust issues with the privacy officer and the audit team.

Removing S/MIME encryption in Outlook desktop

S/MIME encryption relies on a certificate installed on the sender machine. The certificate applies encryption per message through the Trust Center settings.

To turn off S/MIME on a single message, open the composer and go to Options, More Options, Security Settings. Uncheck Encrypt Message Contents and Attachments. Send the message without S/MIME encryption.

To turn off S/MIME across all outbound messages, go to File, Options, Trust Center, Trust Center Settings, Email Security. Uncheck Encrypt Contents and Attachments for Outgoing Messages. Click OK.

Removing the S/MIME certificate entirely happens in the Windows certificate store. Type certmgr.msc in the Run dialog. Open Personal, Certificates. Delete the S/MIME certificate. Deleting the certificate also breaks decryption of past S/MIME messages, so export a backup first.

[mh_protip]

Removing encryption from Outlook messages in bulk

Outlook has no built-in bulk decrypt feature. Third party tools claim to bulk decrypt, but most require the sender private key and produce plaintext exports rather than in-place changes.

The supported path for bulk access uses eDiscovery in the Purview compliance portal. Create a content search that includes the target mailboxes. Export the results as a PST with the Include All Encrypted Messages option checked.

The exported PST contains decrypted copies of every message the running admin has permission to read. Import the PST into the destination mailbox using the Outlook Import feature. The imported copies are unencrypted.

Use this pattern for legal hold, migration, or forensic review only. Bulk decryption for general access defeats the point of the encryption in the first place. Reference guidance from HHS HIPAA Security Rule before running bulk decryption on any mailbox with PHI.

Common Outlook encryption removal errors and fixes

The Encrypt button stays selected even after you click it. Usually a mail flow rule is forcing encryption at the tenant. Check with the admin.

The message arrives at the recipient with the encryption warning banner even though you removed encryption. The recipient mail server flagged the message as suspicious because the sender IP does not match the tenant SPF record. Fix the SPF record.

Attachments still open with a password prompt. Purview Message Encryption applies to attachments through the same policy. Removing encryption from the body does not automatically release the attachments. Re-attach the files after removing encryption to reset the attachment state.

The recipient sees a portal link instead of the message body. The recipient mail client stripped the message body during transport. Check the recipient inbox rules and any downstream security gateways.

When to keep Outlook encryption on and route around it instead

Removing encryption from healthcare, financial, or legal correspondence creates compliance exposure. HIPAA, GLBA, and state privacy laws require encryption of regulated content in transit.

Practices with intermittent encryption needs often benefit from a per-message alternative rather than a permanent policy change. How to send encrypted email guides and services like Mailhippo work alongside Outlook without replacing the native stack.

Mailhippo adds a per-message send option to Outlook. When the sender needs encryption for a specific message, the Mailhippo option applies encryption and a BAA-covered delivery path. When the sender does not need encryption, the message goes out through normal Outlook without any policy conflict. Practices also handling healthcare web hosting and healthcare website maintenance pair the same discipline across their web and email stacks.

For further reference, review CISA cybersecurity advisories on message encryption baselines and the HIPAA Journal on compliant email before making any tenant-level encryption change that affects regulated traffic.

[mh_faqs]

Posted on

Email Encryption Solutions Compared for HIPAA and Business Use

email encryption solutions guide featured image

[mh_key_takeaways]

Email encryption solutions fall into three architectural buckets, and the right pick depends on team size, HIPAA scope, and recipient mix. Native platform encryption, portal-based services, and gateway suites each solve the same problem with different trade-offs.

This guide compares the three approaches, walks through the leading vendors in each category, and lays out a decision framework for practices choosing an encrypted email service in 2026. The comparison focuses on real recipient experience and admin cost rather than marketing feature lists.

Healthcare teams that need HIPAA scope should also review the broader stack of controls around patient communication, including intake forms, portals, and website security. The healthcare marketing agency team at Redefine Web sees encryption gaps most often on smaller practices without dedicated IT.

Three architectures cover the entire market

Native platform encryption ships inside Microsoft 365 Business Premium, Enterprise plans, and Google Workspace with the S/MIME add-on. It relies on tenant licensing and integrates directly with the mail client.

Portal-based services accept plain mail from the sender, encrypt it in transit, and store it behind a secure viewer. The recipient clicks a link and signs in or enters a passcode to read the content.

Gateway and client-side services sit between the sender mail server and the receiving mail server. They negotiate TLS with the recipient server when possible and fall back to a portal only when TLS fails.

All three architectures use AES-256 for at-rest encryption and TLS 1.2 or higher in transit. The differences show up in recipient experience, admin overhead, and price.

Recipient experience decides adoption more than cryptography

Recipients rarely care about the underlying encryption protocol. They care about how many clicks separate them from the message and how often a portal step interrupts a normal reply thread.

Native platform encryption reads inline when both parties use the same platform. Cross-platform mail, Microsoft to Gmail or the reverse, forces a portal step for the recipient.

Portal services always route through a viewer, even when both parties use compatible platforms. The consistency helps admins but frustrates recipients who exchange many messages per day.

Gateway services deliver inline in most cases and fall back to a portal for the small percentage of recipients whose mail servers reject modern TLS. The best gateway architectures produce the smoothest recipient experience overall.

email encryption solutions in article illustration one

HIPAA scope requires a signed Business Associate Agreement

Every HIPAA-scoped email flow needs a BAA between the covered entity and the encryption vendor. The BAA defines breach notification timelines, subcontractor rules, and audit access rights.

Microsoft and Google sign a BAA at no extra cost on Business and Enterprise plans through the Service Trust Portal or the Google Cloud console. That BAA covers Purview Message Encryption and Workspace S/MIME.

Personal Gmail, Business Standard without the Compliance add-on, and free Outlook.com accounts do not qualify for a BAA. Practices sending PHI through those accounts sit outside HIPAA scope regardless of technical encryption.

Dedicated encrypted email services usually include the BAA in the base plan without an upgrade or per-seat premium. This makes them a simpler compliance path for practices without existing Business Premium licensing.

Comparison table of the leading email encryption solutions

The table below compares the three architectural approaches on the criteria that matter most to healthcare and small business practices. Individual vendor names appear in each category to anchor the trade-offs.

Approach Example vendors Recipient experience BAA in base plan Admin overhead Best for
Native platform Microsoft Purview, Google Workspace S/MIME Inline for same platform, portal for others Yes on Business Premium and above Medium to high Practices already on Business Premium with IT lead
Portal-based service Mailhippo, Barracuda Cloud Email Portal for every recipient Yes on standard plans Low Small practices under 50 seats without dedicated IT
Gateway suite Cisco Secure Email, Proofpoint Inline via TLS, portal fallback Yes on healthcare tier High Hospital systems above 200 seats with compliance officer
S/MIME direct Sectigo, DigiCert Inline for both parties Certificate vendor separate from BAA Very high Regulated industries requiring certificate control

The right pick rarely matches the sticker price. Total cost of ownership includes license fees, IT hours, workforce training time, and helpdesk load for recipient confusion.

[mh_example]

Native Microsoft 365 encryption fits Business Premium tenants

Microsoft Purview Message Encryption ships with Business Premium, E3, E5, and equivalent education, nonprofit, and government plans. The Encrypt button lives in the Outlook Options ribbon.

Setup takes an hour for a basic deployment. Mail flow rules under the Exchange admin center automate encryption based on keywords, sensitivity labels, or recipient domains. Training staff on when to click Encrypt takes longer.

Business Standard tenants face a decision. Upgrading every seat to Business Premium adds meaningful monthly cost, and the E5 Compliance add-on requires an existing Business or Enterprise base license.

The full detail of the Outlook workflow lives in the outlook 365 encrypt email guide, which walks through the Encrypt button, mail flow rule setup, and licensing decisions.

Google Workspace S/MIME fits Enterprise tenants with certificate control

Google Workspace Enterprise plans support hosted S/MIME, which encrypts messages with certificates issued to individual users. The receiving mail server decrypts inline when it holds the matching public certificate.

S/MIME does not fall back to a portal for external recipients without certificates. Messages sent to Gmail personal accounts, Yahoo, or non-S/MIME organizations arrive as plain text unless a separate encryption layer intervenes.

The certificate management overhead scales poorly. Practices with 20 staff and 500 external contacts spend hundreds of hours per year issuing, renewing, and revoking certificates. Most healthcare teams pick a different approach.

The broader network solutions email encryption question spans S/MIME, PGP, and hybrid architectures. Enterprise IT teams sometimes deploy multiple layers to cover different recipient categories.

email encryption solutions in article illustration two

Portal-based services fit small practices without dedicated IT

Portal-based services deploy in an afternoon and require no certificate management, no MX record changes, and no mail flow rules. The service intercepts outbound messages that hit a defined trigger and routes them to a secure viewer.

The BAA typically ships in the base plan. Mailhippo, Virtru business tier, and Barracuda Cloud Email cover the BAA at no extra cost for healthcare customers. Pricing lands around a few dollars per user per month.

Portal fatigue is the main drawback. Recipients who exchange multiple messages per week with the practice eventually complain about the login step. A branded portal with practice logo and disclaimer reduces the friction.

Practices under 50 seats without a dedicated IT lead usually pick this category. The hipaa complaitn email solutions guide compares three portal services in more detail.

Gateway suites fit enterprise environments with archiving needs

Cisco Secure Email, Proofpoint Essentials, and Barracuda Advanced Threat Protection sit at the network edge and inspect every message. They handle inbound spam, outbound encryption, and DLP under a single admin console.

The gateway architecture delivers inline when the receiving mail server supports TLS 1.2 or higher. Modern Gmail, Outlook, and major hosted providers all negotiate TLS, so most recipients read the message without a portal step.

Deployment requires MX record changes, TLS certificate rotation, and DKIM and DMARC alignment. Small teams that lack a dedicated mail admin should budget several weeks for a clean rollout.

Enterprise gateway pricing runs a few hundred dollars per user per year and often includes archiving, DLP, and threat intelligence. The enterprise email encryption solutions guide covers the deployment path in detail.

DLP integration matters more as PHI scope grows

Data loss prevention scans outbound mail for patterns that match sensitive information. Common patterns include Social Security numbers, medical record numbers, credit card numbers, and named entity matches for patient data.

DLP paired with encryption removes the burden on staff who forget to click Encrypt. When DLP finds a match, the mail server applies encryption automatically or blocks the message for admin review.

Enterprise gateway suites include DLP in the base plan. Portal-based services offer it as an add-on. Native Microsoft 365 encryption requires the E5 Compliance license or Business Premium with Purview DLP policies.

Small practices with fewer than 20 seats often skip DLP and rely on staff training. The NIST Cybersecurity Framework recommends DLP for any organization handling regulated data at any scale, but implementation cost stays a real barrier.

[mh_protip]

Total cost of ownership rewards honest math

Sticker price rarely tells the full story. A portal service at five dollars per user per month looks cheaper than Business Premium until the practice adds the cost of the Microsoft license the staff already needed.

Add IT hours for deployment, maintenance, and troubleshooting. Native platform encryption requires certificate rotation and mail flow rule tuning. Portal services need a one-time DNS check. Gateway suites need ongoing tuning of DLP and spam rules.

Add workforce training. Every solution requires training staff on when to encrypt, how to explain the recipient experience, and what to do if a message bounces. Budget an hour per staff member per year.

Add helpdesk load for recipient portal confusion. First-time recipients ask questions. A branded portal, a clear cover message, and a support contact reduce the volume but do not eliminate it.

A decision framework built on team size and mail patterns

Practices under 20 seats without dedicated IT usually pick a portal-based service. The BAA ships in the base plan, deployment takes an afternoon, and the recipient experience stays consistent across every provider.

Practices between 20 and 100 seats with an internal IT lead face the widest set of choices. Native Microsoft 365 fits if the tenant already runs Business Premium. Otherwise a portal service still wins on total cost.

Enterprise systems above 200 seats with a compliance officer usually pick a gateway suite. The DLP, archiving, and threat intelligence integration justify the higher per-seat cost when the alternative is buying three separate tools.

Regulated environments requiring certificate control, such as federal contractors and specialty lab networks, layer S/MIME on top of a portal or gateway service. The email encryption guide covers the layering pattern in detail.

Migration paths keep the switch low risk

Switching encryption vendors rarely requires a mail server migration. Portal services layer on top of the existing account, gateway services swap the MX record, and native platform encryption changes only the internal admin console configuration.

Test the new service with a small internal group for two weeks. Send messages to Gmail, Outlook, Yahoo, and a consumer ISP address. Confirm the recipient experience matches expectations and the audit log captures the events.

Roll out to the full team after the test group signs off. Keep the old service running for a week in case a rule needs adjustment. Cancel the old contract only after the audit log for the new service covers a full month.

Document the change in the HIPAA Security Rule risk analysis and update workforce training records. Practices that skip this step create audit gaps that the Office for Civil Rights investigators note during breach investigations.

  • Confirm the vendor signs a BAA covering the encryption service itself, not just the underlying platform.
  • Test the recipient experience across Gmail, Outlook, Yahoo, and a consumer ISP address before committing.
  • Budget IT hours, training time, and helpdesk load in addition to license fees when comparing solutions.
  • Document the encryption decision in the HIPAA Security Rule risk analysis for audit defensibility.
  • Review the choice annually as licensing changes and vendor pricing shifts often outpace initial expectations.

Choosing the right email encryption solution comes down to matching architecture to team size, HIPAA scope, and recipient mix. Every serious solution meets the technical safeguard for encryption, so the differences that matter show up in daily use rather than in the vendor pitch deck.

[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