Can You Email PHI Under HIPAA? Rules, Safeguards & Common Mistakes
Yes, you can email PHI under HIPAA — but not without meeting specific safeguards first. The question most practices get wrong is not whether email is permitted, it is what kind of protection is required, when you need patient consent, and what common shortcuts will expose you to a breach. This guide walks through what the rules actually say, what a compliant email setup looks like in practice, and the mistakes that keep showing up in OCR enforcement actions.
HIPAA Rules for Emailing PHI: What You Need to Know
HIPAA does not prohibit email. What it does require is that when you transmit electronic protected health information (ePHI) over open networks — and standard email qualifies as an open network — you must implement reasonable and appropriate safeguards under 45 CFR 164.312(e)(1). In plain terms: you need to protect the information in transit.
What those safeguards look like depends on who is on the other end of the email and what those parties have agreed to. The Security Rule's encryption standard is listed as "addressable" rather than required (45 CFR 164.312(e)(2)(ii)), which trips people up. Addressable does not mean optional — it means you must either implement it or document why an equivalent alternative provides the same protection. In practice, for email transmission of ePHI, encryption is the only reasonable choice. Everything else is difficult to defend to OCR.
Transport Encryption vs. End-to-End Encryption
These two terms are not interchangeable, and the distinction matters for HIPAA compliance.
Transport Layer Security (TLS) encrypts the connection between mail servers while the message is in transit. When both sending and receiving mail servers support TLS (sometimes called opportunistic TLS or forced TLS), the message is encrypted while moving between servers. This is the minimum baseline for transmitting ePHI between covered entities and business associates — for example, from a hospital's EHR system to a specialist's practice email. Most enterprise email platforms support forced TLS configurations.
End-to-end encryption (E2EE) encrypts the message content so that only the intended recipient can decrypt it. The message remains encrypted at rest on both ends, and the email provider itself cannot read it. This is the stronger standard and is required in higher-risk scenarios — particularly when emailing patients at personal consumer accounts (Gmail, Yahoo, Outlook.com) where you cannot verify or control TLS on the receiving end.
A practical approach for many organizations is to use a HIPAA-compliant email platform (covered below) that handles forced TLS for provider-to-provider communication and wraps patient-facing messages in a secure message portal that requires the recipient to authenticate before reading.
When Patient Consent Changes the Equation
HIPAA includes an important provision that often gets overlooked: patients have the right to request that you communicate with them through an alternative means or at an alternative location under 45 CFR 164.522(b). This includes requesting to receive communications via unencrypted email.
If a patient affirmatively requests that you send their PHI to their personal Gmail account without encryption, you may honor that request — even though the transmission would otherwise not meet the standard safeguard level. The key requirements are:
- The request must come from the patient (not from the practice as a default policy)
- You must advise the patient of the privacy risk before agreeing
- The patient's consent and the risk disclosure must be documented
- The consent applies to that patient's preference only — you cannot use this as a blanket justification for unencrypted patient email across your practice
HHS has confirmed this position in guidance, noting that covered entities are not in violation of the Privacy Rule when they accommodate a patient's request for unencrypted email, as long as the risks are communicated and the request is documented. What you cannot do is default to unencrypted email and claim implied consent because patients gave you their email address.
HIPAA-Compliant Email Services vs. Standard Email Platforms
Standard consumer and business email platforms — Gmail, Microsoft Outlook (personal), Yahoo Mail — are not HIPAA-compliant out of the box for transmitting ePHI. The issue is not just encryption; it is also the Business Associate Agreement (BAA).
Any email platform that stores, processes, or transmits ePHI on your behalf is a business associate under 45 CFR 164.308(b)(1). You need a signed BAA in place before using that platform to handle ePHI. Without it, the transmission itself may be a HIPAA violation regardless of whether the content was encrypted.
Google Workspace (enterprise tier) and Microsoft 365 Business both offer BAAs and support forced TLS and message encryption configurations. Standard Gmail and personal Outlook accounts do not support BAAs and should never be used for ePHI.
Purpose-built HIPAA-compliant email services go further. Platforms like Paubox, Virtru, and Hushmail for Healthcare offer end-to-end encryption by default, deliver messages through secure portals for patient-facing communication, provide BAAs as standard, and generate audit logs of message activity. For practices that send ePHI regularly — lab results, referrals, appointment notes — these platforms are worth the investment. A single breach investigation will cost far more.
When evaluating any email platform for ePHI use, verify three things before go-live: (1) a signed BAA is in place, (2) forced TLS is configured for outbound transmission, and (3) the platform generates audit-ready logs.
PHI in Email Subject Lines
Subject lines are not encrypted by standard TLS. TLS encrypts the body and attachments in transit, but subject lines are often handled differently depending on the email system and can appear in server logs, notification previews, and metadata that travels outside the encrypted channel.
This means putting PHI — a patient name, diagnosis, appointment reason, date of birth, or any other identifier — in an email subject line is a high-risk practice even when the body of the message is encrypted. Organizations should establish a clear policy: no PHI in subject lines, ever. Generic subjects like "Your Appointment Information" or "Secure Message from [Practice Name]" are the right approach.
This is one of the most common mistakes OCR has cited in investigations, and it is entirely preventable with a policy and basic training.
Auto-Forwarding to Personal Email
Auto-forwarding work email to a personal account is one of the most common and overlooked HIPAA risks in small and mid-sized practices. It typically happens when a staff member sets up forwarding to their personal Gmail or Yahoo account for convenience — often without telling anyone — and every message containing ePHI from that point forward is transmitted to an uncontrolled, non-BAA-covered account.
From a HIPAA standpoint, each forwarded email containing ePHI is a separate impermissible disclosure. Depending on volume and the nature of the PHI involved, this can quickly escalate from a policy violation to a reportable breach.
A practical approach is to audit email forwarding rules on your practice's email platform at least annually — and any time an employee departs. Most enterprise email platforms allow administrators to view and disable auto-forwarding rules across all accounts. Disabling user-initiated forwarding entirely is a reasonable technical control for accounts that routinely handle ePHI.
CC'ing the Wrong Recipients
Misdirected email is a persistent source of small breaches. It happens when staff use autocomplete and select the wrong contact, when a patient's old email address is in the system, when CC fields include recipients who should not see the PHI, or when email threads are forwarded with prior ePHI-containing exchanges included at the bottom.
Several OCR-investigated incidents have involved nothing more than a misaddressed email containing a handful of patients' lab results. The breach notification obligations — notifying affected individuals within 60 days, filing with HHS — apply regardless of how simple the error was.
Practical controls that reduce misdirected email risk include:
- Disable email autocomplete for external domains on accounts that handle ePHI
- Require a second review before sending email to new or external recipients containing ePHI
- Train staff to strip prior email chains before forwarding when ePHI appears in the thread
- Use a secure message portal (rather than direct email) for all patient-facing ePHI delivery, so misdirected portal notifications do not expose the PHI itself
What Happens When You Send PHI to the Wrong Person
Despite best efforts, misdirected ePHI emails happen. When they do, the response matters as much as the event itself.
The first step is to contact the unintended recipient as quickly as possible and request that they not read, forward, or retain the message, and that they delete it. Get that request in writing if possible. Document the date, time, and nature of the communication.
Next, conduct the four-factor risk assessment required under the Breach Notification Rule (45 CFR 164.402). This assessment evaluates: the nature and extent of the PHI involved, who the unintended recipient was, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated. If you can demonstrate low probability of compromise, the incident may qualify as a non-reportable privacy incident rather than a breach — but that determination must be documented, not assumed.
If the four-factor assessment does not support a low-probability conclusion, the incident is a reportable breach. Notification to affected individuals is required within 60 days of discovery. If 500 or more individuals are affected, HHS must also be notified within 60 days via the breach reporting portal, and media notice may be required.
The encryption safe harbor is relevant here: if the ePHI was encrypted to NIST standards at the time of the misdirection and the unintended recipient does not have the decryption key, the incident does not constitute a breach under the Breach Notification Rule. This is one of the strongest practical arguments for using proper end-to-end encryption — it removes the breach notification obligation for many accidental disclosure scenarios.
The Encryption Safe Harbor
The Breach Notification Rule at 45 CFR 164.402 defines "unsecured PHI" as PHI that has not been rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified in HHS guidance. HHS guidance references NIST Special Publication 800-111 for data at rest and NIST SP 800-52/800-77 for data in transit.
When ePHI in an email is encrypted to those standards and the unintended recipient cannot decrypt it, the Breach Notification Rule is not triggered. This is the encryption safe harbor, and it is the single most important reason to implement proper email encryption rather than treating it as a nice-to-have.
The safe harbor only applies if the encryption was in place before the incident. Encrypting after the fact, or claiming the recipient would not know how to decrypt the file, does not satisfy the standard. The protection must be built into the transmission process — not applied reactively.
Practical Steps for Small Practices
Many small practices run on standard email platforms without realizing the exposure. Here is a practical starting point that does not require a large technology budget:
Step 1: Audit your current email setup. Identify every email account used by your practice. Determine which accounts receive, send, or store ePHI. Check whether a BAA is in place with your email provider. If you are on standard Gmail or personal Outlook accounts, that needs to change before anything else.
Step 2: Get a BAA with your email provider. If you use Google Workspace, Microsoft 365 Business, or a comparable platform, request or activate the BAA through your account settings. If your provider does not offer a BAA, find one that does. This is non-negotiable for any account that handles ePHI.
Step 3: Enable and enforce TLS. Work with your IT contact or email administrator to configure forced TLS on outbound mail. Most enterprise platforms support this. For inbound, you can configure TLS requirements as well, though this requires coordination with senders.
Step 4: Adopt a HIPAA-compliant email service for patient-facing communication. For communications that go directly to patients — lab results, records, appointment-related ePHI — use a purpose-built platform that handles end-to-end encryption and secure delivery automatically. This removes the need to manually evaluate each patient's email setup before every send.
Step 5: Establish and train on email policies. Written policies should cover: no PHI in subject lines, no auto-forwarding to personal accounts, required second review before sending ePHI to external recipients, and the procedure for responding to a misdirected email. Train every staff member before they handle ePHI via email — not after an incident.
Step 6: Document patient email consent requests. If patients request unencrypted email delivery, build a standard form that captures the request and documents the risk disclosure. Retain it in the patient record. Do not accept verbal-only consent for this.
For a broader view of technical safeguards beyond email, the HIPAA encryption requirements guide covers what the Security Rule requires across all ePHI transmission and storage scenarios.
Real Enforcement: What OCR Has Acted On
Email-related HIPAA enforcement is more common than many practices realize. Most cases do not become headline news, but they do result in financial penalties and multi-year corrective action plans.
In 2019, OCR reached a $3 million settlement with Touchstone Medical Imaging following an incident where ePHI was accessible over the internet due to a misconfigured FTP server. While that case centered on FTP rather than email, the underlying finding — failure to implement adequate technical safeguards for ePHI in transit — applies directly to email transmission of ePHI without encryption.
In 2020, OCR settled with Bayfront Health St. Petersburg for $85,000 after a patient complaint. The pattern across many small-practice enforcement actions is the same: a preventable technical configuration or a staff behavior — auto-forwarding, misdirected email, unencrypted transmission — goes unaddressed until it creates a reportable incident.
The HHS enforcement highlights page is worth reviewing periodically. The cases against small practices consistently involve failures that reasonable email hygiene and a HIPAA-compliant platform would have prevented.
For a complete look at how OCR calculates penalties and what factors they weigh, the HIPAA fines and penalty amounts guide breaks down the current tier structure.
A Note on Business Associate Email
The rules above apply to covered entities. Business associates — billing services, IT vendors, transcription companies, and other third parties that handle ePHI — are bound by the same Security Rule obligations under 45 CFR 164.314(a). If your business associate is emailing ePHI on your behalf, the BAA between you must address email security obligations. You cannot outsource the compliance risk by sending it to a vendor.
When onboarding new business associates, ask directly: what email platform do you use for ePHI? Do you have TLS forced? How do you handle misdirected ePHI emails? If they cannot answer these questions, that is a signal to look more carefully at the BAA and the relationship. The Business Associate Agreement guide covers what the BAA must require from vendors handling ePHI, including email.
FAQs
Can you email PHI under HIPAA?
Yes. HIPAA does not prohibit emailing PHI. It requires that the transmission be protected with appropriate safeguards — primarily encryption in transit, a signed BAA with the email provider, and policies governing how email is used. The specific safeguard level depends on who is receiving the email and whether patient consent for an alternative method has been documented.
Is Gmail HIPAA compliant for sending patient information?
Standard personal Gmail accounts are not HIPAA compliant and should never be used to send or receive PHI. Google Workspace (the paid business version of Gmail) can be made HIPAA compliant if you have a signed BAA with Google and configure the platform with appropriate security settings including forced TLS. Standard @gmail.com consumer accounts do not qualify because Google does not offer a BAA for those accounts.
What encryption does HIPAA require for email?
The Security Rule lists email encryption as an addressable specification under 45 CFR 164.312(e)(2)(ii), which means covered entities must either implement it or document an equivalent alternative. In practice, encryption is the only defensible approach. For provider-to-provider communication, forced TLS between servers is the standard baseline. For patient-facing communication to consumer accounts, end-to-end encryption or a secure message portal is recommended because TLS on the patient's end cannot be verified or controlled.
Can a patient request to receive their PHI via unencrypted email?
Yes. Under 45 CFR 164.522(b), patients have the right to request confidential communications through alternative means. If a patient specifically requests that you send their information to their personal email without encryption, you may honor that request — but you must first advise them of the privacy risk, document their informed request, and keep that documentation in their record. This applies to that individual patient only and cannot be used as a blanket practice policy.
What should I do if I accidentally sent PHI to the wrong email address?
Act immediately. Contact the unintended recipient and request that they delete the message without reading or forwarding it. Document that contact. Then conduct the four-factor risk assessment under the Breach Notification Rule to determine whether the incident is reportable. If the PHI was properly encrypted and the recipient lacks a decryption key, the encryption safe harbor may apply and the incident may not constitute a breach. If the message was unencrypted, assume it is reportable and begin the notification process — affected individuals must be notified within 60 days of discovery.
Is putting a patient's name in an email subject line a HIPAA violation?
It creates meaningful compliance risk. Subject lines are generally not covered by the same encryption protections as email body content and can appear in server logs, message previews, and metadata. Putting a patient's name, diagnosis, date of birth, or other PHI identifier in a subject line — even when the body is encrypted — is a practice that OCR has cited in investigations. Organizations should adopt a policy of using only generic subject lines for any email that may contain ePHI.
Does my practice need a BAA with our email provider?
Yes, if that email account is used to send, receive, or store PHI. Any email provider that has access to ePHI in the course of providing services to your practice is a business associate. Without a signed BAA, using that platform to handle PHI is a HIPAA violation regardless of whether the content is encrypted. Most major enterprise email providers — Google Workspace, Microsoft 365 Business — offer BAAs. Verify that one is in place before using any email platform for ePHI.
Conclusion
Emailing PHI is permitted under HIPAA, but the safeguards required are not automatic — they have to be deliberately configured, documented, and enforced. The practices that stay out of trouble are the ones that treat email hygiene as an operational standard rather than an IT afterthought: signed BAAs with email providers, forced TLS enabled, no PHI in subject lines, auto-forwarding disabled, and a clear procedure for when something goes wrong. That is achievable for practices of any size.
One Guy Consulting helps healthcare organizations build the policies, training, and documentation that make HIPAA email compliance practical and sustainable. Book a demo to see how the platform handles policy distribution, annual training, and compliance tracking — all in one place.
This content is for educational and informational purposes only and should not be construed as legal advice.
Sources
- 45 CFR 164.312 — Technical Safeguards
- 45 CFR 164.522 — Rights to Request Privacy Protection for PHI
- 45 CFR 164.402 — Definitions (Breach Notification Rule)
- HHS FAQ — Does HIPAA Permit Email to Discuss Medical Information?
- HHS Guidance on Breach Notification for Unsecured PHI
- NIST SP 800-52 Rev. 2 — Guidelines for TLS Implementations
- HHS HIPAA Enforcement Highlights
- HHS — Touchstone Medical Imaging $3 Million Settlement (April 2019)
Related Reading: