Posted on

Encrypting an Email Explained From Setup to Recipient View

encrypting an email guide featured image

🔑 Key Takeaways

  • Encryption turns the message body and attachments into ciphertext only the reader can decrypt.
  • Business Premium unlocks the Outlook Encrypt button; lower tiers need a bump or a HIPAA service.
  • Gmail client-side encryption requires Workspace Enterprise Plus and a customer-managed key service.
  • Attachments encrypt with the body across S/MIME, PGP, Purview, and Google client-side encryption.
  • Encryption alone fails HIPAA without a signed BAA, access logs, staff training, and response plan.

Encrypting an email converts the message body and attachments into ciphertext that only an authorized recipient can read. The sending client, the mail server, or both handle the encryption depending on the method used.

This guide covers the current methods for encrypting an email across Outlook, Gmail, and HIPAA-focused services. It explains the setup, the sender steps, the recipient experience, and when a dedicated encrypted email service is a simpler fit.

Encryption is one layer in a broader security posture. The right method depends on plan level, recipient environment, and compliance requirements. Read each section to match the method to the use case.

Encryption Standards Fall Into Three Main Categories

Email encryption uses three main models: transport-level encryption, message-level encryption, and portal-based encryption. Each model protects a different segment of the delivery path.

Transport-level encryption uses TLS between the sending and receiving mail servers. TLS is the baseline. It protects the message during network transmission but leaves the content in cleartext on the mail servers at each end.

Message-level encryption uses S/MIME or PGP to encrypt the message body and attachments before they leave the sending client. Only the recipient key can decrypt the message. The mail servers see ciphertext.

Portal-based encryption stores the encrypted message on a server and delivers a link to the recipient. Microsoft Purview Message Encryption and most HIPAA email services use this model. The recipient authenticates and reads the message in a browser session.

Microsoft Purview Message Encryption Covers Most Outlook Users

Microsoft Purview Message Encryption is the default encryption path for Outlook users on Microsoft 365 Business Premium and higher. The sender clicks Options, then Encrypt, in the ribbon of a new message. Purview handles the encryption and delivery on the server side.

Two options appear: 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.

External recipients on Gmail, Yahoo, or another provider receive 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.

Detailed sender steps are in the Microsoft support guide for encrypted messages in Outlook. The setup on the tenant side is minimal if Azure Rights Management is already active.

encrypting an email in article illustration one

Gmail Users Rely on Confidential Mode or Client-Side Encryption

Gmail offers two encryption features. Confidential mode is available on every Gmail account, including personal Gmail and every Workspace plan. Client-side encryption is available only on Workspace Enterprise Plus and Education Plus.

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

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

Standard Workspace plans that need encryption for HIPAA use a gateway or a dedicated HIPAA email service. The Gmail interface stays the same. The encryption happens at the outbound gateway or at the service layer.

S/MIME Provides End-to-End Encryption With Certificates

S/MIME is a message-level encryption standard supported by Outlook, Apple Mail, and most enterprise mail clients. It uses X.509 certificates issued by a trusted certificate authority such as DigiCert, Sectigo, or IdenTrust.

The sender installs a personal certificate in the mail client. The recipient must also have an S/MIME certificate available. Outlook stores recipient certificates from signed messages the user has previously received.

Once certificates are in place, the sender clicks Encrypt on a new message. The mail client uses the recipient public key to encrypt the content. The recipient decrypts with the private key stored in the recipient client.

S/MIME provides true end-to-end encryption because no server between the sender and recipient can decrypt the message. The trade-off is certificate management. Practices with dozens of external recipients need a workflow for exchanging certificates before the first encrypted message can go out.

Example

A behavioral health group of eight clinicians switches from personal Gmail to Google Workspace Business Standard for HIPAA coverage. The admin accepts the BAA in the console, but discovers client-side encryption requires Enterprise Plus at roughly $30 per user. Instead of upgrading all eight seats at $240 per month, the group adds a HIPAA email service at $10 per clinician for $80 per month. The service handles PHI mail with encryption plus BAA, and Workspace Business Standard handles everything else.

PGP Handles Encryption Between Technical Users

PGP, sometimes called OpenPGP or GPG, is a second message-level encryption standard. It relies on a web of trust rather than a centralized certificate authority. Users generate a key pair and publish the public key to a key server or exchange it directly.

PGP is common in security research, legal work, and technical communities where both parties are comfortable managing keys. Mainstream Outlook and Gmail do not include PGP out of the box. Third-party plugins add support.

The strengths of PGP are strong cryptography and no dependence on a central authority. The weaknesses are key management overhead and a recipient experience that assumes technical familiarity. A patient receiving a PGP message will not know how to decrypt it.

Healthcare practices sending PHI to patients almost never use PGP because the recipient experience is unrealistic. PGP fits internal or business-to-business scenarios where both sides run the same tooling.

TLS Alone Does Not Meet HIPAA Transmission Requirements

TLS encrypts the connection between mail servers. It is the baseline for any modern mail transmission. TLS 1.2 and TLS 1.3 are the current versions in use, according to NIST SP 800-52 Rev. 2.

Opportunistic TLS is the common default. If the receiving server supports TLS, the connection uses TLS. If the receiving server does not support TLS, the connection falls back to cleartext. A sender using opportunistic TLS cannot guarantee the message stayed encrypted end to end.

Forced TLS requires the receiving server to support TLS or the message does not go out. Forced TLS is safer but harder to configure across a large recipient list. Most Outlook and Gmail tenants use opportunistic TLS by default.

HHS guidance treats TLS as acceptable for transmission but recommends message-level encryption for high-risk PHI. See the HHS Security Rule guidance for the current position. Practices should assume TLS alone is not sufficient.

encrypting an email in article illustration two

Sensitivity Labels Automate Encryption at Scale

Sensitivity Labels in Microsoft 365 apply encryption automatically based on content classification. Administrators define labels in the Microsoft Purview compliance portal and set rules that trigger a label when the message contains specific patterns.

Patterns can include medical record numbers, Social Security numbers, credit card numbers, or custom regular expressions for practice-specific fields. A matching pattern applies the label and the encryption policy in one step.

The sender does not have to remember to click Encrypt. The system enforces encryption based on content. This removes human error from the encryption decision on routine mail.

Deployment requires Microsoft 365 E3 or E5 licensing and configuration of Purview Information Protection. Sensitivity Labels fit large practices and health systems that already run Microsoft 365 at the enterprise tier.

Attachments Are Encrypted Along With the Message Body

Every current message encryption method encrypts attachments as part of the message. S/MIME, PGP, Microsoft Purview, and Google client-side encryption all treat attachments and the body as a single encrypted unit.

The recipient sees one verification step. After the sign-in or key decryption, both the body and the attachments become readable. Do Not Forward rights in Microsoft Purview show attachments in the portal preview and block download.

Attachment size limits apply before encryption is added. Outlook and Gmail cap standard attachments at 20 to 25 megabytes. Very large files exceed the limit and get rejected before encryption is even attempted.

Practices sending large imaging files, video, or full record sets should use a HIPAA-compliant file transfer service instead of email attachments. The email carries the link. The file transfer service handles the payload.

Encryption Alone Does Not Equal HIPAA Compliance

HIPAA compliance includes administrative, physical, and technical safeguards. Encryption is one of the technical safeguards. The covered entity is responsible for the full set.

The covered entity needs a signed business associate agreement with the email provider, access logging, workforce training, an incident response plan, and configuration that enforces encryption on PHI. Microsoft 365 and Google Workspace include a BAA as part of the standard business terms.

Practices that outsource the full mail security posture use a HIPAA email service that includes the BAA, encryption, access logs, and audit trails in a single plan. Mailhippo is one option for practices that want a HIPAA-compliant secure email service that works with an existing Gmail or Outlook account without switching providers.

The choice between running encryption inside Microsoft 365 or Google Workspace and using a dedicated service comes down to IT capacity, license cost across all seats, and the sensitivity of the mail volume.

💡Pro Tip: Test the recipient view before rolling out to staff

The sender view is not the recipient view. Send a test encrypted message to your own personal Gmail, Yahoo, and a corporate Outlook address. Walk through each opening path start to finish. If any path takes more than a minute or requires an account, patients will drop off. Front-desk staff who have not seen the recipient view cannot answer basic questions on the phone, and open rates on patient PHI mail crash within the first week.

Practical Setup Checklist for a First-Time Sender

A first-time sender can get an encrypted message out today by picking one path and running through the setup. The choice depends on the mail platform already in use.

  • Confirm the license level of the Microsoft 365 or Google Workspace tenant.
  • Verify that a business associate agreement is in place with the mail provider if PHI is involved.
  • Enable the Encrypt button in Outlook or client-side encryption in Gmail if the license supports it.
  • Test with an external recipient on a different mail platform to see the actual recipient view.
  • Document the sender steps for staff who will send encrypted mail on a routine basis.

The test send matters. The sender view is not the recipient view. A practice sending encrypted PHI to a patient should see the exact browser experience the patient will see before sending real mail.

Practices building the wider HIPAA posture around the encryption method also need to cover the website, intake forms, and patient portals. See the guide on healthcare website security features for the site-side controls that pair with encrypted email.

Common Errors When Encrypting an Email

Several errors show up in the first weeks of a new encrypted email workflow. Most trace back to license mismatch, recipient environment, or a missing configuration step on the tenant.

  • The Encrypt button does not appear in Outlook because the license is Business Basic or Business Standard.
  • The recipient does not receive the notification because a corporate spam filter blocks the outlook.office365.com sender.
  • The S/MIME send fails because the recipient certificate is not in the Outlook contact record.
  • The one-time passcode does not arrive because the recipient inbox filters bulk mail into a folder the recipient does not check.
  • Attachments exceed the 25 megabyte limit and get rejected before encryption is applied.

Each of these errors has a fix. Licensing is a purchase or a switch to a service that bundles encryption. Recipient filters can be addressed by asking the recipient to allow the sender domain. Certificates can be exchanged through a first signed message.

Related reading covers practical steps for common platforms: to encrypt an email, encrypting email in Outlook, email encrypting workflows, and what does encrypting an email do in outlook. Each guide breaks down the sender view for a specific tool.

When a Dedicated Encrypted Email Service Fits Better

A dedicated encrypted email service fits practices that need HIPAA compliance without adding license overhead or IT complexity. The service handles the encryption, the BAA, the access logs, and the recipient portal.

The sender writes mail in the same Gmail or Outlook interface. Outbound mail routes through the service gateway. The recipient gets a portal link or a native decrypt depending on the service configuration.

Mailhippo is a HIPAA-compliant secure email service that 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, without creating a Microsoft or Google account.

Practices building the wider healthcare digital presence often pair encrypted email with a compliant site, intake, and portal setup. A healthcare marketing agency can coordinate the site and communication layer around the encryption service already in place.

Frequently Asked Questions

What is encrypting an email? +

Encrypting an email is the process of converting the message body and attachments into ciphertext so that only an authorized recipient with the correct key can read the content. The encryption can happen at the sending client, at the sending mail server, or at both points. Modern methods include S/MIME, PGP, Microsoft Purview Message Encryption, Google Workspace client-side encryption, and gateway-based encryption used by HIPAA email services. Each method protects the same fundamental thing: the confidentiality of the message contents in transit and at rest.

Does encrypting an email make it secure? +

Encryption protects the message contents from interception and unauthorized reading. It does not protect against a compromised sender account, a compromised recipient account, or social engineering that tricks either party into sharing credentials. Encryption is one control in a layered security model. Practices sending PHI need encryption plus multi-factor authentication, access logging, phishing training, and endpoint protection. Encryption also does not protect a message that a legitimate recipient forwards to an unauthorized party, unless rights management is applied on top of the encryption.

Does encrypting an email encrypt attachments? +

Yes. S/MIME, PGP, Microsoft Purview Message Encryption, and Google Workspace client-side encryption all encrypt attachments along with the message body. The recipient sees a single verification step for both. Do Not Forward rights in Microsoft Purview block download of attachments and display them only in the portal preview. Attachment size limits still apply. Practices sending very large files containing PHI should use a HIPAA-compliant file transfer service instead of email attachments, because the mail server may reject files that exceed the platform limit before encryption is applied.

How do I encrypt an email in Outlook? +

Open a new message in Outlook. Click Options in the ribbon. Click Encrypt and pick Encrypt-Only or Do Not Forward. Encrypt-Only lets the recipient reply, forward, and print. Do Not Forward blocks forward, print, and download. Write the message, add recipients, and click Send. 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 the encrypted content in a browser tab on outlook.office365.com.

How do I encrypt an email in Gmail? +

Gmail on Google Workspace Enterprise Plus and Education Plus supports client-side encryption. The admin enables it in the Google Admin console under Security, Access and data control, Client-side encryption. Users see a lock icon in the compose window that toggles encryption on. Standard Gmail and Workspace Business plans do not have this feature. Those accounts can use confidential mode, which sets an expiration and disables forwarding, or route encrypted mail through a HIPAA email service that works with the existing Gmail account.

What are the benefits of encrypting an email? +

Encryption blocks interception of message contents in transit, protects the content at rest on mail servers, and reduces the impact of a mail server breach because the stolen data is ciphertext. For regulated industries, encryption is a required control under HIPAA, HITECH, GLBA, and similar frameworks. For any business, encryption reduces the risk of an accidental data disclosure when a message is sent to the wrong address or forwarded outside the organization. Recipients also gain confidence that the sender has invested in secure communication.

Is TLS encryption enough for HIPAA compliance? +

TLS encrypts the connection between mail servers but does not encrypt the message at rest inside the recipient inbox. TLS also depends on both sending and receiving servers supporting the same version and cipher suite. Opportunistic TLS falls back to cleartext if the receiving server does not support TLS. The HHS guidance on encryption treats TLS as one acceptable safeguard for transmission but recommends message-level encryption for high-risk PHI. Practices should assume TLS alone is not sufficient and layer message-level encryption on top for regulated content.

Posted on

Encrypting Emails in Outlook

encrypting emails in outlook guide featured image

🔑 Key Takeaways

  • Outlook Business Premium exposes the Encrypt button; lower tiers hide it entirely.
  • S/MIME works from Outlook 2013 up but needs a valid cert for sender and recipient.
  • Outlook on the web shows Encrypt only when Purview Message Encryption is active.
  • Microsoft signs the BAA, but sending PHI in plaintext still counts as a HIPAA breach.
  • Configure a DLP rule so PHI patterns trigger encryption when staff forget to click.

Outlook supports three encryption paths. The Encrypt button, S/MIME certificates, and layered third-party services. Each has a specific plan requirement and a specific recipient experience.

For healthcare organizations and any team handling regulated data, encrypting emails in Outlook means matching the method to the license, the recipient, and the compliance requirement.

This guide covers the setup for Outlook desktop and Outlook on the web across the main Microsoft 365 tiers.

The Encrypt Button Uses Microsoft Purview Message Encryption

The Encrypt button in the Outlook Options ribbon triggers Microsoft Purview Message Encryption. This is the native Microsoft option for sending encrypted mail to recipients outside the sender tenant.

The button appears on Microsoft 365 Business Premium, Enterprise E3, Enterprise E5, and comparable Education plans. It does not appear on Business Basic or Business Standard because those tiers do not include Purview Message Encryption.

If the tenant is on a qualifying plan and the button is missing, an administrator needs to enable Azure Rights Management under the Microsoft 365 Admin Center. Once activated, the Encrypt button appears in Outlook within a few minutes.

According to Microsoft documentation, Purview Message Encryption meets HIPAA transmission requirements when combined with a signed BAA available on qualifying Microsoft 365 tiers.

Encrypt-Only and Do Not Forward Provide Different Levels of Control

