HorizLogoSm.fw_.png
Start Trial

Tag: hipaa

Posted on

What It Means to Encrypt an Email in Plain Terms

what does it mean to encrypt an email guide featured image

[mh_key_takeaways]

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

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

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

Encryption Converts Message Content Into Ciphertext

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

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

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

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

Three Layers of Encryption Cover Different Threats

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

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

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

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

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

The Sender View Looks Almost Identical to Regular Mail

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

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

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

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

The Recipient View Depends on Platform and Method

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

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

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

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

[mh_example]

Unencrypted Email Exposes Content to Anyone on the Path

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

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

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

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

Encryption Methods Compared at a Glance

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

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

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

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

Encrypting an Email in Outlook Uses Microsoft Purview

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

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

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

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

Encrypting an Email in Gmail Depends on Workspace Plan

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

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

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

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

[mh_protip]

Encryption Is One Layer of HIPAA Compliance

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

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

Common gaps in the compliance picture include:

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

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

When a HIPAA Email Service Simplifies the Encryption Decision

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

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

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

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

The Practical Decision Comes Down to Three Questions

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

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

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

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

[mh_faqs]

Posted on

Barracuda Email Encryption Service Review for 2026

barracuda email encryption service guide featured image

[mh_key_takeaways]

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

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

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

What is Barracuda Email Encryption Service

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

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

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

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

barracuda email encryption service in article illustration one

Barracuda Email Encryption Service cost breakdown

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

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

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

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

Barracuda Email Encryption Service login and portal experience

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

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

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

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

[mh_example]

Barracuda Email Encryption Service uptime and outage handling

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

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

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

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

barracuda email encryption service in article illustration two

Barracuda Email Encryption Service phishing and spam handling

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

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

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

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

Barracuda Email Encryption Service legitimacy verification

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

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

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

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

[mh_protip]

Barracuda Email Encryption Service agentless variant

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

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

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

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

Barracuda compared with Cisco and general email encryption alternatives

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

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

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

Key evaluation criteria:

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

Barracuda Email Encryption Service fit for healthcare practices

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

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

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

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

[mh_faqs]

Posted on

HIPAA Compliant Email in Gmail (What Actually Qualifies)

hipaa compliant email gmail guide featured image

[mh_key_takeaways]

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

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

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

Personal Gmail cannot carry PHI regardless of encryption

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

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

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

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

Google Workspace signs a BAA for covered services

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

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

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

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

hipaa compliant email gmail in article illustration one

Encryption in Google Workspace uses TLS and server-side keys

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

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

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

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

Native S/MIME requires Enterprise Plus

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

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

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

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

[mh_example]

Virtru is a common third-party option for Gmail

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

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

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

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

hipaa compliant email gmail in article illustration two

Cisco Secure Email Encryption Service works for larger systems

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

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

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

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

Hosted HIPAA email services layer over Gmail without a plan upgrade

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

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

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

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

[mh_protip]

Admin console settings that harden a Workspace tenant

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

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

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

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

Common breach patterns in Gmail-based practices

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

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

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

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

What to configure this week if you are on Gmail today

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

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

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

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

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

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

[mh_faqs]

Posted on

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

tls encryption email guide featured image

[mh_key_takeaways]

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

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

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

TLS encrypts the connection, not the content

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

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

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

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

Opportunistic TLS is the default and its weakness

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

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

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

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

tls encryption email in article illustration one

MTA-STS and DANE close the fallback gap

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

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

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

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

Office 365 uses TLS on both directions with enforcement options

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

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

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

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

[mh_example]

Outlook covers the client-to-server hop only

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

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

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

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

tls encryption email in article illustration two

TLS alone does not fully satisfy HIPAA

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

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

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

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

How to verify a mail flow is using TLS

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

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

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

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

[mh_protip]

When a receiver does not support TLS, options are limited

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

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

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

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

Configuring outbound TLS enforcement on the sender side

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

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

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

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

Practical setup for a healthcare practice

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

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

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

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

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

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

[mh_faqs]

Posted on

PGP Email Encryption Explained for Gmail and Outlook

pgp email encryption guide featured image

[mh_key_takeaways]

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

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

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

PGP uses public-key cryptography to protect the message body

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

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

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

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

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

PGP for Gmail requires a browser extension

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

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

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

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

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

pgp email encryption in article illustration one

PGP for Outlook uses gpg4win or a commercial add-in

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

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

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

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

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

Symantec PGP centralizes key management for the enterprise

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

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

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

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

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

[mh_example]

PGP compared to S/MIME on the practical decisions

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

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

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

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

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

pgp email encryption in article illustration two

Key management is the hard part of PGP

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

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

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

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

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

HIPAA compliance needs more than PGP encryption alone

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

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

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

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

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

[mh_protip]

PGP fits developer and B2B mail better than patient mail

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

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

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

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

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

Automation with PGP uses gpg and Bouncy Castle

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

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

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

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

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

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

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

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

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

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

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

[mh_faqs]

Posted on

HIPAA Rules for Emailing Medical Records to Patients

hipaa emailing medical records guide featured image

[mh_key_takeaways]

Emailing medical records is one of the most common questions in a HIPAA training. Front-desk staff want to know if a patient can request records by email, whether the response counts as a violation, and what to do when a referring physician office asks for a full chart.

The short answer is that HIPAA allows email delivery of medical records under specific conditions. Getting those conditions right is the difference between a compliant workflow and a six-figure Office for Civil Rights finding. Practices that want the mechanics handled at the service layer usually deploy a secure email service that includes a signed business associate agreement.

This guide covers the actual rules, the patient consent step, the encryption requirement, the common violation patterns, and the workflows that keep records email inside the compliance line.

HIPAA allows email delivery when the patient has consented

The Privacy Rule at 45 CFR 164.524 gives patients the right to access their protected health information in the form and format they request, including electronic delivery. Email counts as an electronic format.

The covered entity must confirm the requested delivery method with the patient. A written form, a portal request, or a documented phone call all work as long as the request is recorded in the audit trail.

For records sent to a third party at the patient direction, the covered entity needs a written authorization signed by the patient. That authorization specifies who receives the records and what information is included.

For records sent among covered entities for treatment, payment, or health care operations, patient consent is not required under the Privacy Rule. A referring physician emailing chart notes to a specialist for a shared patient falls in this bucket.

Every state also has its own rules on medical record disclosure that stack on top of HIPAA. State law can require additional consent, additional recordkeeping, or additional restrictions on specific record types like mental health and substance use treatment records.

Encryption is an addressable specification with a defensible default

The Security Rule at 45 CFR 164.312 lists encryption as an addressable specification. That means the covered entity must implement encryption, adopt an equivalent measure, or document why neither is reasonable and appropriate.

In practice, encryption is the only defensible default for records leaving the practice network. The alternatives, such as physical safeguards on paper records, do not apply to email transmission.

Encryption in transit through TLS covers the connection between the sending server and the receiving server. That is the minimum acceptable standard when both sides are known to support TLS 1.2 or higher.

Encryption at rest covers the message once it lands on either side. Portal-based encrypted email services handle this by keeping the message content inside their own encrypted storage rather than delivering it to the recipient mailbox in plain text.

The HHS FAQ on emailing PHI is the definitive reference on when encryption is required.

hipaa emailing medical records in article illustration one

Patient consent must be documented before records go out

The consent step is where most small practices get in trouble. A verbal request over the phone is legally sufficient under HIPAA, but the practice must document that the request was made and how the patient specified the delivery method.

Documentation can be a signed form scanned into the chart, a completed portal request that logged the timestamp, or a note in the EHR that identifies the requesting person, the delivery method, and the records covered.

The patient must also be informed of the risks of email delivery. HHS clarified in 2013 that a patient can request unencrypted email if they explicitly accept the risks, but the practice must document both the risk disclosure and the patient acknowledgment.

For records going to a third party at the patient direction, the authorization must be in writing and must identify the specific third party, the scope of records, and an expiration date or event.

The consent step is documented in more depth in the guide on HIPAA email requirements, which walks through the specific fields the authorization form must contain.

Delivery to the wrong recipient is the most common violation

Misdirected email tops the Office for Civil Rights list of reported HIPAA violations year after year. A typo in the recipient address, an auto-complete pick from the wrong contact, or a reply-all that included an unintended party all count.

Practices reduce the risk with a verification step before send. The staff member reads back the recipient address from the request form, and the EHR or the email client displays the recipient at the top of the message during compose.

Portal-based encrypted email services add a second layer of protection because the recipient must sign in with a passcode to open the message. A misdirected message that arrives at the wrong inbox cannot be opened without the passcode delivered to the intended recipient.

Auto-complete is a specific risk. Disabling auto-complete for the mailbox that sends records, or moving records to a separate mailbox that only sends to verified addresses, removes the most common failure mode.

For a walkthrough of the reporting steps when a misdirected message happens, see the guide on HIPAA email, which covers the breach notification and remediation timeline.

[mh_example]

Business associate agreements cover every vendor that touches the message

Every vendor that touches, stores, or transmits an email containing PHI on behalf of the covered entity must sign a business associate agreement. That includes the mail provider, the encryption service, the archive vendor, and any spam filtering service.

Free consumer Gmail and personal Outlook.com never qualify because Google and Microsoft do not sign BAAs for those accounts. A practice using a personal Gmail account to email records is out of compliance regardless of whether the message was encrypted.

Google Workspace and Microsoft 365 offer a BAA on eligible paid plans. The practice must actively request the BAA through the vendor portal and sign the covered plan sections before sending PHI.

Dedicated encrypted email services typically include the BAA in the base plan without a separate request step. That removes one of the common compliance gaps found in small-practice OCR audits.

The HHS Covered Entities and Business Associates reference lists the specific BAA requirements and the vendors that count as business associates.

hipaa emailing medical records in article illustration two

Attachments and large records need a link-based delivery pattern

Medical records often exceed the 20 to 25 MB attachment cap on Gmail and Outlook. A full chart with imaging can easily reach several hundred megabytes.

The practical pattern hosts the record on a secure storage service and delivers the download link inside the encrypted message. Portal-based encrypted email services do this automatically for attachments above the SMTP limit.

The recipient authentication step matters more for large records because the file itself is worth more on the black market. A signed URL with a short expiration and a passcode delivered separately is the standard pattern.

Imaging DICOM files, EHR export bundles, and CCDA continuity of care documents all follow the same delivery pattern. The message body carries the request context and the download link, and the file lives on encrypted storage until the recipient opens it.

Some practices also archive the delivered record for the retention period required by state law, which for adult records typically runs seven years and for pediatric records runs through the age of majority plus seven.

Records emails need an audit log the practice can produce on demand

The Security Rule requires audit controls on systems that handle PHI. For records emails, the audit log needs to show who sent the message, when it was sent, who the recipient was, and whether the recipient opened it.

Free consumer mail does not produce this log. Even the sent folder cannot prove that the recipient opened the message.

Google Workspace and Microsoft 365 audit logs cover the send event but not the recipient open event when the recipient is outside the tenant. Portal-based encrypted email services log both because the recipient opens the message through the portal.

The log needs to be retained for the same period as the underlying medical record. Six years is the HIPAA minimum for the Privacy Rule documentation, and state law often extends the requirement to match the medical record retention period.

For a review of the audit control requirements across the full HIPAA Security Rule, see the guide on is it a HIPAA violation to email medical records, which walks through the OCR audit protocol.

[mh_protip]

Penalties escalate quickly for willful neglect

HITECH Act penalty tiers apply to every HIPAA violation. The tier depends on the culpability, not the severity of the disclosure.

Tier 1, unknowing violations, carries $100 to $50,000 per record with a cap of $25,000 per calendar year. Tier 2, reasonable cause without willful neglect, carries $1,000 to $50,000 per record with a cap of $100,000.

Tier 3, willful neglect corrected within 30 days, carries $10,000 to $50,000 per record with a cap of $250,000. Tier 4, willful neglect not corrected, carries $50,000 per record with a cap of $1.5 million.

OCR also requires a corrective action plan that typically runs multiple years. The plan covers policy updates, staff retraining, and a monitoring period during which OCR receives quarterly reports.

State attorneys general can also bring civil actions under HITECH, and repeat willful violations can be referred to the Department of Justice for criminal prosecution under 42 USC 1320d-6.

Common workflow that keeps records email compliant

A compliant records email workflow has a consistent shape. The patient submits a request through a portal or a signed form. The staff member logs the request in the EHR with the delivery method and recipient information.

The staff member composes the message from a mailbox that is covered by a BAA and that uses an encrypted delivery service. The recipient address is verified against the request form, and the send button is clicked only after the verification step.

The recipient receives a portal link, signs in with a passcode delivered to the recipient inbox or phone, and downloads the record over an encrypted channel. The service logs the delivery and the open events.

The practice archives the delivered record and the audit log for the retention period required by state law. The archive is stored on infrastructure covered by a BAA and is available for OCR review on request.

Practices building the full patient communication stack often pair the email service with a secure website. Guidance on security features for healthcare websites covers the portal, form handling, and file upload side of the workflow.

Practical answers to the questions staff actually ask

Can we email a chart to a patient? Yes, with documented patient consent, encryption on the transmission, and a BAA-covered mail service.

Can we email a chart to a referring physician? Yes, without patient consent when the disclosure is for treatment, and with the same encryption and BAA requirements as any external delivery.

Can we email a chart to a patient attorney? Yes, only with a written authorization signed by the patient that identifies the attorney and the scope of records.

Can we email a chart to a family member? Yes, only with a written authorization or a documented emergency exception under 45 CFR 164.510, which allows disclosure to a family member involved in the patient care.

Can we use a personal Gmail account to email a chart? No. Personal accounts have no BAA and are automatically out of compliance regardless of encryption. Every records email must go through a mailbox that is covered by a BAA and a documented practice policy.

[mh_faqs]

Posted on

Encrypted Email Microsoft 365 Setup Guide for 2026

encrypted email microsoft 365 guide featured image

[mh_key_takeaways]

Encrypted email on Microsoft 365 uses Microsoft Purview Message Encryption behind the scenes. The service ships with Business Premium, E3, E5, and F3 plans at no extra cost.

Practices sending PHI to patients or vendors need three things in place. A qualifying license, a signed business associate agreement with Microsoft, and a published sensitivity label that maps to an encryption template. Once those three exist, users see the Encrypt button in Outlook and can send encrypted email from any device.

This guide walks through the setup steps, the license comparison, the sender experience across desktop, web, and mobile, and where the portal-based delivery step creates friction for high-volume patient communication.

Encrypted email Microsoft 365 licensing landscape

Purview Message Encryption ships with Business Premium at $22 per user per month, E3 at $36, E5 at $57, and Frontline F3 at $8. Business Basic at $6 and Business Standard at $12.50 do not include the Encrypt button.

Practices on Basic or Standard have two upgrade paths. Move the tenant to Business Premium for the full compliance stack. Add the Microsoft 365 E3 Compliance add-on at $12 per user per month to gain Purview without paying for Business Premium features the practice does not use.

Nonprofits get 30 to 75 percent off list on every plan through the Microsoft Nonprofits program. Business Premium runs about $5.50 for verified nonprofits. Documentation lives at Microsoft Nonprofits portal.

