HIPAA compliant email is any email system configured to protect patient health information through a combination of encryption, access controls, audit logging, and a signed legal agreement with the email provider. There is no single certified “HIPAA email” product. Instead, compliance comes from how you set up and use the service, not the service itself.
This matters because HIPAA’s Security Rule is deliberately technology-neutral. It never names a specific email platform or encryption protocol as required. It sets standards, and you choose how to meet them. That flexibility is useful, but it also means the responsibility for compliance falls squarely on you and your organization.
The Business Associate Agreement Comes First
Before any technical setup, you need a signed Business Associate Agreement (BAA) with your email provider. A “business associate” under HIPAA is any person or company outside your workforce that handles protected health information (PHI) on your behalf. Your email provider stores, transmits, and processes messages containing PHI, which makes them a business associate. Without a BAA in place, using that service for PHI-containing email violates HIPAA regardless of how strong your encryption is.
The BAA is a contract that spells out exactly how the provider can and cannot use PHI, limits their disclosures, and makes them directly liable under HIPAA. Business associates face civil and, in some cases, criminal penalties for unauthorized uses or disclosures, and for failing to safeguard electronic PHI. This is not a formality. It is the legal backbone of compliant email.
Most mainstream providers offer a BAA, but only on certain plan tiers. Google Workspace customers must have an administrator review and accept a BAA through the Admin console under Account settings before using any Google service with PHI. Microsoft includes its HIPAA BAA as part of the Online Services Data Protection Addendum, available by default for qualifying cloud plans like those that include Exchange Online. If your email provider won’t sign a BAA, you cannot use that service for PHI.
Encryption: In Transit and At Rest
Encryption is the technical safeguard most people associate with HIPAA email, but it actually covers two distinct situations: data moving between servers (in transit) and data sitting in a mailbox or on a hard drive (at rest).
For in-transit security, the standard is Transport Layer Security (TLS) 1.2 or higher. TLS encrypts the connection between mail servers so that anyone intercepting traffic between point A and point B sees only scrambled data. Most major email providers already use TLS by default, but the critical step is configuring your system to require it rather than simply prefer it. If the receiving server doesn’t support TLS, a “prefer” setting will silently fall back to an unencrypted connection, and your message travels in plain text.
For at-rest encryption, AES with 256-bit keys is the widely used standard. This protects messages stored on servers, so a breach of the email provider’s infrastructure doesn’t expose readable PHI.
For higher-risk communications, such as messages sent to outside organizations or business partners, adding message-level encryption through protocols like S/MIME or PGP provides end-to-end security. Unlike TLS, which protects the connection, these protocols encrypt the message content itself. Even if a mail server is compromised, the actual text of the email remains unreadable to anyone without the decryption key. The key difference: TLS protects the pipe, while S/MIME and PGP protect the letter inside it.
Access Controls and Authentication
HIPAA’s access control standard requires that only authorized people or software can reach electronic PHI. For email, this translates into several practical requirements.
- Unique user identification. Every person accessing the email system needs their own login credentials. Shared accounts make it impossible to track who accessed what, which violates both the access control and audit standards.
- Strong authentication. Passwords alone are a weak link. Multi-factor authentication, where users verify their identity with a second method like a phone-based code, is the practical standard for meeting HIPAA’s person-or-entity authentication requirement.
- Automatic logoff. Email sessions should terminate after a set period of inactivity. This prevents unauthorized access on unattended devices, a common real-world exposure point in clinics and shared workstations.
Microsoft’s compliance guidance specifically recommends using its identity management tools to enforce strong authentication, MFA, and role-based access controls so only authorized staff can reach PHI in email. Google similarly publishes a HIPAA implementation guide for administrators configuring Workspace.
Audit Logs and Monitoring
HIPAA requires you to implement mechanisms that record and examine activity in any system containing electronic PHI. For email, this means maintaining logs that show who accessed which messages, when, and from where. If a breach occurs, or if an auditor asks, you need to be able to demonstrate that you are tracking and reviewing email activity.
The rule does not specify exactly how long to retain these logs, but it does require that your approach be risk-based. You need documented policies explaining which systems are audited, how auditing decisions are made, and what procedures govern the review process. Microsoft’s Purview features, for example, allow administrators to apply retention policies and data lifecycle management tools specifically to email content containing PHI. Whatever platform you use, the key is that logging isn’t just turned on but actively reviewed.
Integrity Protections
Beyond preventing unauthorized access, HIPAA requires protections against improper alteration or destruction of electronic PHI. For email, this means your system should have mechanisms to confirm that a message hasn’t been tampered with during transmission or storage. Digital signatures, checksums, and similar verification tools satisfy this requirement. Most enterprise email platforms handle this at the infrastructure level, but your organization still needs a written policy addressing integrity controls.
Common Mistakes That Break Compliance
Many HIPAA email violations come from everyday habits rather than technical failures. The most common:
Putting PHI in the email subject line. Subject lines are the most visible part of any email. They appear in inbox previews, lock screen notifications, and browser tabs. They are also not encrypted by most email systems, even when the message body is. A subject line reading “Lab results for John Smith, DOB 4/12/1985” exposes PHI before anyone opens the message. Keep subject lines generic.
Failing to train staff. Technical safeguards only work if the people using the system understand the rules. Staff need current, documented training on your email policies: what can be sent, how to handle PHI, how to recognize phishing attempts, and what to do if they suspect a breach. An encrypted email platform operated by untrained staff is not compliant.
Assuming your provider handles everything. Signing a BAA and turning on encryption are necessary but not sufficient. HIPAA compliance is a shared responsibility. The provider secures the infrastructure; you configure it correctly, manage access, train your team, and maintain policies. A provider’s BAA does not cover your failure to set strong passwords or your staff forwarding PHI to personal accounts.
Using Gmail or Outlook for HIPAA Email
You do not need a specialized “HIPAA email” vendor. Gmail and Outlook can both be configured for compliance, but the free consumer versions are not sufficient.
For Google, you need a paid Google Workspace plan. A super administrator must navigate to Account settings, then Legal and compliance, and accept the BAA. From there, Google publishes a HIPAA implementation guide covering how to organize and protect PHI across Workspace services. Only services listed on Google’s HIPAA Included Functionality page are covered by the BAA.
For Microsoft, you need a Microsoft 365 or Office 365 plan that includes Exchange Online. The BAA is included by default through the Online Services Data Protection Addendum. Microsoft recommends using its compliance tools to assess your current configuration against HIPAA-related controls and track improvement actions. The Compliance Manager includes a premium HIPAA/HITECH assessment template specifically for this purpose.
In both cases, signing up and accepting the BAA is only the starting point. You still need to configure encryption settings, enable MFA, set up audit logging, apply retention policies, and train every user with access.
When Patients Want Unencrypted Email
HIPAA does not prohibit unencrypted email between providers and patients. The Privacy Rule allows electronic communication as long as reasonable safeguards are applied. If a patient initiates an email conversation, the provider can assume the patient finds email communication acceptable unless they explicitly say otherwise.
That said, providers should limit the amount and type of PHI disclosed through unencrypted channels. If you have concerns that a patient doesn’t understand the risks of unencrypted email, you can alert them and let them decide whether to continue. If a patient requests confidential communications and finds unencrypted email unacceptable, you are required to offer alternatives: a more secure electronic method, postal mail, or phone.
This exception applies to patient-directed communication. It does not cover emails between providers, between a provider and an insurer, or any other non-patient exchange. Those require full technical safeguards.