Clicking the Encrypt button opens a dropdown with two main options. Encrypt-Only sends the message with encryption in transit and at rest. Do Not Forward adds rights-management controls that block the recipient from forwarding, copying, or printing.

Encrypt-Only is appropriate when the sender trusts the recipient to handle the message responsibly but wants to protect it from network interception and mailbox compromise. The recipient can forward it to others once they read it, in encrypted form.

Do Not Forward is stronger when the sender wants to limit downstream distribution. The rights-management layer prevents the recipient from forwarding or exporting the content. Screenshots still work, but the automated actions are blocked.

For HIPAA and regulated content, Encrypt-Only meets the transmission standard. Do Not Forward adds a layer of downstream control that is optional under HIPAA but often used as a matter of practice policy.

encrypting emails in outlook in article illustration one

Encrypt Button Step-by-Step in Outlook Desktop

Open Outlook desktop and click New Email. Fill in the recipient, subject, and body as usual. Click the Options tab in the ribbon.

Click Encrypt in the ribbon. A dropdown appears with Encrypt-Only and Do Not Forward. Select the option that matches the message. A banner appears at the top of the message confirming the selected encryption.

Click Send. Outlook encrypts the message through Microsoft Purview and delivers it to the recipient. Internal recipients on the same tenant see it inline in Outlook. External recipients receive a portal link.

  • The banner in the compose window confirms which encryption level is applied.
  • To remove encryption before sending, click Encrypt again and select the same option to toggle off.
  • The Sent folder shows a lock icon on the encrypted message.

Encrypt Button Step-by-Step in Outlook on the Web

Open Outlook on the web and click New Message. Fill in the recipient, subject, and body. Click the three-dot overflow menu at the top of the compose window.

Select Encrypt from the menu. A banner appears at the top of the message with the selected encryption level. The default is Encrypt-Only. To switch to Do Not Forward, click Change Permissions in the banner.

Click Send. The message is encrypted through Microsoft Purview and delivered. Internal recipients on the same tenant read it inline. External recipients on Gmail, Yahoo, iCloud, or other providers receive a link to the Microsoft portal.

If the Encrypt option does not appear in the overflow menu, the tenant has not enabled Purview Message Encryption. An administrator needs to activate it in the Microsoft 365 Admin Center before the option becomes visible.

Example

A cosmetic surgery office on Microsoft 365 Business Standard needs to send consent forms and pre-op instructions to patients. Business Standard does not include the Encrypt button, and upgrading eight staff to Business Premium would add $76 per user annually. Instead the office keeps Business Standard at $12.50 per user and adds a HIPAA-compliant portal service at $9 per user monthly. Total savings compared to a full Premium upgrade lands near $600 per year, and patients open messages with one click instead of a Microsoft portal sign-in.

S/MIME Setup for Outlook Desktop

S/MIME is the certificate-based encryption standard built into Outlook. It provides end-to-end encryption between sender and recipient without a portal step. Both parties need certificates from a trusted authority.

Get a certificate from DigiCert, Sectigo, IdenTrust, or another trusted authority. The authority delivers a .pfx file containing the public certificate and private key. Import the file into the Windows certificate store on Windows or the macOS keychain on Mac.

Open Outlook and navigate to File, Options, Trust Center, Trust Center Settings, Email Security. Click Settings under Encrypted email. In the dialog, select the certificate for signing and encryption from the dropdown. Click OK and restart Outlook.

When composing a message, click Options, then click Sign and Encrypt icons in the More Options section. If the recipient has a valid S/MIME certificate that Outlook can verify, the encrypted send works. If not, Outlook prompts to send unencrypted.

encrypting emails in outlook in article illustration two

HIPAA Coverage in Microsoft 365 Has Boundaries

Microsoft signs a business associate agreement covering Microsoft 365 core services, including Exchange Online, when the tenant has accepted the BAA under the Microsoft Trust Center. The BAA covers the transmission and storage of PHI in Outlook.

The sender remains responsible for enabling encryption on every PHI transmission. The BAA does not automatically encrypt every message. Sending a PHI message without clicking Encrypt still results in transmission over TLS or plaintext, which does not meet the HIPAA transmission standard for regulated data.

For consistent enforcement, administrators can configure a data loss prevention rule under the Microsoft 365 Purview compliance portal that scans outbound messages for regulated patterns and applies encryption automatically. This is not enabled out of the box.

For practices on Business Basic or Business Standard without Purview Message Encryption, the practical path is a layered encrypted email service. This pairs with broader work covered in healthcare website security features.

Recipient Experience Depends on Their Mail Provider

Recipients on the same Microsoft 365 tenant see the message inline in Outlook or Outlook on the web. They do not click a portal link. The message opens like any other, with a lock icon indicating encryption.

Gmail users get a notification email with a link. They click the link and either sign in with their Google account or request a one-time passcode by email. They read the message in a Microsoft portal in their browser.

Yahoo, iCloud, AOL, and other recipients receive a one-time passcode by email and view the message in the Microsoft portal. They cannot sign in with their mail provider because those providers do not federate with Microsoft identity services.

Test the workflow with a known recipient before relying on it for time-sensitive delivery. Some corporate mail gateways strip the notification link or block the Microsoft portal domain. Testing surfaces those issues before the first real send.

💡Pro Tip: Configure DLP Rules to Enforce Automatic Encryption

Manual Encrypt-button use fails when staff forget on a sensitive message. The single most common HIPAA breach cause is a sender forgetting to click Encrypt on a PHI message. Configure a data loss prevention rule in the Microsoft 365 Purview compliance portal that scans outbound messages for patterns like Social Security numbers or medical record numbers and applies Purview Message Encryption automatically. Human error drops out of the workflow.

Third-Party Services Close the Gap on Lower Microsoft 365 Tiers

Microsoft 365 Business Basic and Business Standard tenants do not have the Encrypt button. Upgrading every seat to Business Premium for the encryption feature is often more expensive than adding a purpose-built encrypted email service.

Mailhippo integrates with any Outlook or Microsoft 365 account through SMTP relay or a plug-in. The sender continues to write and send from Outlook. The service intercepts the message, encrypts it, and delivers over TLS or through a portal fallback.

The service includes a signed BAA in the base plan and logs every message access. The recipient experience is a single click and passcode. No key management, no software install for the recipient.

For healthcare organizations coordinating email with website work, this pairs with services covered in healthcare marketing.

Verify Encryption on Every Sensitive Send

Before hitting Send on a regulated message, verify the encryption is active. In Outlook desktop, the banner at the top of the compose window shows Encrypt-Only or Do Not Forward. In Outlook on the web, the same banner appears.

For S/MIME, the Sign and Encrypt buttons in the Options ribbon show as active. The message icon in the Sent folder shows a lock. If the message went out without those indicators, encryption did not apply.

Microsoft 365 administrators can audit encryption status in the Purview compliance portal under Message Trace. This shows every outbound message with its encryption status, useful for HIPAA risk assessments and periodic compliance reviews.

According to HIPAA Journal, the most common documented compliance failure is a sender forgetting to enable encryption on a PHI message. Verification per send is the single most effective preventive control.

Choose the Outlook Path Based on Plan and Recipient

Match the encryption approach to the Microsoft 365 tier and the target recipient. Business Premium and above have the Encrypt button for a Microsoft-native experience. Business Basic and Business Standard need either an upgrade or a layered service.

  • Business Premium or higher, external recipients: Encrypt button with Purview Message Encryption.
  • Any tier, internal certified users: S/MIME with corporate certificates.
  • Business Basic or Business Standard, external recipients: layered HIPAA-compliant service.
  • Any tier, mixed compliance needs, patients as recipients: layered service with portal fallback.

For deeper coverage on related methods, see the sibling guides encrypting email in Outlook, encrypting an email, and how to open encrypted emails in Outlook.

The final point is that Outlook makes encryption easy on the right plan and unavailable on the wrong plan. Match the tool to the tier, and verify every sensitive send.

Frequently Asked Questions

Which Outlook and Microsoft 365 plans include the Encrypt button? +

The Encrypt button appears on Microsoft 365 Business Premium, Enterprise E3, Enterprise E5, and comparable Education plans. It does not appear on Business Basic or Business Standard. If the tenant is on a qualifying plan and the button is still missing, an administrator likely needs to enable Azure Rights Management under the Microsoft 365 Admin Center. Once activated, the Encrypt button appears in Outlook desktop under Options and in Outlook on the web under the compose window overflow menu within a few minutes.

What is the difference between Encrypt-Only and Do Not Forward in Outlook? +

Encrypt-Only encrypts the message in transit and at rest, so unauthorized viewers cannot read it, but the recipient can forward, copy, print, and download normally once they open it. Do Not Forward adds Microsoft Purview rights-management controls that block forwarding, printing, and copying by the recipient. Do Not Forward is the stronger control when the sender wants to limit downstream distribution. Both options require Microsoft Purview Message Encryption enabled at the tenant level to appear in the Outlook compose menu.

How do I install an S/MIME certificate in Outlook desktop? +

Get an S/MIME certificate from a trusted authority such as DigiCert, Sectigo, or IdenTrust. The authority delivers the certificate as a .pfx file with a private key. Double-click the .pfx file on Windows, or import it into Keychain Access on macOS. Open Outlook, navigate to File, Options, Trust Center, Trust Center Settings, Email Security, and click Settings under Encrypted email. Select the certificate for signing and encryption. Save and restart Outlook.

Does Microsoft 365 Business Basic support S/MIME? +

Microsoft 365 Business Basic is a web-only plan without the desktop Outlook client, and S/MIME on Outlook on the web has limited support. The Encrypt button on Business Basic is not available because Purview Message Encryption requires Business Premium or higher. Practices on Business Basic that need encryption typically use a browser-based encrypted email service or upgrade one or more seats to Business Premium. Layering a HIPAA-compliant service is often the lower-cost path for small practices.

Can I send an encrypted Outlook message to a Gmail user? +

Yes. Purview Message Encryption delivers the message through a Microsoft portal. The Gmail user receives a notification email with a link. They click the link and either sign in with their Google account or request a one-time passcode by email. They read the message in the Microsoft portal in their browser. The message stays encrypted at Microsoft servers and is not copied into the recipient Gmail account in plaintext. Portal-based reads leave the message on Microsoft infrastructure.

Does Outlook automatically encrypt sensitive messages? +

Not by default. Outlook does not scan message content and apply encryption automatically. An administrator can build data loss prevention rules in the Microsoft 365 Purview compliance portal that scan outbound messages for patterns like Social Security numbers or medical record numbers and enforce encryption on match. This is not enabled out of the box. It requires configuration of a DLP policy tied to a Purview Message Encryption action.

What happens if I forget to click Encrypt on a sensitive message? +

The message sends over TLS to the recipient server if the recipient supports TLS, or in plaintext if it does not. Neither of these paths meets HIPAA transmission standards for PHI. If the message contained regulated content, the sender may need to report a potential incident, depending on the organization breach response policy. This is one of the reasons many healthcare organizations layer an encrypted email service that enforces encryption regardless of user action.

Posted on

How to Send Encrypted Emails Across Outlook Gmail and Yahoo

how to send encrypted emails guide featured image

🔑 Key Takeaways

  • Outlook’s Encrypt button needs Microsoft 365 Business Premium; lower tiers get no encryption.
  • Gmail client-side encryption is Enterprise Plus only; Confidential Mode fails HIPAA standards.
  • Yahoo has no native message encryption and no BAA, so PHI belongs on a different platform.
  • S/MIME, PGP, Purview, and HIPAA services encrypt attachments as part of the encrypted message.
  • Password-protected ZIPs guard the file but leave PHI in the body exposed and fail HIPAA rules.

Sending an encrypted email means applying an encryption method before the message leaves the sender. The specific steps vary by platform. Outlook, Gmail, Yahoo, and GoDaddy each handle encryption differently, and each has gaps that a dedicated service can fill.

This guide walks through the sender steps for each platform, covers attachments and password-protected files, and identifies where a HIPAA-focused encrypted email service fits the workflow.

The underlying protection is the same across methods. Content is unreadable to anyone without the correct key or credential. The differences are in setup, license, and recipient experience.

Sending an Encrypted Email in Outlook Uses Purview

The Outlook path starts in the compose ribbon of a new message. Click Options, then Encrypt, and pick a policy. 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.

The tenant must be on Microsoft 365 Business Premium or higher for the Encrypt button to appear. Business Basic and Business Standard do not include the button. Adding it requires an upgrade or a per-seat license add-on.

External recipients see a notification 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. Detailed steps are in the Microsoft support guide for encrypted messages in Outlook.

Sending an Encrypted Email in Gmail Depends on Workspace Plan

Gmail on Google Workspace Enterprise Plus or Education Plus supports client-side encryption. The admin enables it in the Google Admin console under Security, Access and data control, Client-side encryption. Users see a lock icon in the compose window.

The lock icon toggles encryption on for the message. The message content is encrypted in the browser before it reaches Google servers. The keys stay outside Google through a customer-controlled external key service.

Standard Workspace plans and personal Gmail do not support client-side encryption. Confidential mode is available on every Gmail account. Confidential mode sets an expiration date and disables forward, copy, print, and download. It does not encrypt content in a way that meets HIPAA transmission requirements.

Practices on standard Workspace plans that need encryption for HIPAA route outbound mail through a HIPAA email service. The Gmail interface stays the same. The encryption applies at the service layer.

how to send encrypted emails in article illustration one

Sending an Encrypted Email in Yahoo Requires a Workaround

Yahoo Mail does not offer native message-level encryption on standard consumer or business accounts. There is no Encrypt button in the Yahoo compose window equivalent to the Outlook or Gmail options.

Yahoo users send encrypted mail through one of three workarounds:

  • Install a browser extension such as Mailvelope that adds PGP support to the Yahoo web interface.
  • Attach a password-protected ZIP file to the message and share the password through a separate channel.
  • Route outbound mail through a HIPAA email service that adds encryption at the outbound gateway.

Yahoo does not sign a business associate agreement for consumer accounts. The platform is not appropriate for PHI regardless of the encryption workaround. Practices sending regulated content should move to a compliant mail platform rather than relying on Yahoo with encryption bolted on.

Sending an Encrypted Email From GoDaddy Requires a Third-Party Layer

GoDaddy Professional Email is hosted mail on the godaddy.com or a custom domain. The service does not offer native message-level encryption in the web interface or in the standard IMAP client access.

Practices using GoDaddy for hosted email send encrypted mail through one of three options. Add a third-party S/MIME certificate to Outlook or Apple Mail connected to the GoDaddy account. Use a browser extension that supports PGP or S/MIME. Route outbound mail through a HIPAA email service.

GoDaddy signs a business associate agreement for some hosted email plans through a separate compliance add-on. The BAA covers storage of PHI on GoDaddy infrastructure. It does not cover the encryption of outbound transmission automatically.

Practices sending PHI from GoDaddy typically pair the account with a dedicated encryption service. The GoDaddy account handles inbound receipt and stored mail. The encryption service handles the outbound HIPAA-required protection.

Example

A dental practice on Microsoft 365 Business Basic wants to send X-ray attachments to a referring oral surgeon on personal Gmail. The Business Basic plan does not include the Encrypt button. The office manager tries a password-protected ZIP, but the message body still references the patient by full name and treatment code. Instead, the practice routes outbound mail through a HIPAA email service at $10 per mailbox per month, which encrypts every message and delivers a one-click portal link the surgeon opens on any device.

Sending Encrypted Files Uses the Same Message Encryption Path

Encrypted files travel as message attachments protected by the same encryption applied to the message body. S/MIME, PGP, Microsoft Purview, Google client-side encryption, and HIPAA email services all treat the attachment as part of the encrypted message.

The recipient sees one verification step. After the sign-in or key decryption, both the body and the attachments become readable. Do Not Forward rights in Microsoft Purview show attachments in the portal preview and block download.

Attachment size limits apply. Outlook caps standard attachments at 20 megabytes. Gmail caps at 25 megabytes. Larger files exceed the limit before encryption is even attempted. The message bounces with a size error.

For large files, use a HIPAA-compliant file transfer service and put the link in the message body. The email delivers the link. The file service handles the payload with its own encryption at rest and in transit.

how to send encrypted emails in article illustration two

Sending a Password-Protected File as a Workaround

Sending a password-protected file through email is a common workaround for accounts without full encryption. The sender ZIP-encrypts the file with a password and attaches the ZIP to the message.

Tools that support AES-256 encryption include 7-Zip, WinRAR, and the built-in Archive Utility on macOS with a strong password. The encrypted ZIP is unreadable without the password. This protects the file at rest and in transit.

The password must go through a separate channel. Phone call, text message, or a secure messaging app all work. Never include the password in the same email as the encrypted attachment. That defeats the encryption.

Password-protected attachments do not meet the HIPAA requirement for encrypted transmission of PHI when the message body itself contains identifying information. The workaround protects the file but leaves the body exposed. Dedicated encryption remains the required control for regulated content.

Sender Steps Compared Across Platforms

The sender view differs across platforms. The table below summarizes the steps and license requirements for each.

Platform Sender Step License Required Recipient Experience
Outlook Options, Encrypt, pick policy Business Premium or higher Portal sign-in or passcode
Gmail (Workspace) Lock icon in compose Enterprise Plus or Education Plus Portal sign-in with key service
Yahoo Browser extension or gateway None native Depends on workaround
GoDaddy Third-party layer None native Depends on layer added
HIPAA Email Service Send Secure button or automatic Service subscription One-click portal, no account creation

The service approach is the shortest path for accounts without built-in encryption. It also fits practices on Business Premium or Enterprise Plus that want a simpler recipient experience for patient communication.

💡Pro Tip: Test the recipient view before switching platforms

The sender workflow tells you nothing about what the patient sees. Before committing to Purview, S/MIME, or a HIPAA service, send one test message to a personal Gmail and one to a personal Yahoo. Time the steps from notification to reading the body. If the recipient path takes more than 30 seconds or asks for account creation, patient response rates will drop.

Sending Encrypted Mail to Recipients With No Encryption Setup

The most common friction point in sending encrypted mail is the recipient. A patient with a personal Gmail account does not have S/MIME certificates. A small business partner may not know how to use PGP.

Portal-based encryption solves this. Microsoft Purview and most HIPAA email services deliver the recipient a notification with a link. The recipient clicks the link, authenticates with a sign-in or one-time passcode, and reads the message in a browser.

The recipient does not install anything. The recipient does not need a specific mail client. The recipient does not need to hold any cryptographic material. The portal experience matches how patients already use online banking or telehealth portals.

Practices sending to patients almost always want the portal experience for this reason. The one-click access matches patient tech literacy across a broad population.

HIPAA Applies to Encryption Choices for Covered Entities

Covered entities and business associates operate under the HIPAA Security Rule. Encryption is one required technical safeguard. The HHS Security Rule guidance treats encryption as an addressable specification.

Addressable does not mean optional. The covered entity must either implement encryption or document why an alternative safeguard is reasonable. Most compliance reviews expect encryption on any transmission of PHI outside the internal network.

The sending platform must also have a signed business associate agreement in place with the covered entity. Microsoft 365 and Google Workspace include a BAA as part of the standard business terms. Personal Gmail and consumer Yahoo do not.

Practices building the wider HIPAA posture around encrypted mail also need to cover the website and patient portal. See the guide on healthcare website security features for the site-side controls.

Dedicated HIPAA Email Services Simplify the Sender Workflow

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.

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, without creating a Microsoft or Google account.

Related reading covers the platform-specific how-tos: how to send varracuda encrypted email, how to send encrypted email, how to send an encrypted email, how to send encrypted email using gmail, send encrypted email, and how to send encrypted email via comcast.

Practices coordinating encrypted email with a wider healthcare digital strategy often pair the mail service with a compliant site and portal setup. A healthcare marketing agency handles the marketing overlay on top of the compliance stack.

Frequently Asked Questions

How do I send an encrypted email in Outlook? +

Open a new message in Outlook. Click Options in the ribbon. Click Encrypt and pick either Encrypt-Only or Do Not Forward. Encrypt-Only lets the recipient reply, forward, and print. Do Not Forward blocks forward, print, and download. Write the message, add recipients, and click Send. The tenant must be on Microsoft 365 Business Premium or higher for the Encrypt button to appear. Microsoft Purview handles the delivery and recipient authentication through a browser portal for external recipients.

How do I send an encrypted email in Gmail? +

Gmail on Google Workspace Enterprise Plus or Education Plus supports client-side encryption. The admin enables it in the Google Admin console under Security, Access and data control, Client-side encryption. Users see a lock icon in the compose window that toggles encryption on. Standard Workspace plans and personal Gmail do not support client-side encryption. Those accounts can route outbound mail through a HIPAA email service that adds encryption at the gateway, or use confidential mode for non-regulated content that needs expiration and forwarding controls.

How do I send an encrypted email through Yahoo? +

Yahoo Mail does not offer native message-level encryption on standard accounts. To send an encrypted message from a Yahoo address, use a browser extension that adds S/MIME or PGP support, attach a password-protected file with the password shared through a separate channel, or route outbound mail through a HIPAA email service. Yahoo does not sign a business associate agreement for consumer accounts, so the platform is not appropriate for PHI. Practices sending regulated content move to Google Workspace, Microsoft 365, or a dedicated encryption service.

How do I send encrypted files through email? +

Attach the file to a message and send using an encryption method that covers both the body and the attachments. S/MIME, PGP, Microsoft Purview Message Encryption, Google client-side encryption, and HIPAA email services all encrypt attachments as part of the message. The recipient opens attachments after the same authentication step used for the message body. Attachment size limits on Outlook and Gmail typically cap at 25 megabytes. Larger files should use a HIPAA-compliant file transfer service with a link in the message rather than a direct attachment.

How do I send a password-protected file over email? +

Compress the file into a ZIP archive using a tool that supports AES-256 encryption, such as 7-Zip or WinRAR. Set a strong password during compression. Attach the encrypted ZIP to the message and send. Share the password through a separate channel: phone call, text message, or a secure messaging app. Never include the password in the same email as the attachment. This method protects the file but does not encrypt the message body itself. It is a workaround for accounts without full encryption, not a HIPAA-grade solution.

How do I send an encrypted email from GoDaddy? +

GoDaddy Professional Email does not offer native message-level encryption. Practices using GoDaddy for hosted email send encrypted mail by adding a third-party S/MIME certificate, using a browser extension that supports encryption, or routing outbound mail through a HIPAA email service. GoDaddy does sign a business associate agreement for some hosted email plans, but the BAA covers the storage of PHI on GoDaddy servers rather than the encryption of outbound transmission. Practices sending PHI from GoDaddy typically pair the account with a dedicated encryption service.

Is Microsoft 365 encryption enough for HIPAA? +

Microsoft 365 provides the technical layer of encryption when Purview Message Encryption is enabled. HIPAA compliance also requires a signed business associate agreement, which Microsoft includes as part of the Microsoft 365 BAA terms. The covered entity is still responsible for correct configuration, access logging, workforce training, and an incident response plan. The technical layer is one part of the compliance picture. Practices without dedicated IT often supplement Microsoft 365 with a HIPAA email service that simplifies the recipient portal experience and audit trail.

Posted on

HIPAA Compliant Email Marketing Rules Platforms and Setup

hipaa compliant email marketing guide featured image

🔑 Key Takeaways

  • HIPAA marketing needs a signed BAA, encryption in transit and at rest, and PHI-free bodies.
  • Mailchimp, Constant Contact, and standard HubSpot exclude healthcare and refuse to sign a BAA.
  • The real risk is content: any subject line or merge field that names a condition creates PHI.
  • Keep marketing lists and clinical lists separate at the database level with role-based access.
  • Run broadcasts on a BAA marketing tool; run individual PHI email on a HIPAA email service.

HIPAA compliant email marketing means running patient outreach through a platform that signs a business associate agreement, encrypts data in transit and at rest, and applies content controls that keep protected health information out of the message body.

Most mainstream marketing platforms do not sign a BAA. This guide covers the platforms that do, the content boundaries that keep PHI out of broadcast mail, and how a HIPAA secure email service covers the individual patient communication side.

The compliance picture has three parts: platform, content, and consent. All three matter. A compliant platform running unrestricted content is still a violation.

Three Requirements Define HIPAA Marketing Compliance

Compliant email marketing has three requirements. A signed business associate agreement with the platform vendor. Encryption of message content and list data in transit and at rest. Content controls that exclude PHI from broadcast material.

The BAA covers the platform’s legal obligation to protect any PHI it processes on behalf of the covered entity. Without a BAA, the platform is not authorized to handle PHI at all.

Encryption covers the technical safeguard. The list of subscribers, the message templates, and the outbound content should all be encrypted at rest and in transit. TLS is the baseline for delivery. At-rest encryption on the platform storage matters for the list itself.

Content controls cover the human decision on what to include. Even a compliant platform cannot make PHI-in-broadcast safe. Practices set editorial rules and train marketing staff on the distinction between general health content and PHI.

Mainstream Marketing Platforms Do Not Sign a BAA

Mailchimp, Constant Contact, ActiveCampaign, and standard HubSpot Marketing Hub do not sign a business associate agreement in their base plans. The acceptable use policy on each explicitly excludes handling of protected health information.

Mailchimp’s terms of service state that customers cannot use the service to transmit PHI. Constant Contact’s terms carry the same restriction. ActiveCampaign requires a specific plan tier for the BAA. Standard HubSpot excludes healthcare use.

Practices using any of these platforms for healthcare marketing must keep PHI out of the message body, the subject line, and every personalization field. Content that references a specific condition, treatment, or clinical field creates a violation regardless of the technical protection applied.

The workaround is generic content only. Newsletters about health topics that apply to a wider audience are not PHI. Personal condition messaging belongs in a different channel with a BAA in place.

hipaa compliant email marketing in article illustration one

Platforms That Do Sign a HIPAA BAA

Several platforms offer a HIPAA-signed configuration through an enterprise tier or a healthcare-specific product line. The table below summarizes the current options.

Platform BAA Available Tier Required Fits Best For
HubSpot Yes with healthcare add-on Enterprise Larger practices with existing HubSpot
ActiveCampaign Yes on Enterprise Enterprise Automation-heavy workflows
Salesforce Marketing Cloud Yes with Health Cloud Enterprise Large health systems
Healthcare-focused platforms Yes, standard plans All tiers Small to mid practices
Mailchimp, Constant Contact, standard HubSpot No N/A Generic content only, no PHI

The right platform depends on practice size, existing tooling, and the level of clinical content in outreach. Large systems tend to use HubSpot or Salesforce with the healthcare tier. Smaller practices use healthcare-focused tools that bundle the BAA into the standard plan.

Content Controls Keep PHI Out of Marketing Mail

Content controls are editorial rules for what marketing mail can and cannot reference. The rules cover the subject line, the body copy, the personalization fields, and any linked landing pages.

Recommended patterns include:

  • Subject lines identify the practice, not the patient condition. A subject like “Your Practice Newsletter” is safe. “Your recent diabetes screening” is not.
  • Body copy addresses a wider audience with general health content. Condition-specific detail belongs behind a portal link, not in the message body.
  • Personalization fields use first name only. Clinical fields like diagnosis, medication, or provider name should not appear in merge tags.
  • Linked landing pages that carry clinical detail require patient authentication. Public marketing pages carry no PHI.
  • Images that show clinical procedures use stock or generic photography, not identifiable patient images.

Marketing staff review each broadcast against these patterns before sending. Practices with a formal review process document the review on a checklist attached to the send record.

Example

A three-location pediatric practice runs monthly newsletters through Mailchimp with 4,200 subscribers. The marketing coordinator drafts an autumn asthma awareness email that references "your child's recent inhaler prescription." Because that merge field pulls from the EHR and Mailchimp has no BAA, the send would violate HIPAA. The practice rewrites the copy as general seasonal asthma education with no clinical merge fields, keeps Mailchimp for the newsletter, and routes any prescription-specific outreach through a HIPAA email service tied to the EHR export.

List Hygiene Under HIPAA Is Stricter Than Standard Marketing

List hygiene under HIPAA has stricter rules than standard marketing. The list source matters. The consent capture matters. The access controls matter.

Patients who opted in on an intake form with clear language on marketing use are one category. Patients whose email came in through a clinical touchpoint without a marketing opt-in are another. Mixing the two creates a compliance problem.

Practices maintain separate marketing and clinical email lists. The marketing list has documented consent capture. The clinical list has documented clinical necessity. The two lists live in different systems and have different access controls.

Unsubscribe requests apply to the marketing list only. A patient who unsubscribes from marketing still receives clinical communication such as appointment reminders and lab results. The two channels operate independently.

Consent Capture on the Intake Form

Consent capture on the intake form is the standard method for building a HIPAA-appropriate marketing list. The form includes a specific checkbox for marketing communication with clear language.

Suggested consent language:

I agree to receive marketing communication from [Practice Name] about health topics, practice news, and general wellness content. I understand this is separate from clinical communication about my care, and I can unsubscribe from marketing at any time without affecting my clinical services.

The checkbox is unchecked by default. Patients opt in actively. The consent record ties to the patient record with a timestamp and the form version.

Practices without a compliant intake form should not use the clinical email list for marketing. See the guide on website content strategy for healthcare for the intake and consent side of the digital footprint.

hipaa compliant email marketing in article illustration two

HubSpot Healthcare Add-On Enables Compliant Marketing

HubSpot offers a healthcare add-on through the enterprise tier. The add-on includes the BAA and applies additional data handling controls to the account. Standard HubSpot subscribers do not have this configuration.

The add-on enables sensitive data fields, restricts export of contact data, and applies stricter access logging. The marketing dashboard, the workflows, and the reporting all operate under the enhanced controls.

Practices with an existing HubSpot subscription can request an upgrade to the healthcare configuration. The upgrade is not automatic. It requires a contract addendum and a configuration review by the HubSpot compliance team.

Practices without an existing HubSpot investment may find a healthcare-specific platform simpler. Healthcare-focused tools bundle the BAA into every plan and design the workflows around clinical use cases from the ground up.

Separating Marketing From Individual Patient Communication

The cleanest compliance posture separates marketing from individual patient communication. Two systems, two lists, two sets of controls.

The marketing system handles broadcast newsletters, general health content, and practice announcements. The recipient list is opted-in through the intake form or a subscribe page. Content stays clear of PHI. Delivery uses standard TLS through a BAA-signed platform.

The individual communication system handles one-to-one patient email that references specific care. Appointment confirmations, lab results, treatment plans, and follow-up questions all live here. Delivery uses message-level encryption through a HIPAA email service.

Mailhippo covers the individual communication side. It works with existing Gmail and Outlook accounts, includes the BAA, and delivers encrypted mail to patients through a one-click portal. The marketing side runs through a separate compliant platform.

💡Pro Tip: Split marketing and clinical lists at the database level

Mixing lists is how PHI slips into unencrypted broadcast mail. Store marketing consent in its own table with a timestamp, form version, and unsubscribe status. Query only that table when building broadcast segments. Clinical email addresses stay in the EHR and route through the HIPAA email service. Two databases, two access groups, zero accidental crossovers between the systems.

Automation Requires Extra Care Under HIPAA

Marketing automation adds triggered sends based on patient behavior. Under HIPAA, automation requires extra care because the trigger itself can reference PHI.

An automation that sends a follow-up after a specific diagnosis code is a PHI-driven trigger. An automation that sends a welcome sequence after list opt-in is not. The distinction matters for platform selection and content review.

PHI-driven automations belong in a compliant platform with the BAA in place. Non-PHI automations can run on any marketing platform with content controls to keep PHI out of the body.

Practices reviewing existing automation workflows should map each trigger to the source data and confirm whether the source is PHI. Any PHI-based trigger requires the compliant platform.

Audit Trail and Access Logging on the Marketing List

Access logging on the marketing list is a common gap. Practices often treat the marketing list as a normal contact database without audit controls. Under HIPAA, list access is part of the required access logging.

The log records who accessed the list, when, and what actions they took. Export events, edit events, and send events all belong in the log. Retention of the log follows the practice’s HIPAA retention policy.

Access to the marketing list is limited to marketing staff. Clinical staff do not need access. Cross-department access should require a documented reason and a supervisor approval.

Compliant marketing platforms include access logging as a standard feature. Non-compliant platforms may not. Practices using a non-compliant platform must layer the access log through a separate process, which is difficult in practice.

Building a Compliant Marketing Program From Scratch

A practice building a compliant marketing program from scratch follows a specific sequence. Pick the platform first. Configure the BAA. Set up the list with consent capture. Draft the editorial rules. Train the marketing staff.

The HHS Privacy Rule guidance covers the marketing use of PHI at a policy level. The Security Rule covers the technical safeguards. Together they set the framework for compliant program design.

Related reading covers the platform-specific compliance picture: hipaa compliant email marketing for dentists, hipaa compliant email service, hipaa compliant email, cisco hipaa compliant email, best hipaa compliant email, and free hipaa compliant email.

Practices building the wider healthcare marketing footprint coordinate the compliant marketing platform with a compliant site, portal, and individual communication channel. A healthcare marketing agency can pair the marketing strategy with the compliance stack from the start.

Frequently Asked Questions

What makes email marketing HIPAA compliant? +

Three things: a signed business associate agreement with the marketing platform, encryption of message content in transit and at rest, and content controls that keep protected health information out of the message body. The BAA covers the platform’s legal obligation to protect PHI. Encryption covers the technical safeguard. Content controls cover the human decision on what to include. Missing any one of the three creates a compliance gap. Practices also need list hygiene rules that separate marketing consent from clinical consent and log access to the marketing list.

Is Mailchimp HIPAA compliant? +

Mailchimp does not sign a business associate agreement and its acceptable use policy explicitly excludes handling of protected health information. Practices using Mailchimp for healthcare marketing must keep PHI out of the message body, the subject line, and the personalization fields. Content that references a specific condition, treatment, or clinical field creates a compliance violation even without a BAA. Practices that need patient outreach with clinical detail move to a platform that signs a BAA, such as an enterprise HubSpot healthcare tier or a dedicated healthcare marketing tool.

Is HubSpot HIPAA compliant? +

Standard HubSpot Marketing Hub does not include a business associate agreement. HubSpot offers a healthcare add-on through the enterprise tier that includes the BAA and applies stricter data handling controls. Practices need to enable the add-on and configure the account with healthcare mode before sending any content that touches PHI. Standard HubSpot subscribers using healthcare content without the add-on create a compliance risk regardless of the content review. Confirm the account tier and the healthcare configuration before using HubSpot for any patient-related outreach.

Can I use patient email addresses for marketing? +

Only with documented consent to marketing use. A patient whose email came in through an appointment intake form is not automatically consenting to marketing. Practices need a separate opt-in for marketing communication, either as a checkbox on the intake form with clear language or as a separate subscribe form. The consent record must be stored and accessible on request. Practices should also maintain a documented unsubscribe process. Sending marketing to a patient who only consented to clinical communication is a compliance violation and a privacy concern.

Can I include health information in a marketing email? +

General health education content that applies to a wider audience is not PHI and can appear in marketing content. Condition-specific content, treatment recommendations, or personalization fields that pull from clinical records create PHI and belong in a HIPAA-compliant individual communication channel. The line is whether the content identifies a specific patient’s health status. A newsletter about seasonal allergies is not PHI. A message that starts with “your recent test results” is PHI. Practices set editorial rules and train marketing staff on the distinction.

Do I need encryption for marketing emails? +

Broadcast marketing content that contains no PHI can travel under standard TLS without message-level encryption. The compliance requirement kicks in when the content or the personalization fields reference clinical information. A HIPAA-compliant marketing platform should still encrypt list data at rest and encrypt access to the marketing dashboard. Encryption of the outbound message body matters when the content includes anything that could identify a patient’s health status. Practices without a signed BAA on the marketing platform should keep all content generic and add PHI only to the individual encrypted channel.

What is the difference between marketing email and individual patient email? +

Marketing email is broadcast content to a list of subscribers, typically newsletters, promotions, and general education. Individual patient email is one-to-one communication that references a specific patient’s care, such as appointment confirmations, lab results, and treatment plans. The two channels have different compliance requirements. Marketing runs through a platform with a BAA and stays clear of PHI in content. Individual patient email requires encryption and typically runs through a HIPAA email service or a patient portal. Practices separate the two systems rather than trying to use one for both.

Posted on

Zixcorp Email Encryption Guide with Pricing and Review Notes

zixcorp email encryption guide featured image

🔑 Key Takeaways

  • Zixcorp (now OpenText) scans outbound mail and encrypts policy matches at the domain level.
  • Public data pegs Zix at $30 to $80 per user annually with a 25-seat floor for small buyers.
  • The engine ships 100-plus filters covering HIPAA, PCI-DSS, GLBA, and FERPA out of the box.
  • ZixDirectory delivers transparent end-to-end mail when both domains sit inside the network.
  • Reviewers praise enforcement but flag console complexity and steep small-scale total cost.

Zixcorp email encryption is one of the longest-running policy-based encryption platforms in regulated industries. The company was acquired by OpenText in 2022, but the product line still ships under the Zix brand and the ZixPort portal remains the recipient-facing experience.

This guide covers how zixcorp email encryption works, what it costs, and where it fits in the market. Sections address pricing, policy configuration, review sentiment, and comparison to Microsoft-native and inbox-native alternatives.

The material is aimed at IT decision makers evaluating Zix for a healthcare, financial services, or legal practice. Every section reflects vendor documentation, procurement data, and reviewer sentiment from Gartner Peer Insights, G2, and TrustRadius.

How Zixcorp Email Encryption Works Under the Hood

Zixcorp email encryption sits between the sender’s mail server and the outbound internet as a scanning gateway. Every outbound message passes through the gateway. The scanner evaluates the message headers, body, and attachments against active policy filters.

Matches trigger encryption. The gateway rewrites the message as a short notification and stores the original inside the ZixPort portal. Non-matching messages pass through unencrypted. The design keeps regulated content protected without slowing down routine internal communication.

When both sender and recipient domains are members of ZixDirectory, the shared directory of encrypted-mail participants, the flow changes. The message is transmitted encrypted end-to-end with no portal step, and the recipient sees a normal-looking email in their regular inbox with a Zix Secure banner.

That directory-based transparent delivery is unique to Zix among mainstream encryption products and drives adoption in verticals where two large organizations exchange regulated content frequently. Healthcare networks that share PHI across Zix-using systems benefit most from that path.

Zixcorp Email Encryption Pricing Tiers

OpenText does not publish list pricing for Zix on the product page. All quotes go through the sales team. Third-party procurement data provides a working estimate for planning purposes.

The typical pricing structure has three tiers. The base tier covers policy-based encryption and portal delivery. The middle tier adds data loss prevention and message archiving. The top tier adds inbound threat protection, brand impersonation defense, and advanced reporting.

Tier Estimated annual per-user Included
Base encryption $30 to $50 Policy scanning, ZixPort, ZixDirectory
Encryption plus DLP $50 to $75 Base plus DLP filters, archiving
Full stack $75 to $120 All above plus inbound protection, reporting

Volume discounts apply above 500 seats. Minimum-seat pricing (usually 25 or 50 seats) means small practices pay the full minimum even for smaller user counts. That floor is a common reason small healthcare offices look at alternatives.

zixcorp email encryption in article illustration one

Policy Filter Configuration in the Zix Admin Console

The Zix policy engine ships with over 100 pre-built filters aligned to major regulations. HIPAA covers medical record numbers, ICD-10 codes, and provider identifiers. PCI-DSS covers credit card patterns. GLBA covers financial account numbers. FERPA covers student records.

Administrators enable filters through the admin console with checkboxes and adjust sensitivity thresholds. A high-sensitivity filter triggers on partial matches, catching more content but generating more false positives. A low-sensitivity filter triggers only on confirmed patterns.

  • HIPAA filters: MRN patterns, ICD-10 codes, NPI numbers, prescription language
  • PCI-DSS filters: 15 and 16-digit card number patterns, CVV proximity
  • GLBA filters: account number formats, SSN patterns, tax ID patterns
  • Custom filters: administrator-defined regular expressions for organization-specific content

Tuning filters is the most time-intensive part of a Zix deployment. Initial rollouts typically require 30 to 90 days of adjustment as administrators identify false-positive patterns specific to their workflow. Vendor professional services help accelerate that process at additional cost.

ZixPort Recipient Experience and Friction

External recipients (those outside ZixDirectory) receive a notification email with a link when a Zix-encrypted message arrives. Clicking the link opens ZixPort in a browser tab. First-time recipients create a portal account with a password.

The portal displays the message once the recipient signs in. Attachments can be downloaded. Replies are composed inside the portal and stay encrypted end-to-end within the Zix system. The design mirrors other portal-based encryption products such as Barracuda and Proofpoint.

The friction points are standard for portal encryption. Recipients must remember portal passwords for each organization sending encrypted content. Session tokens expire after 15 to 60 minutes of inactivity. Mobile browser rendering varies by phone model.

Organizations that need portal-free delivery for external recipients often supplement Zix with an inbox-native product for a subset of use cases. Our guide to secure email service covers the trade-off between portal and inbox-native models in more detail.

Example

A 12-provider cardiology group runs Microsoft 365 Business Standard and exchanges patient records daily with a 3,000-bed regional health system that already runs Zix. The clinic considers Zix at roughly $55 per user annually plus a 25-seat minimum. Because the target hospital sits inside ZixDirectory, every outbound record would deliver encrypted end-to-end with no portal friction on the receiving clinicians. The clinic weighs that directory value against a $10-per-user inbox-native service that meets HIPAA but forces the hospital staff through a portal login on every message.

Zix Directory and Transparent Delivery

ZixDirectory is the shared directory of encrypted-mail participants that removes portal friction between two Zix-using organizations. When both sender and recipient domains are in the directory, the message is transmitted encrypted end-to-end and arrives in the recipient’s regular inbox.

The recipient sees a decrypted message with a Zix Secure header banner. No portal login is required. The experience mimics regular email except for the visible security marker.

The directory is one of the strongest Zix differentiators in healthcare because many large hospital systems, insurance carriers, and pharmacy chains use Zix. When PHI moves between two directory members, the workflow is faster than any portal-based alternative.

The value scales with directory overlap. An organization whose external contacts are also Zix customers gets substantial friction reduction. An organization whose external contacts are mostly non-Zix falls back to the portal for most messages.

zixcorp email encryption in article illustration two

Zixcorp Email Encryption Review Notes from Peer Sources

Reviews aggregated from Gartner Peer Insights, G2, and TrustRadius cluster around consistent themes. Positive review scores focus on enforcement reliability, filter accuracy after tuning, and the ZixDirectory shared-directory feature.

Negative review scores focus on admin console usability, the professional services requirement for optimal setup, and total cost of ownership at smaller seat counts. Several reviewers describe the interface as functional but visually dated, particularly in the policy filter management screens.

Deliverability and portal uptime rarely draw complaints, which suggests the operational quality is high even where the admin experience lags. Support response times score in the middle of the pack. Enterprise customers report faster response than mid-market customers, which tracks with account tier structure.

Reviewer sentiment on the OpenText acquisition is mixed. Some reviewers report improved integration with other OpenText products. Others report a shift in support experience post-acquisition that they attribute to organizational restructuring.

Zixcorp Encryption for HIPAA Compliance

Zixcorp email encryption is used across healthcare providers, payers, and business associates as the primary HIPAA-compliant email channel. The policy engine covers the standard HIPAA patterns and enforcement happens at the gateway rather than the mailbox.

OpenText (as the Zix parent) provides a Business Associate Agreement covering encryption and portal storage. The BAA scope includes ZixPort message retention, ZixDirectory transmission, and the underlying infrastructure. HHS publishes BAA sample provisions that outline the expected coverage areas.

Retention windows for ZixPort are configurable at the domain level. Common defaults are 30, 60, and 90 days. Healthcare organizations subject to state-level breach notification laws may need longer retention to support audit and investigation timelines. The vendor supports custom retention up to seven years.

Healthcare organizations rolling out Zix often coordinate with broader digital compliance programs. Our team at Redefine Web has published a companion piece on healthcare website security features that pairs encryption strategy with public-facing web hardening.

💡Pro Tip: Match Zix value to directory overlap first

Before signing a Zix contract, list every external organization the practice exchanges regulated content with and check how many run Zix. ZixDirectory is the single feature that justifies the premium price over cheaper alternatives. High directory overlap means friction-free delivery for most sends. Low overlap means paying enterprise rates while most recipients still hit the ZixPort portal login, which erases the workflow advantage.

Zix Versus Microsoft Purview Message Encryption

Microsoft Purview Message Encryption is bundled with Microsoft 365 E3 and E5 licenses. Organizations already paying for those license tiers get encryption at no incremental cost. That baseline makes the Zix pitch harder for pure Microsoft shops.

The Zix differentiators against Purview are the ZixDirectory shared-directory feature, the depth of pre-built policy filters, and the DLP integration. Purview supports policy rules through Exchange transport rules but lacks a shared directory equivalent to ZixDirectory.

Organizations that already have Microsoft 365 E3 or E5 and whose external contacts are mostly Microsoft-shop themselves often stick with Purview. Organizations with regulated peer networks (health systems, insurance groups) frequently prefer Zix specifically for the directory. The email encryption landscape has consolidated around a few architectural choices, and this pairing represents two of them.

Cost comparison favors Purview inside E3/E5 tenants. Cost comparison shifts if the organization would need to upgrade its Microsoft licenses purely to get Purview, in which case Zix at $30-50 per user often beats a license upgrade.

When Zix Fits and When It Does Not

Zix fits organizations with 100 or more users, heavy regulated content flow, and frequent external exchange with other Zix-using organizations. Healthcare systems, regional banks, and mid-size legal firms are common Zix customers.

Zix does not fit small practices under 25 users well. Minimum-seat pricing pushes per-user cost high and the operational overhead of policy tuning is substantial for a small IT team. Smaller organizations often see better economics from inbox-native encrypted email services such as Mailhippo, which include a BAA in the base plan and require no gateway configuration.

Zix also fits less well for organizations that need message-level end-to-end encryption using recipient-controlled keys. Zix is a gateway model with organization-controlled encryption. Organizations that need cryptographic zero-knowledge encryption should look at S/MIME or PGP-based products instead. Our guide to S/MIME email encryption signature covers that model.

Between those extremes sits the middle market where the decision depends on directory overlap, existing Microsoft licenses, and IT team capacity. That is where evaluators spend the most time weighing Zix against alternatives.

Setup and Deployment Timeline for Zixcorp Email Encryption

