HIPAA-Compliant Email: What Qualifies and What Quietly Fails

Ask a practice manager whether the office email is HIPAA compliant and the usual answer is some version of "yes, we're on Microsoft 365 and we signed the BAA." That covers roughly one of the three things that have to be true, and the parts it skips are where audit findings tend to come from.

The core idea of this post is simple. A business associate agreement makes an email platform eligible to carry PHI. Configuration is what makes it safe to do so. A tenant with a signed BAA and untouched default settings is not a compliant system; it is a finding that simply has not been written up yet. This article takes the email section of our HIPAA compliance and healthcare IT guide into working detail: what has to be true for email to qualify, the quiet failures that undo compliance at otherwise careful practices, the patient-consent rule most offices misread in one direction or the other, and a configuration checklist you can give to whoever manages your tenant.

Compliant email stacks three requirements, and every one must hold at the same time:

1. An eligible plan. Microsoft 365 and Google Workspace both offer a BAA, but only on qualifying business and enterprise plans. Consumer accounts and some entry-level plans cannot get one at any price, which means they cannot carry PHI at all. Check the plan name printed on your current invoice rather than what you remember buying years ago. How the two platforms compare on plans and licensing for regulated businesses is covered in our Microsoft 365 vs. Google Workspace comparison.
2. A BAA that has been executed. On both platforms you accept the agreement deliberately, through the admin console or your reseller. Paying for the subscription does not put it into force. Practices regularly learn during an audit that they have been on an eligible plan for years without ever accepting the agreement. Confirm it, keep written proof and file it alongside your other agreements. What the BAA does and does not require of the vendor is explained in our guide to business associate agreements.
3. Configuration. Nobody sells this part, because it is labor rather than a product: enforced encryption in transit and at rest, data loss prevention rules, retention policies, MFA on every mailbox, and audit logging that is switched on and read. Most of this article is about this layer, since it is where "licensed" and "compliant" drift apart.

Fail the first test and there is no agreement to accept. Fail the second and no agreement is in effect. Fail the third and an agreement is in effect over a system that leaks. Only all three together hold up under review.

Nothing in the Security Rule tells you to buy a particular product. It requires access controls, transmission security, audit controls and integrity protections for ePHI. On an email platform, those requirements translate into specific settings, and these are the ones that count:

Encryption, in transit and at rest. Both major platforms encrypt stored data in their data centers and attempt TLS for mail in transit by default. The catch is that opportunistic TLS drops to plaintext when the receiving server will not negotiate it. A compliance-grade setup enforces protection for mail that contains PHI, using policy-based message encryption that keeps a sensitive message protected no matter what the recipient's server supports.

Data loss prevention (DLP). DLP rules inspect outgoing mail for telltale patterns such as medical record numbers, Social Security numbers, diagnosis codes, or a patient name paired with a date of birth, and they act before the message leaves: encrypting it automatically, warning the sender, or blocking it and alerting a compliance contact. DLP is the control that catches honest mistakes, which is where a large share of email incidents begin. Without it, the tenant depends on every staff member getting every message right, permanently.

Multi-factor authentication. A stolen email password is one of the easiest ways into a practice's systems. MFA on every mailbox, with no exemption for the physician who finds it a nuisance and none for the shared front-desk account discussed below, is the most valuable single setting in the tenant. Cyber insurers treat it as a baseline requirement too.

Retention policies. Deletion governed by policy instead of by individual inbox cleanup. Retention gets its own section below because it is a records question as much as a storage one.

Audit logging. The platform can record who opened which mailbox, which rules were created and what was forwarded where. Logging that was never enabled, or that runs but is never reviewed, is how an auto-forward attack can go unnoticed for months.

The failures that hurt are rarely dramatic. They are sensible-looking habits that carry PHI outside the boundary your BAA and settings protect. Four patterns come up again and again when practice email gets reviewed:

Forwarding to personal accounts. An employee sends tomorrow's schedule to a personal Gmail address to get ahead from home. The intent is good and the result is a reportable incident: the PHI now sits in a consumer account with no BAA, outside your encryption, DLP, retention and audit trail. This is among the most frequent email problems in small practices, and it is almost never malicious, so the fix is DLP rules and a clear written policy rather than discipline.

Auto-forward rules. These are worse than one-off forwards because they are systematic and invisible. Sometimes a user creates one for convenience. Just as often, an attacker who briefly gets into a mailbox adds a forwarding rule as a lasting wiretap, a standard move in business email compromise. From then on every message is copied out of the tenant. The remedy is configuration: block external auto-forwarding for the whole tenant, and alert on any new forwarding rule so that exceptions are made on purpose.

Unencrypted attachments. The mailbox may be protected while the habits are not. Someone exports records to a PDF and attaches it without encryption, one autocomplete slip away from the wrong recipient. Records requests, referrals and billing disputes produce this constantly. DLP that recognizes attachments containing PHI and forces encryption or a secure link shuts the door.

Shared mailboxes reached through one login. A shared mailbox such as frontdesk@ or referrals@ is often a sound design. The problem is a shared password: when five people sign in with one credential, the audit trail shows a single anonymous user, MFA protects only whoever holds the password, and departing staff never lose access. Set shared mailboxes up with delegated access from individual accounts and the same workflow becomes compliant.

None of these is a platform defect, and the BAA has nothing to say about any of them. Each is a configuration or policy gap, which is exactly the layer that "we signed the BAA" leaves out.

Practices misjudge patient email in both directions. Some refuse to email patients at all, citing HIPAA, which frustrates patients and misstates the rule. Others email freely on the theory that a patient's reply authorizes anything, which misstates it too.