Confirm the license status in the Microsoft 365 admin center under Billing, Licenses. See Microsoft 365 email encryption setup for the regional configuration walkthrough.

Business associate agreement for encrypted email Microsoft 365

Microsoft signs a business associate agreement with covered entities on qualifying paid plans. The BAA covers Exchange Online, SharePoint Online, OneDrive, Teams, and Purview.

Administrators accept the BAA in the Microsoft 365 admin center. Open Billing, Your Products, then click the Terms link on the eligible plan. Read the BAA in full and click Accept. The tenant is HIPAA-eligible immediately after acceptance.

The BAA does not cover any consumer Outlook.com account or any free Microsoft account. Verify the tenant type in the admin console before treating any mailbox as HIPAA-eligible.

After BAA acceptance, configure the required admin settings. Enable multi-factor authentication for every user. Turn on audit logging in the compliance portal. Set retention that meets the six-year Privacy Rule requirement. Reference the sample BAA at HHS sample BAA provisions.

encrypted email microsoft 365 in article illustration one

Enabling Microsoft 365 email encryption with Microsoft Purview

Sign in to compliance.microsoft.com with a global admin or compliance admin account. Open Information Protection, then Labels.

Click Create Label. Give the label a display name like Confidential, add a description, and pick a color. On the encryption step, choose Assign Permissions Now.

Configure the permission block. Add users or groups, set the permission level, and save the encryption settings. Publish the label to the tenant. Users see the Encrypt button in Outlook after publication.

Test on a pilot user before rolling to production. Send a message from the pilot mailbox to an external Gmail address and confirm the recipient gets the portal notification. Reference Microsoft Purview email encryption for the deep configuration walkthrough.

Sending encrypted email from desktop Outlook

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

Click Encrypt. A dropdown appears with the available permission templates. Pick Encrypt for basic encryption or Do Not Forward for stronger controls that block forwarding and printing.

The composer displays a lock icon at the top and a permission banner near the subject line. Send the message. External recipients get a notification email with a portal link.

If the Encrypt button is grayed out, the tenant does not have a published sensitivity label yet. Check with the admin. See encrypt email Microsoft Outlook for the full sender walkthrough.

[mh_example]

Sending encrypted email from Outlook web

Sign in to outlook.office.com. Compose the message as usual. Click the three-dot menu at the top of the composer, next to the Send button.

Choose Encrypt from the dropdown. A submenu opens with the available permission templates. Pick Encrypt or Do Not Forward. The composer shows a lock icon and a permission banner at the top.

Send the message. The recipient experience matches desktop Outlook. External recipients get a notification email with a portal link.

Outlook web sometimes hides advanced permission templates behind the tenant plan tier. Enterprise E5 tenants see every option. Business Premium tenants see the default four. See Microsoft Outlook 365 encrypt email for the tier-by-tier feature matrix.

encrypted email microsoft 365 in article illustration two

Sending encrypted email from Outlook mobile

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

Tap Encrypt Message. A screen appears with the available permission templates. Pick the template and tap the back arrow to return to the composer.

The lock icon in the composer header confirms encryption is active. Send the message from the mobile composer. The recipient experience matches desktop and web.

Users on personal iPhones sending occasional PHI often struggle with the mobile encryption workflow because the ellipsis menu is not obvious. Train users on the workflow before rollout. Screenshots in the training material help far more than a written procedure.

Recipient experience for Microsoft 365 encrypted email

External recipients get a notification email with a portal link. The notification email includes the sender name, subject line, and a button that opens the portal.

Recipients sign in with Microsoft, Google, or a one-time passcode. The Microsoft option works for anyone with a Microsoft account. The Google option works for anyone with a Google account. The one-time passcode works for anyone else.

Reply from the portal stays encrypted. The reply routes back through Microsoft servers and lands in the original sender inbox as a normal encrypted message.