A Zix deployment moves through four phases: procurement, gateway configuration, policy tuning, and user rollout. Total timeline for a mid-size healthcare organization runs 30 to 90 days from contract signature to full production.

Procurement takes one to three weeks depending on legal review of the BAA and master service agreement. Gateway configuration is faster, usually one to two weeks including MX record changes, TLS certificate provisioning, and integration with Microsoft 365 or Google Workspace.

Policy tuning is the longest phase. Administrators enable filters, monitor the message stream, and adjust sensitivity as false positives appear. NIST publishes guidance in Special Publication 800-177 on trustworthy email that covers the general principles applied during tuning. Vendor professional services can compress this phase but add cost.

User rollout is typically staged. IT teams enable policy enforcement for a pilot group of 20 to 50 users, monitor for two weeks, then expand to the full user base. That approach catches workflow issues before they hit the whole organization. For a broader view of the email encryption service category, our companion articles compare Zix to Cisco Secure Email Encryption Service and other secure email encryption service options.

Frequently Asked Questions

What does Zixcorp email encryption cost per user? +

Public pricing is not listed on the OpenText site. Third-party data from procurement platforms and resellers suggests the standard encryption tier runs $30 to $80 per user annually, depending on volume. Enterprises above 500 seats often negotiate below $30. Small practices under 25 seats often see quotes at or above $80 because minimum-seat pricing applies. Add-ons for archiving, DLP, and inbound protection are priced separately. Direct sales contact is required for a firm quote tied to the exact seat count and add-on mix.

How does Zixcorp email encryption compare to Microsoft Purview Message Encryption? +

Purview Message Encryption is bundled with Microsoft 365 E3 and E5 licenses, so organizations already on those plans pay no incremental fee. Zix provides more granular policy filters and a shared directory that eliminates portal friction between two Zix-using organizations. Purview lacks that shared-directory benefit outside of native TLS. The right choice depends on whether the license is already paid for and whether frequent recipients also run Zix. Healthcare networks with heavy peer-to-peer PHI exchange often prefer Zix for the directory alone.

Does Zixcorp email encryption include a BAA for HIPAA? +

Yes. Zix, as an OpenText company, offers a Business Associate Agreement covering the encryption and portal storage services. Healthcare organizations should confirm the BAA is signed and in force before sending PHI through the platform. The BAA covers the message content stored in ZixPort during retention windows and the transit path between sender, portal, and recipient. Retention windows are configurable at the domain level, with 30, 60, and 90 days as common defaults for regulated content.

What is ZixPort, and how do recipients use it? +

ZixPort is the recipient-facing portal where encrypted messages are stored and read. External recipients who receive a Zix-encrypted email get a notification with a link. Clicking the link opens ZixPort in a browser. First-time recipients create a portal account with a password. Returning recipients sign in with the same credentials. The portal displays the message and allows secure replies. The reply stays inside the Zix system and reaches the original sender as a decrypted message in their regular inbox.

How does Zix policy-based encryption differ from user-triggered encryption? +

User-triggered encryption depends on the sender remembering to click an Encrypt button before Send. Policy-based encryption scans every outbound message for regulated content and encrypts matches automatically, regardless of whether the sender remembered. That distinction matters in healthcare where a distracted clinician can miss the manual step. Zix runs primarily as policy-based, with pre-built filters for HIPAA, PCI-DSS, and other regimes. Administrators can also allow user-triggered encryption through subject-line tags for edge cases the filters do not catch.

Is Zixcorp email encryption a good fit for a small medical practice? +

For practices under 25 users, Zix is often more platform than the workload requires and pricing tends to be steep. The policy engine and directory value scale with volume. Small practices frequently get equivalent HIPAA protection from inbox-native encrypted email services with lower per-user cost and simpler setup. Practices above 100 seats or that exchange PHI heavily with other Zix-using organizations get more value from Zix. The break-even seat count depends on directory overlap and negotiated pricing.

What common issues appear in Zixcorp email encryption reviews? +

The most frequent review complaints center on admin console complexity, the need for vendor support during policy tuning, and total cost of ownership at small scale. Reviewers on Gartner Peer Insights and G2 also cite occasional false positives in the policy filters that require adjustment. Positive reviews focus on enforcement reliability, the ZixDirectory shared-directory feature, and mature support for regulated content patterns. Reviewers rarely complain about message deliverability or portal uptime, which are consistently rated well across sources.

Posted on

How to Email Encrypted Documents in Gmail, Outlook, and Apple Mail

how to email encrypted guide featured image

🔑 Key Takeaways

  • Outlook 365 Business Premium sends encrypted mail in three clicks: Options, Encrypt, pick policy.
  • Gmail S/MIME rides on Enterprise and Education tiers; Business Standard skips the lock icon.
  • Apple Mail S/MIME works once the certificate lands in Keychain; MDM pushes it to iPhones fast.
  • Encrypted attachments need their own layer if the mail client does not wrap them in the envelope.
  • Portal encryption solves the patient certificate problem; test the flow on iOS and Android.

Sending an encrypted email looks simple in a marketing screenshot. In real practice it depends on which mail platform the sender uses, which platform the recipient uses, and whether both sides have the right certificates or the right portal experience.

This guide covers the three main paths. Native encryption in Outlook, Gmail, and Apple Mail. Portal-based gateway services that layer encryption on top of any mailbox. And attachment-level encryption for cases where the message envelope does not carry the protection. A HIPAA-ready encrypted email service covers the second path in one plan.

The goal is a workflow the practice staff will actually use. Encryption that requires ten steps loses the race against the encryption that requires two.

Outlook 365 Business Premium sends encrypted email in three clicks

Open a new message in Outlook. Click Options in the ribbon. Click Encrypt. A dropdown appears with policies like Do Not Forward, Encrypt-Only, and Confidential.

Pick the policy that matches the sensitivity level of the message. Encrypt-Only is the standard choice for general PHI. Do Not Forward adds a restriction that prevents the recipient from forwarding or copying the message content.

External recipients receive a portal link. They sign in with Microsoft, Google, or a one-time passcode sent to the recipient inbox. Microsoft Purview Message Encryption handles the cryptographic work.

The Encrypt button is missing on free Outlook.com accounts and on Microsoft 365 Business Basic. For those tiers a gateway service adds the encryption layer. For more depth on the how to send encrypted email workflow across Outlook plans, review the linked tutorial.

how to email encrypted in article illustration one

Gmail encrypted send depends on the Google Workspace plan

Google Workspace Enterprise and Education plans support hosted S/MIME. Administrators upload user certificates to the admin console, and the Encrypt lock icon appears in Gmail compose. Users click the lock and pick a level.

Business Standard and Business Plus plans do not include S/MIME. The Encrypt option is grayed out or missing entirely. Confidential mode is available on every plan and adds passcode gating and expiration.

Confidential mode is not end-to-end encryption. Google can still read the message. For HIPAA workflows on plans without S/MIME, add a gateway service that encrypts outbound messages at the mail server layer.

For a step-by-step tutorial on the Gmail send flow, review the linked how to send encrypted email Gmail guide with plan-by-plan screenshots.

Apple Mail supports S/MIME on macOS and iOS with certificate provisioning

Apple Mail is often overlooked, but it supports S/MIME cleanly. Install the user certificate in the macOS keychain or the iOS device profile. The Mail app auto-detects the certificate.

Compose a new message. If a valid public key exists for the recipient, a blue lock icon appears next to the recipient field. Click the lock and the message goes out encrypted.

Mobile device management profiles can push certificates automatically to staff iPhones. This removes the burden of manual certificate installation. Apple documents the profile format at support.apple.com/deployment.

The main limitation is recipient support. If the recipient does not have a valid S/MIME certificate, the message cannot be encrypted with this method. Portal-based services fill that gap.

Example

A six-provider urology practice runs Outlook 365 Business Premium and averages 40 encrypted messages per week to patients and referring physicians. The compliance officer runs a quarterly test at the end of each quarter. She sends a message from her practice mailbox to a personal iCloud address, opens the portal link on an iPhone, and confirms the one-time passcode arrives within 30 seconds. She documents the pass or fail in the HIPAA risk analysis alongside a screenshot of the Received headers showing TLS 1.3 negotiation.

Portal-based gateway services fit HIPAA workflows best

A gateway service sits between the practice mail server and the internet. Staff send email normally through Gmail or Outlook. The gateway inspects each message against a policy list.

Messages that match a trigger, like a subject line keyword or a recipient on the encryption list, divert to a secure portal. The recipient receives a notification email with a link.

The recipient clicks the link, verifies identity with a one-time passcode, and reads the message in a browser. No certificate, no plugin, no keypair. This works for patients on any device.

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

how to email encrypted in article illustration two

Encrypting attachments as a second layer

Password-protected PDFs add attachment-level encryption. Adobe Acrobat, Preview on macOS, and free tools like PDFsam all support the format. The recipient enters a password to open the file.

ZIP files encrypted with AES-256 offer the same layer for other document types. Windows Explorer, macOS Terminal, and free tools like 7-Zip all support the format. Use AES-256 rather than the older ZipCrypto standard.

The password must travel through a channel separate from the email itself. A phone call, a text message, or a secure messaging app all work. If both the file and the password go through the same mailbox, an attacker with mailbox access gets both.

For sending encrypted documents that need to survive across mail platforms, this dual-layer approach is a reliable fallback. Review the linked how to send encrypted documents via email guide for a detailed walkthrough.

Method comparison across three common scenarios

The table below shows which method fits which scenario. Practices should map their real mail flows against the categories rather than picking a single method for all sends.

Scenario Best method Recipient action
Internal staff email carrying PHI Native S/MIME or Purview Open in mail client
Patient communication Portal-based gateway Click link and verify with passcode
Referral to another clinic Portal or S/MIME if certificate available Portal login or auto-decrypt
Sensitive attachment across mixed platforms Password-protected PDF plus TLS Open file with password

Practices with mixed platforms usually settle on the portal model as the default because it works everywhere. Native S/MIME stays useful for internal mail between staff who all have certificates.

💡Pro Tip: Test the encryption flow on mobile every quarter

Portal login flows that work on desktop sometimes break on iOS or Android because of pop-up blockers, browser policy differences, or MDM restrictions. Once per quarter, send a test message from the practice mailbox to a personal address on a different provider. Open the portal link on both an iPhone and an Android phone. Confirm the one-time passcode arrives and the message renders correctly. This catches issues before a patient hits them on a time-sensitive prescription authorization or lab result.

Testing the encryption flow before high-stakes sends

Every practice should test the encryption flow at least once a quarter. Send a test message to a personal address on a different mail provider. Open the message in the recipient inbox.

Check the message headers. TLS negotiation appears as TLS=version in the Received line. S/MIME shows a lock icon in the mail client. Portal services show a login page.

Test on both desktop and mobile. Portal login flows that work on desktop sometimes break on iOS or Android because of pop-up blockers or browser policy differences. The test catches these issues before a patient hits them.

  • Send a quarterly test to a personal address on a different provider
  • Verify TLS in the message headers
  • Test the portal login on desktop and mobile
  • Document the test result in the risk analysis
  • Retrain staff on any workflow changes

Common mistakes that break the encryption flow

Staff often paste PHI into the subject line and forget the body is where the encryption applies. S/MIME and OpenPGP leave the subject unencrypted. Portal services often replace the subject with a generic notification, but the practice should train staff to keep the subject vague.

Free consumer accounts get used for PHI during on-call rotations. Personal Gmail or Outlook.com accounts do not qualify for a Business Associate Agreement. Staff should have a documented backup path for after-hours PHI sends.

Recipient certificates expire silently. The next S/MIME message to that address fails to encrypt, and the sender may not notice until the recipient reports the problem. Regular certificate audits catch expired public keys.

Practices that align email encryption with strong healthcare website security features close common gaps in patient intake forms where the same PHI often flows through both channels.

Ongoing training keeps the workflow tight

Training is not a one-time event. New hires, platform changes, and new patient portals all reset the baseline. Practices should include encryption training in the onboarding checklist and revisit it annually.

Focus training on the practical scenarios. A referral letter to another clinic. A claim to a billing partner. An intake form sent back to a patient. Each is a moment where the staff member decides to encrypt.

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

Practices that pair training with strong healthcare website maintenance keep the patient communication stack aligned. For a single-vendor solution that covers the BAA, the portal, and the audit trail, a HIPAA-ready secure email service removes most of the setup work.

Frequently Asked Questions

What is the fastest way to send an encrypted email? +

For Outlook 365 Business Premium users, click Options, click Encrypt, and pick Encrypt-Only. The message goes through Microsoft Purview Message Encryption and reaches the recipient with a secure portal link. For Gmail on Google Workspace Enterprise, click the lock icon in compose after S/MIME is configured. For every other plan, use a gateway service that layers encryption on top of the existing mailbox. Gateway services require no client setup and produce a consistent recipient experience across sender platforms.

Can I encrypt an email attachment separately from the message body? +

Yes. Password-protected PDFs and ZIP files add attachment-level encryption on top of any message-level protection. This is useful when the sender and recipient use different mail clients. The password should travel through a channel separate from the email itself, like a phone call or text message. If both the encrypted attachment and the password travel through the same compromised mailbox, an attacker gets access to both. Sharing the password through a different channel is a small step that meaningfully raises the effort required for a breach.

Does Gmail confidential mode count as encryption? +

Confidential mode adds passcode gating, message expiration, and controls that disable forwarding, copying, and printing. It does not add end-to-end encryption. Google can still read the message. For HIPAA workflows this is not sufficient by itself. Confidential mode is useful for internal Gmail-to-Gmail messages where extra recipient controls are helpful. For external mail carrying PHI, use S/MIME on the Enterprise plan or a gateway service. Confidential mode on a free Gmail account is not enough for any regulated data flow.

What happens if the recipient cannot open my encrypted email? +

Portal services fall back to a one-time passcode sent to the recipient inbox, which the recipient enters on the portal to open the message. S/MIME messages sent to a recipient without a valid certificate arrive as unreadable ciphertext or attachments. Practices should test the flow before high-stakes sends. Send a test message to a personal address on a different provider and confirm the login works on a phone. If the recipient hits a broken portal, the message may be a prescription authorization that misses a deadline.

How do I send an encrypted email from my phone? +

iOS Mail sends S/MIME encrypted messages after the certificate is installed in the keychain. Outlook mobile supports Encrypt on Business Premium accounts, and Gmail mobile supports S/MIME on Enterprise accounts. Portal-based gateway services work identically on desktop and mobile because the encryption happens at the mail server, not on the device. For occasional PHI sends from a personal phone during on-call rotations, the portal model is the simplest option. Free personal accounts should not be used for PHI regardless of device.

Does an encrypted email hide the subject line? +

S/MIME and OpenPGP encrypt the message body and attachments but leave the subject line, recipient address, and sender address unencrypted. Portal-based services often replace the subject line with a generic notification like Secure message from Practice Name. That reveals the sender but hides the topic. Practices should train staff to avoid sensitive terms in the subject line even when the body is encrypted. A subject line of Test results for Patient Smith leaks PHI on its own.

How do I verify my encrypted email actually worked? +

Send a test message to a personal address on a different mail provider. Open the message in the recipient inbox. If the sender used TLS, the Received headers show TLS=version. If the sender used S/MIME, the message shows a lock icon and requires the recipient certificate to decrypt. If the sender used a portal service, the recipient sees a login page rather than the message body inline. NIST recommends quarterly verification of encryption controls as part of the risk analysis process.

Posted on

Encrypted Emails in Outlook Sending Guide and Troubleshooting Fixes

encrypted emails outlook guide featured image

