HIPAA Compliant Email Encryption: A Practical Guide (2026)

Email is the way most patient information leaves a practice. Referral letters, X-rays sent to a specialist, lab results, insurance appeals, statements, records requests: it all goes out by email, usually from a busy front desk. It's also one of the most common ways patient data ends up where it shouldn't.

The good news is that HIPAA doesn't ban email, and you don't need an expensive specialist system to do it properly. If your practice runs on Microsoft 365, you may already pay for everything you need. The bad news is that "we use Outlook, so we're fine" isn't an answer, and neither is a little lock icon nobody can explain.

This guide covers when HIPAA expects you to encrypt email, the different kinds of encryption (and which ones actually protect you), how to set up Microsoft Purview Message Encryption step by step, how to handle patients who just want a normal email, third-party options, and a policy template you can adapt.

Does HIPAA require email encryption?

HIPAA requires you to protect patient data sent by email, and encryption is the expected way to do it, but the current rule doesn't mandate one specific technology. Encryption is an "addressable" specification, which means you must use it unless you document a good reason not to and use an equivalent alternative.

Three parts of the rules matter here:

1. The Security Rule's transmission security standard (45 CFR 164.312(e)) requires "technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network." Its two implementation specifications, integrity controls and encryption, are both addressable.
2. HHS's own answer in FAQ 2006: the Security Rule "does not expressly prohibit the use of email for sending e-PHI," and allows e-PHI to be sent over an open network "as long as it is adequately protected." You're expected to assess the risk, choose a solution and document the decision.
3. The Privacy Rule (HHS FAQ 570) allows providers to email patients with "reasonable safeguards," such as checking addresses and limiting the information included.

What "addressable" means in practice

"Addressable" is not "optional." Under the Security Rule, you must look at each addressable item, decide whether it's reasonable and appropriate for your practice, and then either implement it, or write down why not and what you're doing instead.

For email, it's very hard to argue that encryption isn't reasonable. It's built into Microsoft 365 Business Premium and Google Workspace's higher tiers, it costs little or nothing extra, and staff can use it with one click. An auditor reading "we decided encryption wasn't reasonable" in 2026 is going to ask hard questions.

Why encryption also protects you after a mistake

There's a second, very practical reason to encrypt: breach notification. HHS's breach guidance says PHI encrypted to its standards (which reference NIST guidance, including NIST SP 800-52 for TLS) is "secured," and the breach notification rules only apply to unsecured PHI. If an encrypted email goes astray, you'll still investigate and document, but you're far less likely to be sending letters to patients and reporting to HHS.

Proposed rule changes

In January 2025, HHS proposed updating the Security Rule to remove the "addressable" category and require encryption of ePHI in transit, with limited exceptions. As of our check on October 5, 2026, that proposal has not been finalized; the federal regulatory agenda lists July 2027 as the target for a final rule. Read our article on the proposed Security Rule changes for details. Either way, encrypting email now puts you ahead of any change.

When should you encrypt an email?

Encrypt any email that contains patient information and leaves your organization, unless the patient has asked for unencrypted email or you've confirmed an enforced secure channel with the recipient. Internal email between users in the same Microsoft 365 tenant stays within Microsoft's covered cloud and is a lower risk.

Here's a decision guide we give front-desk teams:

The most common failure isn't a lack of encryption technology. It's a busy staff member not knowing which of these situations they're in. That's why the setup section below leans on automatic rules, not memory.

TLS vs end-to-end vs portal encryption: what's the difference?

There are three main ways email gets encrypted, and they protect different things. TLS protects the trip between servers. End-to-end encryption protects the message itself from sender to recipient. Portal encryption keeps the message on a secure server and lets the recipient read it there.

TLS (Transport Layer Security)

TLS encrypts the connection between two mail servers, like an armored truck between banks. Microsoft 365 and Google use it by default whenever the other side supports it.

• Strength: Invisible to users and to patients. Nothing to click.
• Weakness: It's usually opportunistic. If the receiving server can't do TLS, the message may go unencrypted. TLS also protects only the trip; once the message lands in the recipient's mailbox, it's stored however their provider stores it. And your staff can't see whether a given message traveled encrypted.
• Best use: Regular partners where you can enforce TLS. Exchange Online lets you create a connector that requires TLS for a specific domain and rejects mail if a secure connection can't be made. That's a good option for a hospital, lab or billing company you email every day.

End-to-end encryption (S/MIME and PGP)

End-to-end encryption scrambles the message on the sender's device and only the recipient's device can unscramble it. S/MIME and PGP are the two traditional standards.

• Strength: The strongest protection. Even the mail providers can't read it.
• Weakness: Both sides need certificates or keys set up in advance. Patients almost never have them. In practice it works between organizations that set it up deliberately, not with the public.
• Best use: Rarely the right tool for a small practice.

Portal or message-level encryption (Microsoft Purview Message Encryption and similar)

Message-level encryption encrypts the message and its attachments with rights-management technology. Recipients on compatible systems read it directly; everyone else gets a link to a secure portal where they verify who they are.

• Strength: Works with any recipient: Gmail, Yahoo, iCloud, anyone. Protects the message even if the recipient's mailbox isn't encrypted. Can be applied automatically by rules.
• Weakness: Patients on non-Microsoft email have to click a link and sign in or enter a passcode. A few find that confusing at first.
• Best use: Patients, specialists, attorneys and anyone you don't have an enforced TLS relationship with. This is the workhorse for most practices.

Side-by-side comparison

Most well-run practices use all three tiers: TLS everywhere as a baseline, enforced TLS for the few partners they email constantly, and message encryption for everything else that contains PHI.

How to set up Microsoft Purview Message Encryption

If your practice has Microsoft 365 Business Premium, or Microsoft 365 or Office 365 E3/E5, Microsoft Purview Message Encryption is already included and usually already switched on. Business Basic and Business Standard need the Azure Information Protection Plan 1 add-on to get it, according to Microsoft's Purview service description.