The friction of the portal step drops adoption. Practices sending 200 patient messages per week often see 30 to 50 first-time recipients need help with the portal. Support ticket volume tracks directly to the portal experience.

[mh_protip]

S/MIME as an alternative encrypted email path on Microsoft 365

S/MIME encryption sits alongside Purview Message Encryption in Microsoft 365. S/MIME uses certificates installed on the sender and recipient devices.

Configuring S/MIME in Microsoft 365 requires the admin to upload the certificate authority chain to the Exchange admin center. Users install their personal certificate in the Windows certificate store or the Outlook mobile app.

S/MIME provides stronger cryptographic guarantees than Purview because the message content decrypts only on the recipient device. Microsoft servers never see the plaintext.

The tradeoff is setup complexity. Most healthcare practices skip S/MIME because patients cannot install certificates. Reference the current S/MIME setup path at Microsoft Learn S/MIME configuration.

Common Microsoft 365 encrypted email problems and fixes

The Encrypt button is grayed out. The tenant does not have a published sensitivity label with encryption enabled, or the user account does not have a Purview-eligible license.

The recipient gets a portal link but cannot log in. The one-time passcode option ships to the same email address the notification came to. Ask the recipient to check the inbox for the passcode message and to check spam if the passcode does not appear.

Attachments open with a permissions error. The permission template applied to the message restricts attachments. Change the template to Encrypt without additional restrictions.

Common troubleshooting checklist:

  • Confirm the license includes Purview Message Encryption
  • Confirm the BAA is accepted in the admin center
  • Confirm at least one sensitivity label is published with encryption
  • Confirm the Outlook client version is current
  • Confirm the recipient inbox is not blocking the portal notification domain

When to layer a zero-step alternative on top of Microsoft 365

Practices with heavy external patient mail volume often outgrow the Purview portal experience. Support ticket volume from patients who cannot log in to the portal starts to eat into clinical time.

A zero-step encryption service like Mailhippo works alongside Microsoft 365. Purview handles internal traffic between mailboxes on the tenant. Mailhippo handles external mail to patients and vendors without a portal step. The two services coexist without a routing conflict.

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

For further reference, review Microsoft Learn Purview Message Encryption, the HHS HIPAA Security Rule, and the HIPAA Journal guide to compliant email before finalizing the Microsoft 365 encrypted email stack. See also Microsoft email encryption and Microsoft Office 365 email encryption for related walkthroughs. See the Mailhippo secure email service overview for the zero-step alternative details.

[mh_faqs]

Posted on

Secure Encrypted Email for Business and Compliance

secure encrypted email guide featured image

[mh_key_takeaways]

A secure encrypted email service does more than TLS. It applies message-level encryption, protects content at rest, provides audit-ready access controls, and, for healthcare and financial use, includes a signed business associate agreement.

The main options include native features in Gmail and Outlook, standalone privacy-focused providers, and purpose-built HIPAA-compliant services. Understanding secure encrypted email starts with the specific threat model and compliance context.

This guide covers the categories, the trade-offs, and the criteria for selecting a service that fits a specific workflow.

Secure Encrypted Email Combines Multiple Protections

A secure encrypted email service protects messages at three layers. Transport, using TLS to secure the connection between mail servers. Content, using message-level encryption so only the recipient can read the plaintext. Storage, using encryption at rest on the mail server.

Beyond encryption, a secure service includes strong authentication for the sender, audit logging for access to encrypted content, spam and phishing filtering to prevent fraudulent messages from reaching the inbox, and, for regulated use, a signed contract with the sender covering handling of protected data.

Some services bundle all of these. Others provide the encryption layer but leave authentication, filtering, and audit logging to the mail platform. Evaluate a service by the completeness of the protection stack, not by any single feature.

According to NIST SP 800-45, secure email systems should enforce authentication of sender identity, protect messages in transit and at rest, and maintain access logs for audit purposes.