🔑 Key Takeaways

  • Outlook offers three encryption paths: Purview, native S/MIME, and third-party add-ins like Virtru.
  • Purview encryption is four clicks: Options, Encrypt, pick policy, Send. External users get a portal.
  • No Encrypt button usually means the wrong Microsoft 365 plan, not an Outlook bug.
  • S/MIME needs an X.509 cert on both sides, which clusters use in orgs with central PKI.
  • HIPAA practices need a Microsoft BAA plus Purview or S/MIME before routing any PHI through Outlook.

Sending encrypted emails in Outlook is straightforward once the correct license and configuration are in place. The confusion for most users starts with which encryption method their license supports and whether the Encrypt button in the ribbon is available at all.

This guide covers the three practical routes for encrypted email in Outlook: Microsoft Purview Message Encryption, S/MIME through certificates, and third-party add-ins. Each section includes step-by-step instructions and the license or setup requirement.

A dedicated troubleshooting section addresses the “cant send encrypted emails Outlook” errors that generate the most support tickets. Every fix is based on Microsoft’s current documentation and typical production configurations.

Three Encryption Routes in Outlook

Outlook supports encrypted email through three separate mechanisms. The right choice depends on the Microsoft 365 license, the recipient population, and whether the organization needs certificate-based zero-knowledge encryption.

Microsoft Purview Message Encryption is the most common route. It ships with Microsoft 365 Business Premium and Enterprise E3, E5, A3, and A5 licenses. Users encrypt messages with a single click in the Options ribbon.

S/MIME is the second route. It requires an X.509 certificate installed on the sender’s device and prior key exchange with the recipient. S/MIME is standards-based and interoperable across mail clients that support it, but the setup burden limits adoption.

Third-party add-ins are the third route. Virtru, Mailhippo, and Barracuda all publish Outlook add-ins that add encryption capability to Outlook regardless of the underlying Microsoft license. These add-ins fit tenants on lower license tiers or workflows that need features Microsoft native encryption does not cover.

Sending an Encrypted Email with Purview Message Encryption

Purview Message Encryption is the fastest route to encrypted email in Outlook for tenants with an eligible license. The sending workflow takes four steps.

Compose a new message in Outlook Desktop or Outlook on the web. Click the Options tab in the ribbon at the top of the compose window. Click the Encrypt button in the Options ribbon. Choose the encryption policy from the dropdown: Encrypt-Only for content encryption or Do Not Forward for encryption plus forwarding restrictions.

  • Compose the message as normal (recipient, subject, body, attachments)
  • Click Options in the ribbon
  • Click Encrypt, then select the policy
  • Click Send

Recipients on Microsoft 365 read the message inline in their inbox with no additional steps. External recipients receive a notification email with a link to Microsoft’s Message Encryption portal. They sign in with a Microsoft account, Google account, or a one-time passcode to read the message.

encrypted emails outlook in article illustration one

Sending an Encrypted Email with S/MIME in Outlook Desktop

S/MIME encryption in Outlook Desktop requires an X.509 certificate installed in the Windows certificate store on the sender’s machine. The certificate can be issued by an internal certificate authority or a commercial CA.

Once the certificate is installed, configure Outlook to trust it. Open Outlook, click File, Options, Trust Center, Trust Center Settings, Email Security. Under Encrypted email, click Settings. In the Security Settings Name dropdown, name the profile. Under Signing Certificate and Encryption Certificate, click Choose and select the S/MIME certificate. Click OK.

To send an encrypted message, compose the message as normal. Click the Options tab and select Encrypt (or Sign, if digital signing only). Send. For encryption to work, Outlook needs the recipient’s public certificate. If the recipient has sent a previously signed message, Outlook captures the certificate automatically.

Our companion piece on how to send encrypted emails covers the S/MIME setup in more depth including certificate procurement from commercial CAs.

Understanding Encrypt-Only Versus Do Not Forward

The Encrypt button dropdown in Outlook offers two Purview policies: Encrypt-Only and Do Not Forward. The difference matters because it affects what recipients can do with the message after they read it.

Encrypt-Only applies message-level encryption to the content in transit and at rest. Recipients can read, reply, forward, print, and copy the content freely once decrypted. The encryption protects against server-side exposure and network interception.

Do Not Forward adds rights management restrictions on top of encryption. Recipients using compliant clients cannot forward, print, or copy the content. The restrictions are enforced by the recipient’s mail client, so they may not hold in all environments (particularly on mobile clients or non-Microsoft mail apps).

Choose Encrypt-Only when the concern is transport and mailbox exposure and the recipient needs full flexibility to work with the content. Choose Do Not Forward for messages containing internal deliberations, confidential negotiations, or sensitive personnel information where distribution controls matter.

Example

A 12-clinician orthopedic practice on Microsoft 365 Business Standard tried to send an MRI report to a referring surgeon and found no Encrypt button in the Outlook ribbon. IT verified the plan in the admin center, upgraded three clinical mailboxes to Business Premium at $22 per seat per month, and confirmed Azure Rights Management showed Activated. The Encrypt button appeared within 45 minutes of license assignment. A test send to a Gmail address delivered a portal link that opened after a one-time passcode.

Fixing “Cannot Send Encrypted Emails” Errors in Outlook

The most common cause of the “cant send encrypted emails Outlook” error is a license mismatch. Purview Message Encryption is not included in Microsoft 365 Business Basic or Business Standard. The Encrypt button in the ribbon does not appear when the license is not eligible.

Verify the license in the Microsoft 365 admin center at admin.microsoft.com. Navigate to Billing, Licenses, and confirm the assigned license is Business Premium, E3, E5, A3, or A5. If the license is Business Basic or Business Standard, upgrade to enable Purview Message Encryption.

The second common cause is Azure Rights Management being disabled at the tenant level. In the admin center, navigate to Settings, Org settings, Services, and confirm Rights Management is set to Activated. Microsoft’s documentation at learn.microsoft.com purview ome covers the tenant-level activation steps.

The third common cause is Outlook not being fully signed in to the Microsoft 365 mailbox. Check the account status in File, Account Settings and confirm the account shows as connected. Sign out and sign back in if the account shows as offline or unauthenticated.

encrypted emails outlook in article illustration two

Encrypted Emails in Outlook on the Web

Outlook on the web (outlook.office.com) supports Purview Message Encryption with the same license eligibility as Outlook Desktop. The compose window includes an Encrypt option in the toolbar.

Click New message. Compose the message. Click the ellipsis (three dots) in the message toolbar. Select Encrypt, then choose the policy. The recipient experience matches the Desktop workflow.

Outlook on the web does not support S/MIME as fully as Outlook Desktop. Some S/MIME features require the S/MIME extension for Edge or Chrome. Organizations relying on S/MIME should standardize on Outlook Desktop or accept the reduced feature set in the web client.

For workflows where users move between Desktop and web frequently, Purview Message Encryption provides a consistent experience. S/MIME works best when the user consistently uses Outlook Desktop.

Encrypted Emails in Outlook Mobile

The Outlook mobile app for iOS and Android supports Purview Message Encryption for both sending and reading. The interface mirrors the desktop workflow with an Encrypt option in the compose menu.

To send an encrypted message on mobile, tap New Message. Compose the message. Tap the three-dot menu. Tap Encrypt and select the policy. Tap Send.

S/MIME on mobile is more limited. iOS Mail supports S/MIME natively when a certificate is provisioned through a configuration profile. Outlook mobile has limited S/MIME support and generally requires organization-specific configuration through Intune or a similar mobile device management platform.

For practices where mobile use is heavy, Purview Message Encryption provides a smoother path than S/MIME. Users who need S/MIME on mobile should plan on iOS with MDM-managed certificates rather than trying to make it work on Android or Outlook mobile.

💡Pro Tip: Confirm the Azure Rights Management state first

License upgrades alone do not always surface the Encrypt button. Azure Rights Management must be Activated at the tenant level under Settings, Org settings, Services. Roughly one in five license-upgrade tickets stall here because the tenant was provisioned before automatic activation became default. Activating takes two clicks in the admin center, and the button appears in Outlook after the client resyncs licenses (usually within an hour).

Encrypted Emails in Outlook for HIPAA Compliance

Healthcare practices sending PHI through Outlook need a Business Associate Agreement (BAA) covering the Microsoft 365 tenant. Microsoft signs a BAA for Business and Enterprise plans but not for free Outlook.com accounts.

The BAA plus TLS in transit plus encryption at rest satisfies the HIPAA Security Rule’s transmission and storage safeguards. Adding Purview Message Encryption or S/MIME provides additional message-level protection. HHS publishes BAA guidance at the HHS BAA reference page.

Practices should confirm the BAA is signed before sending PHI. The Microsoft 365 admin center under Compliance shows the BAA status for enterprise agreements. For Business tier agreements, the BAA is typically part of the Microsoft Products and Services Data Protection Addendum available from the Microsoft Trust Center.

Our team at Redefine Web has published guidance on healthcare website security features for practices building broader HIPAA programs beyond email.

Third-Party Encryption Add-Ins for Outlook

Tenants on Microsoft 365 Business Basic or Business Standard cannot access Purview Message Encryption. Rather than upgrading the whole tenant license, some practices add a third-party encryption product that includes an Outlook add-in.

Common options include Virtru (browser and Outlook add-in), Barracuda Email Gateway Defense (Outlook add-in through the gateway), and inbox-native services such as Mailhippo (Outlook add-in with recipient inbox delivery).

These add-ins install through Microsoft AppSource and integrate into the Outlook compose window. Users click an encryption button in the ribbon or toolbar to route the outbound message through the service.

The trade-off is that the sender manages two encryption tools if the tenant also uses Purview. For small practices, standardizing on a single add-in and skipping Purview keeps the workflow simpler. Larger organizations that already own Business Premium or higher typically standardize on Purview and use add-ins only for niche workflows.

Opening and Forwarding Encrypted Emails in Outlook

Recipients on Microsoft 365 read Purview-encrypted messages inline in Outlook Desktop, Outlook on the web, or Outlook mobile. No additional steps are required.

External recipients receive a notification email with a Read the message button. Clicking opens Microsoft’s Message Encryption portal in a browser. The recipient signs in with a Microsoft, Google, Yahoo, or one-time passcode option. The decrypted message displays. Our companion piece on how to open encrypted emails in Outlook covers this flow.

Forwarding an encrypted email depends on the policy. Encrypt-Only messages can be forwarded and remain encrypted in transit. Do Not Forward messages are blocked from forwarding in compliant clients. S/MIME messages can be forwarded, but the forwarding recipient must have the original recipient’s public certificate for the encryption to reach them successfully.

For practices where forwarding is common (referrals, care coordination), Encrypt-Only is usually the correct default policy. Do Not Forward suits legal, personnel, and executive communications where distribution controls matter more than workflow flexibility.

Frequently Asked Questions

How do I send an encrypted email in Outlook? +

Open a new message in Outlook Desktop or Outlook on the web. Click the Options tab in the ribbon. Select Encrypt and choose either Encrypt-Only or Do Not Forward from the dropdown. Compose the message and click Send. Recipients on Microsoft 365 read the message inline. External recipients receive a portal link to read through Microsoft’s Message Encryption portal. This method requires the tenant to have Microsoft 365 Business Premium or higher, or an Enterprise E3, E5, A3, or A5 license.

Why can I not send encrypted emails in Outlook? +

The most common cause is a license issue. Microsoft Purview Message Encryption is not included in Microsoft 365 Business Basic or Business Standard. Upgrading to Business Premium or higher enables the Encrypt button in the ribbon. Other causes include Azure Rights Management being disabled at the tenant level, Outlook not being connected to the Microsoft 365 mailbox, or corporate policies blocking the encryption option. Verify the plan in the Microsoft 365 admin center and confirm the correct account is signed in to Outlook.

What is the difference between Encrypt-Only and Do Not Forward in Outlook? +

Encrypt-Only encrypts the message content in transit and at rest. Recipients can read, reply, forward, print, and copy the content. Do Not Forward encrypts the message and applies rights management restrictions that prevent forwarding, printing, and copying (for recipients using clients that honor those restrictions). Do Not Forward is enforced by the recipient’s mail client, so restrictions may not hold on all clients. Choose Encrypt-Only when the concern is transport and mailbox exposure. Choose Do Not Forward for additional distribution controls.

How do I set up S/MIME encryption in Outlook Desktop? +

Obtain an S/MIME certificate from an internal certificate authority or a commercial certificate authority such as Sectigo or DigiCert. Install the certificate in the Windows certificate store on the machine running Outlook. Open Outlook, go to File, Options, Trust Center, Trust Center Settings, Email Security. Under Encrypted email, click Settings and select the certificate. Save. To send encrypted, compose a message, go to Options in the ribbon, and select Encrypt (S/MIME option) if the recipient’s certificate is already known to Outlook.

Can external recipients read encrypted emails from Outlook? +

Yes. External recipients read Purview-encrypted messages by clicking a link in the notification email that opens Microsoft’s Message Encryption portal. They sign in with a Microsoft account, Google account, or a one-time passcode. The portal displays the decrypted message. For S/MIME encrypted messages, the external recipient must have their own S/MIME certificate and a mail client that supports S/MIME. Not all external recipients meet those requirements, so Purview is more practical for mixed audiences.

Does encrypted email in Outlook satisfy HIPAA compliance? +

Encrypted email in Outlook satisfies HIPAA when three conditions are met. The Microsoft 365 tenant must be on a plan for which Microsoft signs a BAA (Business or Enterprise, not free Outlook.com). Encryption must be applied to PHI-containing messages using Purview Message Encryption or S/MIME. The organization must have documented policies and access controls consistent with the HIPAA Security Rule. Meeting all three keeps Outlook-based email HIPAA-compliant for most healthcare workflows. Practices should verify the BAA is signed before sending PHI.

What happens if I forward an encrypted email in Outlook? +

Forwarding behavior depends on the encryption method and policy. An Encrypt-Only message can be forwarded by the recipient and remains encrypted at the transport level. A Do Not Forward message is blocked from forwarding in clients that honor the restriction. An S/MIME encrypted message can be forwarded, but the forwarding recipient must have the original recipient’s certificate or the sender re-encrypts to the new recipient. Forwarding across encryption boundaries (Purview to S/MIME or vice versa) often falls back to unencrypted or requires re-encryption at the forwarding client.

Posted on

Virtru Email Encryption Reviewed with Pricing and Setup Details

virtru email encryption guide featured image

🔑 Key Takeaways

  • Virtru adds client-side encryption to Gmail and Outlook via extension in minutes, not weeks.
  • The proprietary TDF format supports revocation and expiration that S/MIME and PGP cannot match.
  • Pricing runs free personal, Pro at about $79 per user yearly, and custom Enterprise with DLP.
  • The Pro tier BAA covers Virtru servers but not the underlying Gmail or Outlook mailbox itself.
  • Reviews praise setup speed and post-send controls; recipient Secure Reader is the top friction.

Virtru email encryption is one of the most widely adopted client-side encryption products in the small and mid-market segment. The service plugs into Gmail and Outlook through a browser extension or add-in and encrypts messages on the sender’s device before they leave the mail client.

This guide covers how virtru email encryption works, what it costs, and where it fits. Sections address pricing tiers, HIPAA coverage, the proprietary Trusted Data Format, review sentiment, and honest deployment trade-offs.

The material is aimed at IT decision makers evaluating Virtru against alternatives. Every section reflects Virtru documentation, published pricing on the Virtru site, and aggregated review sentiment from Gartner Peer Insights, G2, and TrustRadius.

How Virtru Email Encryption Works

Virtru installs as a browser extension for Gmail and as an add-in for Outlook. Once installed, the compose window in either application displays a Virtru toggle above the message body.

Enabling the toggle before Send encrypts the outbound message using Virtru’s Trusted Data Format. The message body and attachments are wrapped in a TDF container that includes policy metadata and references to encryption keys held on Virtru servers.

