🔑 Key Takeaways
- Any email tying a patient to care falls under the Security Rule; TLS alone is not a safe baseline.
- Three real methods: native Encrypt button, third-party gateway, or portal-only service beyond email.
- Verify three things before sending: plan supports encryption, BAA is signed, recipient can decrypt.
- Content-based DLP rules catch missed manual toggles; run them alongside staff-triggered encryption.
- OCR asks for procedure, training, and audit logs; undocumented encryption looks the same as none.
An email that names a patient and mentions their care is protected health information. Send it outside the practice’s network and HIPAA’s Security Rule expects encryption.
How to encrypt an email containing PHI depends on the sender’s platform and plan tier. Some paths take one click, others need certificate setup, and a few require the practice to route mail through a HIPAA-compliant secure email service that handles the encryption automatically.
This guide covers the three practical methods, the setup steps for each, and the documentation the practice needs to prove the workflow to an OCR investigator if a question ever arises.
Recognize what makes an email a PHI email
PHI is any information tied to an identifiable person plus a health, treatment, or payment detail. Name and diagnosis. Name and lab result. Name and appointment for a specific service.
A chart number by itself qualifies if it can be linked back to a person. So does a birthdate paired with a partial name. So does a photo of a treatment site with any identifying context.
Internal messages count. A note to a colleague that says the patient in room three had an abnormal EKG is PHI. So is a scheduling note that includes a patient’s name and appointment reason.
The safest rule is to treat any message that could reveal a specific person’s care status as PHI. Encryption on a routine message costs nothing. Missing a PHI message and shipping it in cleartext can trigger a breach.
Confirm the account and BAA before sending
An email account cannot handle PHI unless the provider has signed a business associate agreement with the covered entity. Personal gmail.com and outlook.com accounts do not qualify.
Google Workspace, Microsoft 365, Mailhippo, Paubox, and similar business-tier providers offer BAAs. The BAA takes effect only after the covered entity signs it, and it covers only the services listed in the agreement.
Check the BAA before sending. On Google Workspace, the acceptance record is in the Admin console under Account, Legal and compliance. On Microsoft 365, it is in the Service Trust Portal. Keep a copy in the practice’s compliance folder.
If the BAA is not in place, encryption alone does not solve the problem. The provider handling the message is a business associate under HIPAA, and without a BAA, that relationship is unauthorized.
Method one: encrypt from Gmail with a hosted service
The Gmail path most practices use combines a paid Google Workspace plan with a hosted encryption service. Mailhippo, Virtru, and Paubox all connect to a Gmail account and encrypt outbound mail without a plan upgrade to Enterprise Plus.
Setup takes about ten minutes. The user signs up with the service, authorizes access to the Gmail account through OAuth, and installs a browser extension if required. Some services work through SMTP relay and require no extension.
Once connected, the user composes messages in the normal Gmail interface. The service encrypts the message before delivery, and external recipients receive a portal link.
Test with a personal address on a non-compliant server before rolling out. Confirm the recipient sees the portal link, opens the message, and can reply. Practices comparing the manual and automated options often review can i encrypt an email guides to see how each toggle behaves.
Method two: encrypt from Outlook with the Encrypt button
On Microsoft 365 Business Premium or higher, the Encrypt button appears on the message ribbon. Click it before sending to apply Purview Message Encryption.
Two options appear: Encrypt Only for standard message-level encryption, and Do Not Forward for encryption plus a restriction against the recipient forwarding or copying the message.
External recipients receive a link and sign in with Microsoft, Google, or a one-time passcode sent to their address. The message opens in a Microsoft-hosted portal.
If the button does not appear, Azure Rights Management may not be activated on the tenant. A super administrator can enable it under Settings, Org settings, Services, Microsoft Azure Information Protection.
Method three: encrypt automatically with content rules
Both Google Workspace and Microsoft 365 support data loss prevention rules that trigger encryption based on message content. The rules run on the gateway, not on the client, so they apply regardless of whether the user remembered to toggle.
Common patterns to match: Social Security number formats, ICD-10 code prefixes, credit card patterns, and specific keywords like patient chart numbers or the phrase PHI in the subject.
Google Workspace calls the feature Content compliance and configures it under Apps, Google Workspace, Gmail, Compliance. Microsoft 365 calls it DLP policy and configures it in the Purview compliance portal.
Rules can encrypt, block, or warn. Most practices start with warn to see what the rule catches, then move to encrypt once the rule pattern is tuned. Content rules cover the human-error gap that manual toggling leaves open.
Verify the recipient can actually open the message
The most common encryption failure is a compliant send that the recipient cannot open. S/MIME messages arrive as a gibberish attachment on clients that do not support S/MIME. Portal messages require a working browser and a recipient willing to click a link.
Before sending PHI to a new external recipient, send a test message. Ask the recipient to confirm they received a readable message. Log the successful test in the patient’s chart if the practice audits patient communications.
For recipients who cannot open the encrypted message, the practice needs a fallback path. That is usually a phone call to walk through the portal, or a physical mail delivery, or a secure patient portal upload.
Never send PHI in cleartext as a fallback. The Security Rule does not accept convenience as a justification for skipping encryption.
Handle attachments the same way as body content
An unencrypted attachment on an encrypted email is still an unencrypted attachment. Some encryption tools encrypt the message body but leave attachments in the clear. Check the tool’s documentation.
Purview Message Encryption encrypts attachments. Mailhippo encrypts attachments. Native S/MIME encrypts the entire message including attachments. Gmail Confidential Mode does not encrypt attachments in any real sense.
PDF files, DICOM images, and lab reports are the common attachment types in clinical mail. Each contains PHI and each needs the same encryption coverage as the body.
For very large attachments, a secure file transfer service is often better than email. Practices that send imaging studies often route them through a dedicated portal rather than trying to email a 500-megabyte DICOM series.
Log every encrypted send for audit purposes
An OCR investigation asks for proof that the practice encrypted PHI messages. Proof means audit logs from the email platform showing which messages were encrypted, when, and to whom.
Google Workspace logs message-level actions in the Admin console under Reports, Audit, Email log search. Microsoft 365 logs are in the Purview compliance portal under Audit.
Hosted encryption services keep their own logs. Mailhippo, Virtru, and similar services show each encrypted send with a timestamp, recipient, and delivery status.
The HHS guidance on risk analysis and NIST SP 800-66 Rev. 2 both point to logging as a required component of Security Rule compliance. Practices without logs cannot prove they were compliant.
Document the workflow and train staff annually
A two-page written procedure covers most practice needs. Name the tool, the trigger, the recipient handling, the fallback for recipients who cannot open the message, and the annual review date.
Train every staff member who touches patient email at least once a year. Log the training. Track new hires through the same training within their first 30 days.
The training should include a live send to a personal address, so staff see what a compliant message looks like from both sides. Reading a policy is not the same as sending a real message.
Practices building the wider healthcare marketing and website posture around the email workflow often engage a specialist. Firms focused on healthcare marketing and healthcare website security features keep the intake forms, the patient portal, and the outbound clinical mail on the same compliance footing.
- Confirm a signed BAA is in place before sending any PHI.
- Choose one primary encryption method and one fallback.
- Enable content-based DLP rules to catch missed manual toggles.
- Test with a real external recipient before rolling out to staff.
- Log every encrypted send and keep the logs for at least six years.
Knowing how to encrypt an email containing PHI is a combination of the right platform, the right method, and the discipline to apply it every time. Automated rules and gateway services do the last part more reliably than trained humans, and the practices with the cleanest audit records lean on both.