Native Encryption in Gmail and Outlook Has Specific Limits

Gmail and Outlook include encryption features, but the availability depends on the plan tier. Gmail supports TLS on every account and S/MIME hosted encryption only on Workspace Enterprise. Outlook supports S/MIME on all desktop-enabled plans and Microsoft Purview Message Encryption on Business Premium and higher.

Neither provider enforces encryption by default. The sender must click Encrypt in Outlook or use Confidential Mode in Gmail to trigger message-level protection. A regular send goes over TLS if available, or plaintext if not.

For HIPAA, both providers offer a business associate agreement at qualifying plan tiers. Microsoft signs a BAA for Microsoft 365 Business Standard and higher. Google signs one for Workspace Business Standard and higher. The BAA covers the platform, but it does not automatically enforce encryption on every send.

secure encrypted email in article illustration one

Privacy-Focused Providers Offer End-to-End Encryption

ProtonMail, Tutanota, and Mailfence provide end-to-end encryption where the provider itself cannot read message content. Messages between users of the same service are encrypted automatically. Messages to external recipients can be sent through a password-protected link.

These services lead for personal privacy. They are the standard recommendation for journalists working with sources, activists in high-risk regions, and users who want encryption that even the service provider cannot bypass.

They are less common for HIPAA-scale healthcare deployments because their business focus is privacy rather than healthcare compliance. Business plans may include a BAA on higher tiers, but the integration with existing Gmail or Outlook accounts is limited.

Sibling coverage on this category is in ProtonMail encrypted email and related provider comparisons.

HIPAA-Focused Services Solve Healthcare Recipient Friction

Purpose-built HIPAA-compliant email services target healthcare and other regulated business use. They include a signed BAA in the base plan without negotiation. They enforce encryption on every send. They handle external recipients through a portal fallback.

Mailhippo is one of these services. It integrates with existing Gmail or Outlook accounts through SMTP relay or a plug-in. The sender writes and sends from their normal client. The service encrypts and delivers over TLS when supported or through a portal link when not.

The recipient experience is a single click on a notification email, a one-time passcode, and a browser view. No account creation, no key management, no software install. This suits patients, external providers, and vendors who cannot be expected to manage certificates.

[mh_example]

Service Category Comparison

Each service category fits a specific use case. The table summarizes the practical trade-offs across the main options for business users evaluating secure encrypted email.

Category End-to-End BAA in Base Plan Recipient Friction Best For
Gmail/Workspace Enterprise only Business Standard and up Low for internal, medium for external Organizations already on Workspace
Outlook/Microsoft 365 S/MIME and Purview Business Standard and up Low for tenant, medium for external portal Organizations already on Microsoft 365
Privacy providers Yes, within service Higher tiers only High for non-users Personal privacy, journalists
HIPAA-focused service Yes, portal-based Yes, base plan Low, click and passcode Healthcare, regulated business

The clearest divide is between platforms and purpose-built services. Platforms bundle encryption with a broader mail service. Purpose-built services focus on the encryption and compliance layer, integrating with an existing mail platform.

secure encrypted email in article illustration two

HIPAA-Compliance Requires More Than Encryption

Encryption is one required control under HIPAA, not the complete picture. HIPAA also requires a signed business associate agreement with any vendor handling PHI, audit logs of access to PHI for six years, access controls limiting who can read PHI, and a documented risk assessment covering the sender infrastructure.

A secure encrypted email service that is HIPAA-ready bundles most of these. The BAA is included. The audit logs are built in. The access controls include multi-factor authentication and role-based permissions. The provider provides documentation supporting the sender risk assessment.

For healthcare organizations that also handle patient acquisition, encrypted email pairs with HIPAA-compliant website design and healthcare website security features as part of the broader compliance stack.

According to the HHS Security Rule, transmission security is addressable, meaning the covered entity must document why any specific method meets the standard for the assessed risk.