Microsoft Purview Message Encryption is the current name for what many people still call OME (Office 365 Message Encryption). It's built on Azure Rights Management, it's covered by Microsoft's HIPAA BAA, and recipients don't need a Microsoft subscription to read or reply. (If you're not sure what your Microsoft 365 setup covers overall, start with our article on whether Microsoft 365 is HIPAA compliant.)

Step 1: Confirm your license

In the Microsoft 365 admin center, go to Billing > Your products and check that every user who emails patient information has Business Premium, E3/E5, or the add-on. Message encryption is licensed per sender.

Step 2: Confirm encryption is active

Microsoft says that in most eligible tenants, Azure Rights Management is activated automatically and message encryption turns on with it. To check:

1. Connect to Exchange Online PowerShell with an admin account.
2. Run Get-IRMConfiguration and confirm AzureRMSLicensingEnabled is True.
3. Run Test-IRMConfiguration -Sender you@yourpractice.com -Recipient you@yourpractice.com and confirm the overall result is PASS.

If you're not comfortable with PowerShell, this is a five-minute task for your IT provider.

Step 3: Create a keyword rule staff can trigger

The simplest habit to teach is a keyword in the subject line.

1. Open the Exchange admin center > Mail flow > Rules.
2. Create a rule: If the subject includes "[secure]" and the recipient is outside the organization, then Apply Office 365 Message Encryption and rights protection with the Encrypt template.
3. Add an exception if needed, for example for your own internal test address.
4. Test it by sending to a Gmail account you control.

Pick one keyword and stick with it. Practices that allow "secure," "encrypt," "[encrypt]" and "confidential" end up with staff who aren't sure which one works.

Step 4: Add automatic encryption for sensitive content

Relying on staff to remember the keyword will fail on a busy Monday. Add a rule that catches sensitive content automatically:

1. In the Microsoft Purview portal, create a data loss prevention (DLP) policy for Exchange.
2. Use Microsoft's built-in sensitive information types, such as U.S. Social Security numbers, and health-related identifiers relevant to your practice.
3. Set the action for external recipients to encrypt the message and show the sender a policy tip explaining what happened.
4. Run it in simulation mode for a week or two, look at what it would have caught, then turn it on.

DLP for Exchange is included in Business Premium and E3/E5. On Business Standard, a mail flow rule that looks for sensitive information types is a more limited alternative.

Step 5: Show staff the Encrypt button

In Outlook (desktop, web and mobile), staff can encrypt any message manually:

• Outlook on the web and new Outlook: Select Encrypt in the message toolbar (sometimes under the Options tab or a padlock icon), then choose Encrypt or Do Not Forward.
• Classic Outlook for Windows: Options > Encrypt, then choose the option.

Encrypt-Only protects the message but lets the recipient forward or print it, which is usually what patients and other providers need. Do Not Forward also blocks forwarding, printing and copying in supporting apps. Use it for highly sensitive material, not by default, because patients often legitimately need to send records on to another doctor.

Step 6: Set up TLS-enforced connectors for frequent partners

For the hospital, lab or billing company you email daily:

1. Confirm with their IT team that they support TLS (almost all do).
2. In the Exchange admin center > Mail flow > Connectors, create a connector from Office 365 to the partner's domain that requires TLS.
3. Test, then document the connector in your risk analysis as your transmission safeguard for that partner.

Mail to those partners is then protected automatically, with no portal and no extra clicks.

Step 7: Customize the recipient experience (optional)

The default encrypted message notice is plain and branded as Microsoft. Patients sometimes mistake it for phishing. You can customize the notice text in Exchange Online PowerShell (the OMEConfiguration settings) to include your practice's name, logo and phone number. Multiple branding templates, automatic expiration and revocation of portal messages are part of Advanced Message Encryption, which Microsoft includes in E5-level plans, not Business Premium.

Step 8: Tell patients what to expect

A short line on your website, intake forms and patient portal helps: "When we email you health information, it will arrive as a secure message from [Practice Name]. Click the link, then sign in with your email account or request a one-time code." Staff should be able to walk a patient through it on the phone.

What the patient sees

• Patient uses Outlook with a Microsoft 365 or Outlook.com account: the message opens normally.
• Patient uses Gmail or Yahoo: they get a notice email with a Read the message button. They sign in with their Google or Yahoo account, or choose Sign in with a one-time passcode and get a code by email.
• Patient uses another provider, like a local ISP or iCloud: they use the one-time passcode option.
• On phones: the portal works in a mobile browser.

Replies from the portal are encrypted too, so patients can answer you securely.

Sending email to patients: what HIPAA allows

Patients can choose how they get their own information, including regular unencrypted email, as long as you warn them about the risk first. This trips up a lot of practices, who either refuse patients' email requests outright or email everything unencrypted without asking.

Two patient rights are involved:

The right of access

Under 45 CFR 164.524, patients have a right to copies of their records in the form and format they request, if readily producible. HHS's right of access guidance and FAQ 2060 make several points clear:

1. Patients can ask for their records by unencrypted email. You can't refuse just because your policy prefers encryption.
2. You should warn them. HHS says a brief warning is enough: that there's some risk the information could be read by a third party in transit. You don't need to give a lecture on encryption.
3. If they still want it, send it. Once warned, if the patient confirms, you send it the way they asked.
4. You're not responsible for interception in transit. HHS has said that in that situation the covered entity isn't responsible for unauthorized access during transmission. You're still responsible for sending it to the right address.

Under the current rule, you generally have 30 calendar days to respond to an access request, with one 30-day extension if needed. HHS proposed shortening this in 2021; as of October 2026 that change has not been finalized.

The right to confidential communications

Under 45 CFR 164.522(b), patients can ask you to communicate with them by alternative means or at alternative locations, and providers must accommodate reasonable requests. A patient who says "please only email my work address" or "don't email me, call my cell" is using this right.

A simple workflow for the front desk

1. Ask at intake: "How would you like us to send you health information: secure email, the patient portal, or regular email?" Record the answer in your practice management system.
2. If they choose regular email: read or show a short warning (see the template below) and record that they confirmed.
3. Verify the address. Send a test message, or have them reply to a confirmation email, before sending anything sensitive.
4. Default to secure. If there's no recorded preference, use encryption.
5. Re-confirm periodically, for example annually, or when they change their email address.

Sample patient warning language

"You've asked us to send your health information by regular email. Regular email isn't encrypted, so there's some risk it could be read by someone else while it travels over the internet or if your email account is accessed by others. We can send it securely instead at no cost to you. Would you still like to receive it by regular email?"

Record the date, the staff member, and the patient's answer. That record is your protection.

What about sending to other providers, insurers and labs?

For treatment, payment and operations, you can email other providers and business partners, but you're expected to protect the message in transit. HIPAA doesn't give other organizations the same right patients have to waive encryption.

• Use enforced TLS connectors for high-volume partners.
• Use message encryption for everyone else.
• Use payer and hospital portals when they exist. They usually come with their own access controls and audit trails.
• Apply minimum necessary. Send the records needed for the referral, not the entire chart.
• Check the address. Autocomplete is a leading cause of misdirected email. Consider turning off or regularly clearing autocomplete suggestions for staff who send a lot of external PHI.

Third-party HIPAA email encryption options

If you're not on Microsoft 365 Business Premium, or you want features Purview doesn't offer, there are specialist HIPAA email services. They generally fall into three groups, and any of them will need to sign a BAA with you.

Before choosing one, ask:

1. Will you sign a BAA, and what does it cover?
2. What does the patient see, and how many steps does it take to open a message?
3. Can it encrypt automatically based on content, or only when staff remember?
4. Does it keep logs showing a message was delivered and opened?
5. What happens to messages if we cancel the service?
6. Does it duplicate something we already pay for in Microsoft 365?

That last question matters. We frequently find practices paying for a separate encryption service while also paying for Business Premium, which already includes Purview Message Encryption.

What does HIPAA email encryption cost?

On Microsoft 365 Business Premium or E3/E5, message encryption costs nothing extra. On Business Basic or Standard, you need the Azure Information Protection Plan 1 add-on per sender, or a third-party service. Specialist HIPAA email services are typically priced per user per month and vary by features and volume.

We don't publish list prices here because they change. Microsoft's pricing is on its website, and third-party vendors usually quote directly. When comparing, include:

• The per-user cost of encryption for every staff member who sends PHI
• Whether upgrading to Business Premium also gets you device management, endpoint protection and Conditional Access you'd otherwise buy separately
• Setup time and staff training
• The cost of a single misdirected unencrypted email that turns into a breach investigation

Our Microsoft 365 plan picker can help you compare.

How to test your email encryption setup

Test from the recipient's side, not just the sender's. A rule that looks right in the admin center can still fail because of a typo, an exception, or a rule order problem. Run these tests after setup and again at least once a year, and keep a note of the results.

1. Keyword test. Send a message with "[secure]" in the subject to a Gmail account and a Yahoo account you control. Confirm both arrive as encrypted notices, and that you can open them with the account sign-in and with a one-time passcode.
2. Automatic DLP test. Send a message containing a test Social Security number (a made-up number in the correct format, never a real patient's) to an external address. Confirm it's encrypted and the sender sees a policy tip.
3. Internal test. Send the same content to a colleague inside the practice. Confirm the behavior matches your policy (usually not encrypted, or encrypted without friction).
4. Reply test. Reply from the portal and confirm the reply arrives in the practice mailbox and is still protected.
5. Attachment test. Send a PDF and an image attachment, including a large X-ray file, and confirm the recipient can download both.
6. Mobile test. Open an encrypted message on an iPhone and an Android phone using the mail app the patient is most likely to use.
7. Connector test. For any TLS-enforced connector, check Exchange message trace to confirm messages to that partner show a TLS connection. Ask the partner to confirm receipt.
8. Forwarding test. Try to set up an automatic forward from a test mailbox to an outside address. It should be blocked.

If anything fails, fix it before you tell staff the system is ready. Nothing undermines a new process faster than the first patient calling to say "I can't open your email."

How to train staff on encrypted email

A 15-minute session at a staff meeting covers what most front-desk and clinical staff need. Training is a required administrative safeguard under the Security Rule, and it's also what makes the technology actually get used. Keep it practical:

1. Why it matters (2 minutes). Email is the most common way patient information leaves the practice. One misdirected email can mean a breach investigation, letters to patients and a report to HHS.
2. When to encrypt (3 minutes). Walk through the decision table above with real examples from your practice: referrals, lab results, statements, records requests.
3. How to encrypt (4 minutes). Show the Encrypt button live in Outlook. Show the "[secure]" keyword. Show what the policy tip looks like when DLP catches something.
4. What the patient sees (3 minutes). Open an encrypted message in a Gmail account on screen, so staff can talk patients through it on the phone.
5. Patient preferences (2 minutes). How to read the warning, where to record the choice, how to verify an address.
6. When things go wrong (1 minute). Tell the privacy officer immediately. No blame for reporting quickly.

Have everyone sign an attendance sheet or acknowledge it electronically. Repeat it annually and for every new hire. Our phishing quiz is a good companion for the inbound side of email security.

How email encryption fits into your risk analysis

Your HIPAA risk analysis should list email as a system that transmits ePHI, describe the risks, and record the safeguards you chose. That entry is what an auditor or OCR investigator will ask for first. It doesn't need to be long. A clear entry might read:

System: Microsoft 365 Exchange Online (email). BAA: Microsoft DPA, downloaded [date].

ePHI involved: Referrals, lab results, statements, records requests, insurance correspondence.

Risks: Interception in transit; misdirected email; account takeover through phishing; forwarding to personal accounts; staff not applying encryption.

Safeguards: TLS by default; TLS-enforced connectors for [lab, hospital]; Microsoft Purview Message Encryption via Outlook button and "[secure]" keyword; DLP policy auto-encrypting messages with SSNs and health identifiers; external auto-forwarding blocked; MFA and Conditional Access for all accounts; Defender for Office 365 anti-phishing; annual staff training.

Patient preferences: Recorded in practice management system; warning script on file.

Residual risk: Low to moderate. Main remaining risk is human error in addressing. Next review: [date].

If you're building or refreshing your risk analysis, our HIPAA security risk assessment guide walks through the whole process, and email is a good place to start because the risks are easy to picture.

Email encryption policy template

Your policy should say when encryption is required, how staff apply it, how patient preferences are handled, and what to do when something goes wrong. Adapt this to your practice; it's written for a small office on Microsoft 365.

[Practice Name] Email and Encryption Policy

Purpose. To protect patient information sent by email, in line with the HIPAA Security Rule (45 CFR 164.312(e)) and Privacy Rule.

Scope. All workforce members who send or receive email on behalf of [Practice Name].

1. Approved email systems. Only practice-provided Microsoft 365 email accounts may be used for practice business. Personal email accounts must never be used to send, receive or store patient information. Automatic forwarding to external addresses is disabled.

2. When encryption is required. Any email containing patient information sent to a recipient outside [Practice Name] must be encrypted, unless (a) it is sent to a partner with an approved TLS-enforced connection listed in Appendix A, or (b) the patient has requested unencrypted email under section 4.

3. How to encrypt. Use the Encrypt button in Outlook, or include "[secure]" in the subject line. Messages containing Social Security numbers or other sensitive identifiers are encrypted automatically by the practice's data loss prevention policy. Use Do Not Forward only for highly sensitive information.

4. Patient preferences. Patients may choose secure email, the patient portal, or regular email. If a patient requests regular email, staff must give the standard warning, confirm the request, and record it in the patient's account. Staff must verify a patient's email address before sending health information.

5. Minimum necessary. Include only the information needed for the purpose. Do not put diagnoses or treatment details in subject lines. Do not email Social Security numbers unless required.

6. Verify recipients. Double-check every external address before sending. Do not rely on autocomplete for external recipients.

7. Suspicious email. Do not open unexpected attachments or links. Report suspicious messages to [Privacy/Security Officer] using the Report button.

8. Mistakes. If you send patient information to the wrong person or unencrypted by mistake, tell [Privacy/Security Officer] immediately. Do not try to handle it alone. The practice will investigate and decide whether notification is required.

9. Training. All workforce members receive training on this policy at hire and annually.

10. Review. This policy is reviewed annually and after any significant change. Approved by: ________ Date: ________

Appendix A: Approved TLS-enforced partners. [Lab name, domain, date verified]

Keep signed copies and training records for six years, as required by 45 CFR 164.316.

Mistakes we see with HIPAA email

Most email problems are about habits and settings, not missing technology. These come up again and again:

1. Assuming the lock icon means encrypted. Staff see "TLS" or a lock somewhere and assume the message is protected end to end.
2. Personal email "just this once." Sending a referral from a personal Gmail account because the work account wasn't loading.
3. Forwarding rules. A former employee's mailbox still forwarding everything to their personal address. Or an attacker's hidden rule doing the same after a phishing attack.
4. PHI in the subject line. Subject lines aren't always encrypted and show up in notifications and previews. "Results for Jane Smith, HIV panel" should never be a subject.
5. Too many keywords. Five different trigger words and nobody sure which one works.
6. Refusing patients' email requests. Telling a patient "we can't email you, HIPAA doesn't allow it." That's not accurate and can violate their right of access.
7. No record of patient preferences. Sending unencrypted email to patients who asked for it, but with nothing written down to prove it.
8. Paying twice. A third-party encryption service on top of Business Premium, with half the staff using one and half the other.
9. No phishing protection. Encryption protects outbound mail. It does nothing against the inbound phishing email that steals a staff member's password. The FBI's Internet Crime Complaint Center reported more than $3 billion in business email compromise losses in 2025 alone (IC3 2025 Internet Crime Report). Our phishing and business email compromise guide covers the inbound side.

Scenario walk-throughs

A dental office sending X-rays to an oral surgeon

The front desk needs to send a panoramic X-ray and treatment notes to an oral surgeon down the road. The surgeon's office uses a different email provider.

What to do: Attach the images, put "[secure]" in the subject (or click Encrypt), and send. The oral surgeon's staff click the link and read it in the portal, or in Outlook if they're on Microsoft 365. If the two offices exchange referrals weekly, set up a TLS-enforced connector between the domains and the process becomes invisible. Our dental office IT guide covers imaging workflows in more detail.

A medical practice emailing lab results to a patient

A patient asks the nurse to email her recent bloodwork. Her chart shows no recorded email preference.

What to do: Default to secure email and tell her to expect a secure message. If she says she'd rather just get a normal email, read the warning, record her choice, confirm her address with a test message, then send. Next time, her preference is in the chart.

A patient asks for their entire record by Gmail

A patient requests a full copy of their records sent to their Gmail address, unencrypted, because they had trouble with the portal.

What to do: This is their right. Warn them briefly, confirm, record it, and send within the HIPAA time limit. If the file is too large for email, offer a secure download link or another format they agree to.

Something goes wrong

A billing coordinator sends an unencrypted statement with procedure codes to the wrong patient with a similar name.

What to do: Tell the privacy officer immediately. Try to recall the message (this only works within your own organization, so don't count on it). Contact the unintended recipient, ask them to delete it and confirm in writing. Then do the four-factor risk assessment HIPAA requires to decide whether it's a reportable breach, and document the decision either way. Our HIPAA breach response plan guide walks through it. Afterward, look at what would prevent a repeat: a DLP rule, turning off autocomplete for that user, or a second check for statements.

Texting and other messaging

The same principles apply to text messages and chat. Standard SMS text isn't encrypted, so the same patient-preference approach applies: patients can choose to receive appointment reminders or even limited information by text after a warning, and you should document it. For clinical communication between staff, use a tool covered by a BAA, such as Microsoft Teams in your Microsoft 365 tenant, rather than personal phones' text messaging. Our HIPAA Security Rule checklist covers messaging alongside other safeguards.

The bottom line

HIPAA-compliant email isn't complicated once it's set up:

1. Use a business email system with a BAA (Microsoft 365 or Google Workspace), never personal accounts.
2. Keep TLS on as a baseline, and enforce it for the partners you email most.
3. Use message encryption, ideally Microsoft Purview Message Encryption if you're on Business Premium, for patient data going outside your practice, triggered automatically by rules wherever possible.
4. Respect patients' choices, including unencrypted email, after a short warning that you document.
5. Write it down in a policy, train staff, and keep the records.

If you'd like help setting up encryption, DLP rules and connectors in your Microsoft 365 tenant, or reviewing what your current email setup really protects, see our healthcare IT services and compliance services, try our free email security checker, or book a free 20-minute call.