The rule itself is precise. A patient may ask to receive communications by unencrypted email, and the practice may honor that request after warning the patient of the risk and documenting both the warning and the request. The right belongs to the patient, applies only to that patient and only by their choice, and is not a general license to send PHI in the clear. The fact that a patient emailed first is not documentation.

The safer standard, and the one we suggest practices adopt across the board, is the secure-link pattern. The email itself carries no PHI, only a notice and an authenticated link, while the content stays in the patient portal or a secure message viewer. Patients make one extra click. In return, a misaddressed email exposes nothing, a forwarded email carries nothing, and the sensitive material stays inside a system you control. Reserve documented-consent unencrypted email for patients who specifically ask for it and route everyone else through the link.

Two related boundaries are worth keeping in view. Marketing email is a separate regime: sending promotional messages to patient lists raises authorization requirements this article does not cover, so treat any plan to email patients about a new service as a compliance question first. Texting is a different discipline again. Standard SMS is not encrypted, and the consent, platform and policy rules for compliant patient texting, along with phone and voicemail, are covered in Talk Is Cheap's guide to HIPAA-compliant communications. Email rules do not carry over to those channels.

Retention is where compliance meets records management, and most practices have never made a deliberate decision about it.

Two clocks apply. HIPAA requires compliance documentation (policies, risk assessments, authorizations and the correspondence that evidences them) to be kept for six years. Separately, email that forms part of a patient's designated record set, such as clinical exchanges with the patient, referral correspondence or documentation of care decisions, falls under medical-record retention rules, which in Texas generally means at least seven years for adult patients and longer for minors.

In operational terms, retention should run on policy, not on whoever tidies their inbox. Set retention rules in the platform so mail is kept for the required periods and disposed of on schedule afterward. Retention cuts both ways: mail kept forever stays discoverable forever, and a compromised mailbox holding fifteen years of patient correspondence becomes a fifteen-year breach. Litigation hold matters here as well. Qualifying business plans include it, which is one more reason the plan test above is not a formality.

Give this list to whoever administers your tenant, whether on staff or at your IT provider, and ask for it back with each item marked done, scheduled, or not applicable with a reason. That dated, filed document is exactly the kind of evidence an audit rewards.

Identity and access

• MFA enforced on every account, including administrators and users with delegated shared-mailbox access
• No shared logins; shared mailboxes reached only through delegated individual access
• Same-day offboarding for departing staff, including removal of mobile mail profiles
• Administrator accounts kept separate from everyday mailboxes

Encryption

• Message encryption available and triggered by policy for PHI, not left to each sender's judgment
• Enforced rather than opportunistic encryption for defined sensitive mail flows
• Mobile devices that access mail required to be encrypted and PIN-protected

Data loss prevention

• DLP policies active for PHI patterns in message bodies and attachments
• External auto-forwarding disabled across the tenant, with alerts on new forwarding rules
• Warn and block behavior defined and tested with a sample message

Retention

• Retention policies that match your written schedule (the six-year HIPAA documentation floor, plus state medical-record rules where they apply)
• Litigation hold confirmed as available on your plan
• Deletion controlled by policy, not by user habit

Audit

• Unified audit logging enabled and confirmed working
• A named person, internal or at your IT provider, who reviews unusual sign-ins and rule changes
• Written confirmation of the executed BAA filed with your other agreements

Email is the system every employee uses every hour, which makes it one of the easiest places for PHI to leak and one of the places where careful setup pays off most in a compliance program. The pattern is the same one that runs through the full HIPAA guide: the paperwork makes you eligible, the configuration makes you defensible, and the documentation proves both.

If you would rather not work through the checklist alone, this is standing work for our compliance support team and part of how Talos manages Microsoft 365 and Google Workspace for healthcare clients. We review the tenant against these categories, close the gaps and give you the findings in writing, the before-and-after record an auditor wants to see. Either way, run the checklist: a signed BAA protects only as well as the tenant behind it. To get started, contact Talos or email info@talosautomation.ai.

Either one can be, and neither is compliant out of the box. Three conditions must hold together: an eligible business plan (consumer accounts and some entry-level plans offer no BAA at all), a BAA that has been deliberately accepted, and real configuration, meaning enforced encryption in transit and at rest, DLP rules, retention policies, MFA on every mailbox and audit logging. A tenant with a BAA and default settings is licensed, not compliant.

No. The BAA governs what the platform vendor must do; it says nothing about how your tenant behaves. A tenant with a signed BAA and no configuration can still auto-forward PHI to personal addresses, send unencrypted attachments and run shared logins that erase the audit trail. The agreement is necessary, and the configuration is what protects the data.

Yes, with care. HIPAA allows email with patients, and a patient may ask for unencrypted email after being warned of the risk, as long as the warning and the request are documented and the arrangement covers only that patient. For everyone else the safer default is a secure-link pattern, where the email carries an authenticated link and the PHI stays in the portal.

Four keep recurring: staff forwarding work mail to personal accounts to work from home, auto-forward rules (set by a user for convenience or planted by an attacker) that copy mail out of the tenant, unencrypted PDF attachments of records sent to the wrong person, and shared mailboxes accessed through a single shared login, which destroys the audit trail HIPAA expects. DLP, forwarding restrictions and delegated access close all four.

HIPAA requires compliance documentation to be kept for six years. Email that is part of a patient's designated record set falls under medical-record retention rules instead, which in Texas typically means at least seven years for adults and longer for minors. Set retention policies in the platform so preservation and deletion follow the schedule rather than individual inbox habits.