The recipient receives an email with a Secure Reader link. Clicking the link opens the Virtru Secure Reader in a browser and displays the decrypted content. First-time recipients complete a short verification flow. Returning recipients read directly.

The sender can also enable post-send controls at the time of encryption: message expiration, disable forwarding, disable printing, watermarking, and read receipt visibility. Those controls are enforced by the Secure Reader when the recipient opens the message.

Virtru Email Encryption Pricing Tiers

Virtru publishes three pricing tiers on its site. The tiers scale from free personal use to enterprise deployments with custom pricing.

The free personal tier supports encrypted send and receive on personal Gmail accounts. Basic post-send controls are included. The tier does not include a BAA and is not suitable for HIPAA-covered content.

  • Free tier: personal Gmail encryption, basic controls, no BAA
  • Pro tier: approximately $79 per user annually, BAA included, full post-send controls
  • Enterprise tier: custom pricing, adds DLP, key management options, advanced integrations
  • Volume discounts: apply above ~100 seats on the Enterprise tier

The Pro tier at $79 per user per year sits above the Zixcorp base tier ($30 to $50) and roughly comparable to portal-based products such as Barracuda Email Gateway Defense at the small business scale. Enterprise negotiations often move on volume and add-on scope.

virtru email encryption in article illustration one

Downloading and Installing Virtru

Installation is one of the shorter paths in encrypted email deployment. The Virtru extension for Chrome installs from the Chrome Web Store in under a minute. Firefox and Edge extensions install through their respective add-on stores.

The Outlook add-in installs through Microsoft AppSource for Outlook 2016 and later, Outlook for Mac, and Outlook on the web. Enterprise administrators can deploy the add-in centrally through the Microsoft 365 admin center for all users at once.

After installation, the user signs in to Virtru with their existing Gmail or Microsoft 365 credentials through OAuth. That step links the mail account to the Virtru service. No new mailbox or address is created.

Total time from installation to sending the first encrypted message is typically under five minutes. That contrasts with the 30 to 90 day tuning cycle common for gateway policy products such as Zixcorp or Proofpoint.

The Trusted Data Format and Its Trade-Offs

Trusted Data Format (TDF) is Virtru’s proprietary encryption container. It wraps content in a package that includes both the ciphertext and policy metadata such as expiration dates, forwarding restrictions, and watermark instructions.

The design gives senders post-send controls that neither S/MIME nor PGP provide. A sender can revoke access to a message after delivery, change the expiration date, or add a watermark. Those features rely on the Secure Reader enforcing the policy at open time.

The trade-off is interoperability. TDF is not an open standard supported by native mail clients. Recipients read TDF messages through the Virtru Secure Reader, not through Outlook’s or Apple Mail’s S/MIME support. That dependency ties recipient access to Virtru infrastructure remaining operational.

Organizations that need standards-based encryption for interoperability with S/MIME or PGP users need a different tool. Our guide to S/MIME email encryption signature covers the standard-based approach.

Example

A boutique law firm with eight attorneys picks Virtru Pro at $79 per user annually for client communication involving privileged material. Setup finishes in under an hour on a Tuesday morning. Within two weeks, attorneys use post-send revocation four times to pull back messages sent to wrong recipients from autocomplete errors. Clients on Gmail open messages through the Secure Reader with a verification code on first read. The firm accepts the modest recipient friction because revocation and expiration controls justify the pricing above simpler portal options.

Virtru Email Encryption and HIPAA

Healthcare practices use Virtru on the Pro and Enterprise tiers to send HIPAA-covered PHI through Gmail or Outlook. The BAA covers Virtru’s services under HIPAA’s business associate rules.

The BAA scope includes Virtru servers, the Secure Reader portal, and the TDF encryption process. Practices should confirm the signed BAA is in force before routing PHI. HHS publishes sample provisions at the HHS BAA reference page.

The Virtru BAA does not extend to the underlying Gmail or Outlook mailbox. For full HIPAA coverage across the mail path, the practice needs Google Workspace on a BAA-eligible plan or Microsoft 365 on a business plan with a BAA. Free consumer Gmail does not qualify. Our companion piece on HIPAA compliant email Gmail covers the Workspace plan requirements.

Practices building broader HIPAA compliance often pair encrypted email with hardening on the web side. Our team at Redefine Web has published guidance on healthcare website security features.

virtru email encryption in article illustration two

Virtru Review Notes from Peer Sources

Aggregated reviews from Gartner Peer Insights, G2, and TrustRadius cluster around consistent themes. Positive scores focus on ease of setup, Gmail and Outlook integration quality, and the post-send controls.

The setup speed is a common highlight. Reviewers frequently note that a small practice can be sending encrypted email within an hour of purchasing. That contrasts with 30 to 90 day gateway deployments and drives adoption in the small business segment.

Negative scores focus on the proprietary TDF model, the recipient Secure Reader experience (which has improved but historically drew complaints), and pricing above budget-conscious small practices. Reviewers also occasionally cite the OAuth reauthentication cycle in Gmail as a friction point after Google credential rotation events.

Deliverability and the sender experience rarely draw complaints. The integration into the existing mail client keeps sender workflow essentially unchanged. That is a real strength compared to portal-based products where the sender must remember to route sensitive mail through a separate compose interface.

Post-Send Controls in Virtru

Post-send controls are one of the strongest Virtru differentiators. The sender can enforce policy on a message after it has already left the outbox by adjusting metadata stored on Virtru servers.

Message expiration lets the sender set a date after which the Secure Reader refuses to display the content. Useful for time-limited offers, contract negotiations, and clinical results with a documented review window.

Revocation lets the sender cut off access to a specific message even before expiration. Useful when a message was sent to the wrong recipient or when a situation changes after send.

Disable forwarding, disable printing, and watermarking add friction against internal or accidental redistribution. None of these controls are cryptographically enforceable in the strict sense, since a determined recipient can screenshot or transcribe. They act as policy signals and legal deterrents rather than technical guarantees.

💡Pro Tip: Verify post-send controls fit your actual workflow

Virtru's revocation, expiration, and disable-forwarding controls are its strongest differentiator. Before signing, list the last twenty sensitive messages the team sent and ask whether any of them would have benefited from those controls. A workflow of routine patient reminders rarely uses revocation. A workflow of contract negotiations, clinical results with review windows, or attorney-client documents uses them weekly. Match the tier to actual usage patterns, not to the theoretical value of features that sit unused.

The Recipient Experience with Virtru

Recipients of Virtru-encrypted messages receive a normal-looking email with a Secure Reader link. Clicking the link opens the Secure Reader in a browser tab and displays the decrypted content.

First-time recipients complete a short verification flow. Virtru typically sends a verification code to the recipient’s email address to confirm identity. That step reduces phishing risk but adds a small friction to the first read.

Returning recipients read directly through the Secure Reader with a shorter session flow. Recipients who receive frequent messages from the same sender often find the Secure Reader workflow acceptable. Recipients who receive occasional messages find the extra click and verification step noticeable.

For senders whose recipients want no portal or Secure Reader step at all, inbox-native services such as Mailhippo deliver decrypted content directly to the recipient’s regular inbox with a one-click experience.

Virtru Compared to Alternatives

Virtru competes with three categories of alternatives: gateway policy products (Zixcorp, Barracuda, Proofpoint), Microsoft-native encryption (Purview Message Encryption), and inbox-native services.

Against gateway policy products, Virtru wins on setup speed and loses on policy-based enforcement. A Virtru sender must remember to enable the toggle. A Zixcorp gateway scans every outbound message automatically. For high-volume regulated senders, that enforcement gap matters.

Against Microsoft Purview Message Encryption, Virtru offers more granular post-send controls and works with both Google Workspace and Microsoft 365. Purview is bundled with M365 E3 and E5 and works transparently between M365 tenants without additional cost for licensed users. Purview documentation lives at learn.microsoft.com purview ome.

Against inbox-native services, Virtru offers more post-send controls and a longer feature list. Inbox-native services offer a smoother recipient experience and often a lower price point. Our companion piece on email encryption service covers the category comparison.

When Virtru Fits and When It Does Not

Virtru fits small to mid-size teams that use Gmail or Outlook, need HIPAA-compliant email quickly, and value post-send controls such as revocation and expiration. Legal firms, healthcare practices, and financial advisors are common Virtru customers.

Virtru does not fit large enterprises with heavy regulated content flow that need policy-based automatic enforcement across thousands of users. The user-triggered toggle model depends on the sender remembering to encrypt, which introduces enforcement gaps at scale.

Virtru also fits less well for organizations that need cryptographic zero-knowledge encryption with recipient-held keys. TDF holds encryption keys on Virtru servers, so Virtru servers can decrypt if compelled by legal process. Organizations with true zero-knowledge requirements need S/MIME or PGP.

For a broader view, our companion articles on secure email encryption service and email encryption cover the category landscape and help match tool to workflow.

Frequently Asked Questions

What does Virtru email encryption cost? +

Virtru offers a free personal tier for individual users. The Pro tier for business users is priced around $79 per user annually and includes the BAA for HIPAA coverage. The Enterprise tier is custom-priced and adds data loss prevention, key management options, and integration features. Volume discounts apply at higher seat counts. Small practices under 10 seats pay approximately full list. Enterprises above 500 seats typically negotiate below list. Confirm current pricing on the Virtru site because published rates are updated periodically.

Is Virtru email encryption free for personal use? +

Yes. Virtru offers a free tier for personal Gmail users that supports encrypted send and receive with basic controls. The free tier does not include a BAA and is not suitable for HIPAA-covered PHI. It also lacks the DLP integrations and advanced management features of the Pro and Enterprise tiers. The free tier works well as an evaluation environment or for individual privacy-focused users who want client-side encryption on a personal Gmail account without paying for a business plan.

How does Virtru email encryption work in Gmail and Outlook? +

Virtru installs as a browser extension for Gmail (Chrome, Firefox, Edge) and as an Outlook add-in for Outlook desktop and Outlook web. Once installed, the compose window shows a Virtru toggle. Enabling the toggle encrypts the outbound message using Virtru’s Trusted Data Format. The recipient receives a normal-looking email with a Secure Reader link that opens the decrypted content in a browser. The sender can also enable post-send controls such as expiration, disable forwarding, and watermarking through the same interface.

What is the Virtru Trusted Data Format? +

Trusted Data Format (TDF) is Virtru’s proprietary encryption container. It wraps message content and attachments in a package that includes policy metadata and references to encryption keys held by Virtru servers. TDF supports features that S/MIME and PGP do not, such as post-send revocation, expiration, disable forwarding, and watermarking. The trade-off is that TDF is not an interoperable open standard. Recipients read TDF-wrapped content through Virtru’s Secure Reader rather than through their normal mail client’s native encryption support.

Does Virtru email encryption include a BAA for HIPAA? +

The Pro and Enterprise tiers include a Business Associate Agreement covering Virtru’s services under HIPAA. The free personal tier does not include a BAA and is not suitable for PHI. The BAA covers the Virtru servers, the Secure Reader portal, and the TDF encryption process. Healthcare organizations should confirm the signed BAA is in force before routing PHI. The BAA does not extend to the underlying Gmail or Outlook account, so the mail platform must also be on a BAA-eligible plan for full path coverage.

How does Virtru compare to Zixcorp email encryption? +

Virtru and Zixcorp target different segments. Virtru fits small to mid-size teams that want quick setup on existing Gmail or Outlook accounts. Zixcorp fits enterprises with heavy regulated content flow, mature IT teams, and a need for policy-based enforcement across large user populations. Pricing overlaps in the middle. Virtru at $79 per user is competitive with the Zix base tier at $30 to $50 per user, though Zix drops with volume. Our companion piece on Zixcorp email encryption covers Zix in detail.

Can Virtru email encryption prevent phishing? +

Virtru is an outbound encryption product. It does not scan inbound mail for phishing. Preventing phishing requires a separate inbound email security product such as those offered by Microsoft Defender for Office 365, Google Workspace advanced security, Barracuda Email Gateway Defense, or a dedicated anti-phishing service. Virtru complements those products by protecting outbound content but does not replace them. Practices should treat encryption and phishing defense as separate categories of protection and evaluate each independently.

Posted on

Are Emails Encrypted by Default in 2026

are emails encrypted guide featured image

🔑 Key Takeaways

  • About 95% of Gmail traffic runs on TLS, but any relay refusing the handshake drops to plain SMTP.
  • Encryption at rest guards disks, not access; a court order or hijacked account still reads inboxes.
  • Internal 365 mail stays inside Microsoft’s network and never touches the public internet.
  • True end-to-end mail needs S/MIME, PGP, or a portal service like Purview or Mailhippo.
  • HIPAA won’t accept TLS alone for PHI; regulators expect message-level encryption on external sends.

Most email today rides on some form of encryption. The question is which kind, at what stage, and whether it survives long enough to matter.

Ask are emails encrypted and the honest answer is a qualified yes. Transport encryption covers the connection between mail servers when both sides support it. Message-level encryption, the kind used for encrypted email delivery, protects the content from the sender’s device to the recipient’s inbox.

The gap between those two matters for anyone sending regulated data. This guide walks through where each layer applies, which providers use which methods, and what changes when HIPAA or a business associate agreement enters the picture.

TLS in transit is the default, not end-to-end protection

TLS, or Transport Layer Security, is the standard method for encrypting the link between two mail servers. When a sending server hands a message to a receiving server, both sides negotiate a TLS session and the traffic across that hop is encrypted.

Google reports that around 95 percent of Gmail traffic uses TLS on outbound and inbound. Microsoft 365 numbers are similar. The 5 percent gap is real, and it usually reflects small receiving servers that do not support modern TLS versions.

TLS does not encrypt the message body itself. It encrypts the connection. Once the receiving server accepts the message, it stores the content in whatever form its policies dictate.

Opportunistic TLS also falls back to plain SMTP if the handshake fails. MTA-STS and DANE are the two standards that force a receiving server to require TLS, and they close that downgrade path. Most large providers publish MTA-STS records now, but many smaller domains do not.

Gmail encrypts in transit and at rest, but not end to end

Are all Gmail emails encrypted? In transit, almost all of them are, when the receiving provider supports TLS. Google publishes real-time transparency numbers on this at their Safer Email Transparency Report.

At rest, Gmail stores every message with server-side encryption using keys Google manages. That protects the mailbox from disk theft or unauthorized physical access to Google data centers.

End-to-end encryption is a different layer. Gmail supports S/MIME on Google Workspace Enterprise Plus and Education Plus, which encrypts the message body before it leaves the sender’s device. Personal Gmail accounts do not include native S/MIME.

For consumer-grade Gmail users who need to send an encrypted message once in a while, the practical options are Confidential Mode, which sets an expiration and a passcode but does not encrypt the body, or a browser extension that layers PGP over the compose window.

are emails encrypted in article illustration one

Microsoft 365 encryption depends on the license tier

Are Microsoft emails encrypted? Internal messages between two users on the same Microsoft 365 tenant stay on Microsoft’s network and are encrypted the entire way. External messages use opportunistic TLS.

Purview Message Encryption, which was previously called Office 365 Message Encryption, is Microsoft’s message-level product. It encrypts the body and attachments and delivers external recipients a portal link. Recipients sign in with a Microsoft or Google account, or with a one-time passcode.

Purview requires Business Premium, Microsoft 365 E3, or higher. Business Basic and Business Standard do not include it. Practices on lower tiers either need to upgrade the entire tenant or send outbound clinical mail through a dedicated encrypted service.

Azure Rights Management sits behind Purview and handles the actual key management. If a tenant has never activated Azure Rights Management, the Encrypt button in the Outlook ribbon does not appear even on the correct license.

Internal Office 365 traffic never leaves Microsoft infrastructure

Are internal Office 365 emails encrypted? Yes, at every layer. Internal email between two users on the same tenant traverses Microsoft’s private network and never touches the public internet.

The traffic between Exchange Online servers is TLS-protected. The mailboxes themselves are encrypted at rest with BitLocker at the storage level and additional service-level encryption in the message database.

Cross-tenant email is a different case. A message from one Microsoft 365 tenant to another still uses Microsoft infrastructure end to end, but it is treated as external and subject to standard transport encryption rules.

Administrators can enforce Modern Authentication, disable legacy protocols like POP and IMAP, and turn on Customer Key to hold their own encryption keys. Those steps harden the tenant but do not change the underlying encryption layers already in place.

Example

A cardiology group assumed their Google Workspace Business Starter setup encrypted patient lab results because Gmail showed the padlock icon on outbound messages. During a HIPAA risk assessment, the security consultant tested by sending a message to a legacy mail server at a rural referring clinic that did not support TLS. The delivery downgraded to plain SMTP silently. The group enforced MTA-STS on their domain, added Mailhippo for external PHI sends at $4.95 per user per month, and closed the finding within one week.

DocuSign notifications are not encrypted documents

Are DocuSign emails encrypted? The notification email itself is an ordinary message sent over TLS. It contains a link, a sender name, and a subject line, and none of that content is encrypted end to end.

The signed document lives inside the DocuSign platform, not in the email. When the signer clicks the link, they authenticate to DocuSign and view the document over HTTPS. The document itself is protected by DocuSign’s platform encryption and access controls.

The gap this creates is that anyone with mailbox access to the recipient can click the link and, if additional authentication is not enforced, sign the document. DocuSign offers signer authentication options like SMS codes, knowledge-based questions, and ID verification. Those are separate from the email.

Providers like Adobe Sign, Dropbox Sign, and PandaDoc all follow the same pattern. The document is protected in the platform, and the notification is a routine email.

Are emails automatically encrypted or does the sender configure it

Are emails automatically encrypted? Transport encryption is automatic when both servers support it. Message-level encryption is not automatic on any consumer email service.

The sender has to take an action. On Outlook 365, that action is clicking the Encrypt button on the message ribbon. On Gmail Enterprise, S/MIME messages are marked automatically if certificates are installed on both sides.

Some services automate the encryption trigger based on content. Data loss prevention rules can inspect outbound mail for patterns like credit card numbers, Social Security numbers, or clinical terms, then apply encryption when a rule matches.

For healthcare senders who need every message with protected health information to be encrypted without depending on user behavior, the practical approach is a gateway service that encrypts by default. Mailhippo works this way, applying encryption to every outbound message from the connected account rather than relying on a user to remember the correct button.

are emails encrypted in article illustration two

End-to-end encryption requires S/MIME, PGP, or a portal service

Three technologies deliver true end-to-end email encryption today: S/MIME, PGP, and portal-based services. Each protects the message body from the sender’s device to the recipient’s inbox or portal.

S/MIME uses X.509 certificates issued by a certificate authority. Each user has a personal certificate, and the sender needs the recipient’s public key to encrypt a message to them. Certificate management is the hardest part of running S/MIME at scale.

PGP uses a similar public-private key pair model but operates through a web of trust rather than a central authority. It is common in developer and privacy-focused circles but rare in mainstream business email.

Portal services like Purview Message Encryption and Mailhippo skip the certificate problem by delivering messages through a browser-based portal. The recipient does not need to manage keys, and the sender only needs an account.

HIPAA requires encryption when it is reasonable and appropriate

The HIPAA Security Rule lists encryption as an addressable specification for transmitting electronic protected health information. Addressable means the covered entity must implement it if it is reasonable and appropriate, or document why it is not.

In practice, HHS treats email encryption as the default expectation for any transmission of PHI outside a covered entity’s internal network. The 2013 Omnibus Rule reinforced that position by tying breach notification safe harbor to encryption of the data involved.

The HHS guidance on the Security Rule and NIST Special Publication 800-52 Rev. 2 both point to TLS 1.2 or higher for transport and AES-128 or AES-256 for content encryption. Meeting those baselines matters more than the specific product chosen.

Practices that route external clinical email through a service with a signed business associate agreement satisfy the encryption requirement and the vendor accountability requirement at the same time. Emails that carry hipaa phishing emails patterns still need employee training on top of encryption.

💡Pro Tip: Enforce MTA-STS to block silent TLS downgrades

Opportunistic TLS falls back to plain SMTP whenever the receiving server refuses the handshake, and the sender never sees a warning. Publish an MTA-STS policy on your domain so receiving servers know to require TLS on inbound. Configure enforced TLS on outbound to any recipient domain that regularly gets PHI. If TLS negotiation fails, the message queues instead of shipping in plaintext. This one change removes the most common HIPAA transport gap.

Free and consumer options do not include a BAA

ProtonMail sends encrypted messages to other ProtonMail users automatically. Messages to outside recipients go through a password-protected portal that the recipient opens in a browser.

Outlook.com supports Microsoft’s free encryption for consumer accounts through the same Purview infrastructure used by business tenants. The recipient experience is identical to the paid version.

Free S/MIME certificates are available from providers like Actalis for personal use. Setting them up requires installing the certificate in the operating system’s certificate store and pairing it with each mail client.

None of the free options include a business associate agreement. For a healthcare practice, that rules them out for anything involving protected health information. If a topic covers are there free tools for encrypting emails, the compliance angle is where free services fall short. Compliance requires a paid service that will sign a BAA and accept vendor liability.

Steps to confirm your email is being encrypted correctly

Gmail shows a small padlock next to the sender address on received mail. A closed padlock means TLS was used on the last hop, an open one means it was available but not enforced, and no padlock means the message arrived over plain SMTP.

Outlook shows a shield icon on S/MIME-signed or encrypted messages. A green check inside the shield means the signature validated. A red X or a missing shield means the message was not S/MIME protected.

Portal messages arrive as a link rather than an inline body. Recipients who see a Read the message button and a sender-branded landing page are receiving a message-level encrypted message.

For senders who want to confirm their outbound TLS posture, tools like the NIST SP 800-52 Rev. 2 guidelines outline the correct cipher and version baseline, and free tests like CheckTLS or the Google Postmaster Tools show the negotiated TLS status per destination domain.

What to configure for a healthcare or compliance-heavy practice

Start with a written policy that defines what qualifies as protected health information and which outbound messages need encryption. Staff cannot apply a rule they do not know exists.

Configure MTA-STS and DANE on the practice domain to prevent TLS downgrade attacks on outbound mail. Publish DMARC at reject or quarantine to stop spoofed messages from reaching patients.

Choose one encryption path and stick with it. Options include Microsoft 365 Business Premium plus Purview, Google Workspace Enterprise plus S/MIME, or a gateway service like Mailhippo that layers encryption over the existing Gmail or Outlook account without a license upgrade.

Practices that want a broader marketing and website foundation to match the security posture often work with a specialist agency. Firms that focus on healthcare marketing services understand how encryption, patient acquisition, and HIPAA-safe intake forms fit together, and how a compliant healthcare website security setup supports the practice’s digital communications.

  • Verify TLS 1.2 or higher on outbound and inbound mail flow.
  • Enable MTA-STS and DANE on the practice domain.
  • Enforce Modern Authentication and disable legacy IMAP and POP.
  • Route external PHI-bearing mail through an encrypted service with a signed BAA.
  • Train clinical and administrative staff on when encryption is required.

Answering the core question, are emails encrypted, comes down to which layer and which sender. Transport encryption is close to universal between major providers. Message-level protection is the sender’s responsibility, and it is what compliance rules actually require.

Frequently Asked Questions

Are Gmail emails encrypted end to end? +

No. Gmail encrypts messages in transit using TLS whenever the receiving server supports it, and it encrypts stored messages at rest on Google’s servers. Neither method prevents Google from reading the content, and neither protects the message once it lands in a mailbox on a provider that does not enforce TLS. For true end-to-end encryption inside Gmail, the sender needs S/MIME through Google Workspace Enterprise or an external tool that encrypts the body before the message reaches Google.

Are Microsoft 365 emails encrypted? +

Internal messages between users on the same Microsoft 365 tenant stay on Microsoft servers and are encrypted the entire way. External messages use TLS when the receiving server supports it. Microsoft 365 also offers Purview Message Encryption on Business Premium and higher, which applies message-level encryption and delivers external recipients a portal link. Encryption at rest is enabled by default on all Microsoft 365 mailboxes, but that only protects stored data on disk.

Are internal Office 365 emails encrypted? +

Yes. Internal email between two users on the same Microsoft 365 tenant never leaves Microsoft’s infrastructure, and the traffic is encrypted across every internal link. The mailbox contents are also encrypted at rest with Microsoft-managed keys. That protects the message from external interception, but it does not stop a compromised account or an administrator with the correct role from reading the content. Internal encryption is not the same as end-to-end encryption.

Are DocuSign emails encrypted? +

The notification emails DocuSign sends are ordinary messages over TLS, and they contain a link rather than the document itself. The signed document lives on DocuSign’s servers, protected by DocuSign’s platform encryption and access controls. When a signer clicks the link, they authenticate to the DocuSign platform and view the document over HTTPS. The email notification is not encrypted end to end, and anyone with mailbox access can click the link.

How can I tell if an email I received was encrypted? +

Gmail shows a small padlock icon next to the sender address that indicates the transport encryption status between servers. A green padlock means TLS was used, a gray one means TLS was available but not enforced, and a red one means no encryption at all. Outlook displays a similar shield icon for S/MIME-signed or encrypted messages. Portal-based services deliver a link rather than an inline message, which itself is a sign the sender used message-level encryption.

Is there a free way to send an encrypted email? +

Free options exist but each carries a trade-off. ProtonMail sends encrypted messages to other ProtonMail users automatically, and to outside recipients through a password-protected portal. Outlook.com supports Microsoft’s free encryption for consumer accounts. Some sender-side tools also offer free S/MIME certificates from providers like Actalis. Free tiers do not include a business associate agreement, which rules them out for healthcare use. Compliance-grade sending requires a paid service with a signed BAA.

Does encryption protect an email from being read once it arrives? +

No. Once the recipient decrypts and opens the message, the content sits in their mailbox as readable text. Anyone with access to that mailbox, including a shared inbox user, an assistant with delegated access, or a malicious actor with stolen credentials, can read the content. Encryption protects the message during transmission and, in some cases, during storage. It does not protect against account takeover, screen capture, or forwarding by the recipient after decryption.

Posted on

How to Send Encrypted Email Across Any Client

how to send encrypted email guide featured image

🔑 Key Takeaways

  • Opportunistic TLS drops to plaintext without warning; the Sent padlock lies to you.
  • S/MIME encrypts message-level in Outlook and Apple Mail but needs certs on both sides.
  • PGP does the same job with public and private keys; recipients must set up software.
  • Portal services encrypt every send and give recipients a one-click browser link.
  • HIPAA also demands a signed BAA, six-year access logs, and verified encryption proof.

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

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

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

TLS Is the Default Encryption Layer for Every Modern Mail Server

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

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

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

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

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

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

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

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

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

how to send encrypted email in article illustration one

PGP Delivers the Same Protection with a Different Key Model

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

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

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

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

Outlook Encrypt Button Uses Microsoft Purview Message Encryption

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

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

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

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

Example

A pain management clinic uses Microsoft 365 Business Standard with the Encrypt button unavailable. Staff send referral summaries to physicians on Yahoo, iCloud, and small hospital systems. TLS delivery drops to plaintext on roughly fifteen percent of sends because those receiving servers refuse TLS. The clinic adds a portal-based service at $9 per user monthly. Every outbound referral now enforces encryption, falls back to portal delivery when TLS fails, and produces an audit trail the compliance officer can export for annual risk assessment review.

Portal-Based Services Remove the Recipient Setup Barrier

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

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

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

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

how to send encrypted email in article illustration two

Comparison Across the Main Methods

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

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

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

Gmail Encryption Steps Depend on the Workspace Tier

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

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

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

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

💡Pro Tip: Never Rely on Opportunistic TLS for PHI

TLS is opportunistic. When the receiving mail server refuses encryption, the sending server delivers the message in plaintext without alerting the sender. Your Sent folder shows the padlock because the initial hop succeeded. For any regulated content, pick a method that refuses plaintext delivery: S/MIME with verified certificates, or a portal-based service that routes to browser delivery when TLS is not available.

Outlook Encryption Steps Depend on the Microsoft 365 Plan

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

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

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

Verification Steps for Every Sensitive Send

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

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

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

Choose the Method by Recipient and Content

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

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

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

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

Frequently Asked Questions

What is the difference between encryption in transit and end-to-end encryption? +

Encryption in transit protects the connection between two mail servers using TLS. Once the message reaches the destination server, TLS no longer applies and the mail provider can read the content. End-to-end encryption protects the message content from the moment the sender clicks Send until the recipient opens it. Only the sender and the recipient can read the content, not the mail provider in between. S/MIME and PGP provide end-to-end encryption. TLS alone does not.

Do I need special software to send encrypted email? +

It depends on the method. TLS is automatic in every modern mail client and requires no user setup. Confidential Mode in Gmail and Encrypt in Outlook are built into the compose interface. S/MIME needs a certificate installed in the mail client. PGP needs a key pair generated and shared. Portal-based services either install a browser plug-in or route mail through an SMTP relay, and the sender continues to use their existing client. Recipients on portal-based services need no software at all.

Can I send encrypted email to someone who does not use encryption? +

Yes, but the method matters. S/MIME and PGP will not work because both parties need matching keys or certificates. TLS covers the transport but drops to plaintext if the recipient server does not support TLS. Portal-based services solve this because the recipient does not need to configure anything. They receive a notification, click a link, enter a one-time code, and read the message in a browser. Any recipient with an email address and a web browser can open portal-encrypted messages.

Is Gmail Confidential Mode enough for HIPAA? +

No. Confidential Mode does not use end-to-end encryption. Google can read the message content, and the business associate agreement Google signs for Workspace does not extend Confidential Mode into a HIPAA-safe transmission method. Confidential Mode blocks forwarding, copying, and downloading, which are useful controls, but does not meet the transmission encryption standard HIPAA requires for PHI. Use a HIPAA-focused service with a signed BAA that provides verified encryption for every send.

How do S/MIME certificates get issued and renewed? +

S/MIME certificates come from a trusted certificate authority such as DigiCert, Sectigo, or IdenTrust. The user or administrator submits a certificate signing request, verifies identity, and receives the certificate for install in the mail client. Certificates typically expire after one to three years. Renewal repeats the request-and-verify process. Departing employees should have their certificates revoked so their prior encrypted messages cannot be decrypted after they leave. Enterprise deployments automate the process through a managed PKI.

What happens if I send an encrypted email to the wrong person? +

With TLS, the message reaches the wrong recipient and they read it because TLS does not restrict access at the mailbox level. With S/MIME or PGP, the wrong recipient cannot decrypt unless they somehow hold the intended recipient private key, which is very unlikely. With portal-based services, most providers let the sender revoke access at any time from their outbox. The recipient link stops working immediately. This is one of the practical reasons portal-based services are the healthcare default.

Does my mail provider store copies of encrypted messages? +

Yes, in almost every case. Even with S/MIME or PGP, the mail provider stores the encrypted ciphertext in the sender Sent folder and the recipient inbox. Neither the provider nor anyone else can decrypt it without the private key, but the encrypted copy remains stored. This is why HIPAA archive requirements are satisfied by encrypted copies retained for six years. Portal-based services store the content on their own servers and use enforced access controls with logging on every read.