Cost Considerations Vary by User Count and Plan

Purpose-built HIPAA-compliant email services typically price at around $10 per user per month for unlimited sends with a signed BAA. Costs scale with user count and vary by feature tier for administrator controls, archive retention, and integrations.

Microsoft 365 Business Premium, which unlocks the Encrypt button, costs around $22 per user per month at published pricing. For a small practice, adding a HIPAA-focused service to Business Standard at around $12.50 plus the service cost is often less than upgrading every seat to Business Premium.

Google Workspace Enterprise Plus, which includes S/MIME hosted encryption, prices significantly higher than Business Standard. Small teams typically add a HIPAA-focused service rather than upgrading the Workspace tier for encryption alone.

Cost decisions should weigh the license price against administrator time. Certificate management for S/MIME is real work. Portal-based services remove that overhead.

[mh_protip]

Enforced Encryption Removes Human Error

The single most impactful design choice in a secure encrypted email deployment is whether encryption is enforced or user-triggered. User-triggered encryption relies on the sender clicking a button before every sensitive send. Enforced encryption applies to every message regardless of user action.

User-triggered systems fail when a sender forgets. This is documented as one of the most common HIPAA breach causes. A sender types a message containing PHI, forgets to click Encrypt, and sends over plaintext or opportunistic TLS.

Enforced-encryption systems apply the protection at the SMTP relay or at the DLP layer, so every outbound message gets checked and encrypted before delivery. This removes the human-error path.

  • Purpose-built HIPAA services enforce encryption at the relay by design.
  • Microsoft Purview supports enforced encryption through a data loss prevention rule.
  • Gmail supports enforced encryption through Content Compliance rules in the Workspace Admin console.
  • Native S/MIME and PGP are user-triggered by default.

Verification and Audit Support the Compliance Case

A secure encrypted email deployment needs to prove it worked. Audit logs, delivery reports, and encryption-status tracking are the evidence a compliance reviewer looks for.

Microsoft 365 provides Message Trace and the Purview compliance portal. Google Workspace provides Email Log Search and BigQuery export. Purpose-built services provide their own admin portals with access logs, delivery status, and per-recipient audit trails.

For a HIPAA risk assessment, the reviewer will ask for evidence that encryption was applied consistently over the assessment period. The audit log is the answer to that question.

According to HIPAA Journal, audit-log gaps are one of the most common findings in Office for Civil Rights investigations.

Choose Based on Recipient, Volume, and Compliance Bar

The decision framework for selecting a secure encrypted email service reduces to a few practical questions. Who are the recipients? How many messages per week? What compliance framework applies? What is the tolerance for user error?

  • Recipients are internal certified users only: S/MIME with corporate certificates.
  • Recipients include external patients or vendors without technical setup, HIPAA scope: purpose-built service with portal fallback.
  • Recipients are on the same Microsoft 365 tenant: native Encrypt button plus a service for external mail.
  • High volume of regulated mail, low tolerance for human error: enforced encryption at the relay.

For healthcare organizations coordinating email security with the broader marketing and web stack, encrypted email deployment pairs with healthcare marketing services.

The final rule is that the cheapest secure encrypted email service is the one that fits the specific workflow. Match the service to the recipients, the volume, and the compliance requirement. Verify enforcement, log access, and review the audit trail on a set schedule.

[mh_faqs]

Posted on

Encrypting an Email Explained From Setup to Recipient View

encrypting an email guide featured image

[mh_key_takeaways]

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.

[mh_example]

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.

[mh_protip]

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.

[mh_faqs]

Posted on

Encrypting Emails in Outlook

encrypting emails in outlook guide featured image

[mh_key_takeaways]

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.

[mh_example]

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.

[mh_protip]

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.

[mh_faqs]

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

© 2026 MailHippo, Inc.

View our Privacy Policy or contact our Customer Service team.

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