HIPAA Email Authentication: Does §164.312 Actually Require DMARC?
No — HIPAA does not explicitly require DMARC. The HIPAA Security Rule (45 CFR §164.312) is technology-neutral and never names DMARC, SPF, or DKIM. But its required §164.308(a)(1) risk analysis, applied to internet email, makes DMARC and TLS the de-facto baseline. That is the honest answer to the HIPAA-and-DMARC question, and it is the one the strongest sources lead with rather than hedge around.
This guide is for the IT admins, compliance leads, and founder-operators at covered entities and business associates who send ePHI over email and need to get HIPAA email authentication right without overstating what the law says. It is the only page that maps each §164.312 sub-paragraph to the specific protocol that helps satisfy it, plus what the December 2024 NPRM would change. Want to skip ahead and see where your domain stands? You can check your domain against HIPAA-relevant email controls first, then come back for the why.
Does HIPAA require DMARC? The honest answer
No HIPAA regulation names DMARC, SPF, or DKIM — but “addressable” does not mean “optional,” and the required risk analysis behind §164.312 almost always lands on email authentication as a reasonable and appropriate safeguard. So does HIPAA require DMARC? Not by name. In practice, yes-you-should.
The word “email” does not appear anywhere in the regulatory text of §164.312. Encryption in transit lives only at §164.312(e)(2)(ii) (“Encryption (Addressable)”). A targeted review of the December 2024 NPRM confirms the rule is deliberately technology-neutral: DMARC, SPF (Sender Policy Framework, RFC 7208), DKIM (RFC 6376), and “DomainKeys” appear nowhere in its complete acronym table, which lists comparable controls like MFA, NIST, and CISA but none of the three email-authentication protocols.
In short: a required risk analysis forces you to either deploy email authentication or document an equivalent. The obligation comes from a chain, not a named control:
- §164.306(a) — general security requirements.
- §164.306(d)(3) — the addressable decision process.
- §164.308(a)(1)(ii)(A) — the required risk analysis.
The Security Rule’s own definitions set the rules of that chain — when a standard includes addressable specs, a covered entity or business associate must:
…(A) Implement the implementation specification if reasonable and appropriate; or (B) If implementing… is not reasonable and appropriate— (1) Document why… and (2) Implement an equivalent alternative measure if reasonable and appropriate. (45 CFR §164.306(d), eCFR)
A competent risk analysis of open-network email will almost always conclude that SPF, DKIM, DMARC, and TLS are “reasonable and appropriate.” That is why the accurate framing is “not explicitly required, but expected once you document your risk decision” — not the overstated “DMARC is required” you will see on some vendor pages.
What §164.312 technical safeguards actually say about email
The HIPAA technical safeguards at §164.312 define five standards — access control, audit controls, integrity, person-or-entity authentication, and transmission security — yet only two implementation specs are flatly Required (unique user ID and emergency access). Everything touching encryption, transmission integrity, and authenticating ePHI is Addressable.
In plain language, the five §164.312 standards read like this. Access control (a)(1) restricts ePHI systems to authorized identities. Audit controls (b) record and examine activity in systems that use ePHI. Integrity (c)(1) protects ePHI from improper alteration or destruction. Person-or-entity authentication (d) verifies that a person or entity is the one claimed. Transmission security (e)(1) guards ePHI moving over an electronic communications network.
“Addressable” is where most people misread the rule. Per HHS, “The ‘addressable’ designation does not mean that an implementation specification is optional… Where it is reasonable and appropriate, the regulated entity must adopt the addressable implementation specification.” And email is explicitly allowed for ePHI under those conditions — HHS FAQ #2006 states the Security Rule “does not expressly prohibit the use of email for sending e-PHI,” provided access control, integrity, and transmission security are satisfied.
One distinction matters for the §164.312 mapping that follows: encryption and authentication are different controls, and you need both. Per NIST SP 800-177 (Trustworthy Email), TLS protects the confidentiality and integrity of a message in transit, while SPF, DKIM, and DMARC authenticate the sending domain to guard against spoofing. Interception and forgery are different threats, so a robust setup deploys both layers.
Mapping DMARC, SPF, DKIM, and MTA-STS to §164.312: the email-auth table
This is the cross-reference no competitor publishes: each §164.312 sub-paragraph paired with the email-authentication control (and RFC) that helps satisfy it. It turns a vague “best practice” into a control-by-control map.
| §164.312 ref | Spec (R/A) | Plain-language requirement | Email-auth control that helps satisfy it | RFC |
|---|---|---|---|---|
| (a)(1) / (a)(2)(i) Access control / Unique user ID | Standard / Required | Allow access only to authorized identities | SPF and DKIM establish sending identity; DMARC alignment ties them to the domain | RFC 7208, RFC 6376 |
| (b) Audit controls | Standard | Record and examine activity in systems using ePHI | DMARC RUA/RUF aggregate and forensic reporting gives a domain-level audit trail of who sent mail as you | RFC 7489 |
| (c)(1) / (c)(2) Integrity / Authenticate ePHI | Standard / Addressable | Protect ePHI from improper alteration; corroborate it was not altered | DKIM’s cryptographic signature detects in-transit body and header tampering | RFC 6376 |
| (d) Person or entity authentication | Standard | Verify a sender is who they claim to be | DMARC alignment plus enforcement (p=quarantine or p=reject) blocks spoofed senders of your domain | RFC 7489 |
| (e)(1) / (e)(2)(i) Transmission security / Integrity controls | Standard / Addressable | Guard ePHI in transit; prevent undetected modification | MTA-STS enforces TLS; TLS-RPT reports downgrade and failure; DANE pins certs via DNSSEC | RFC 8461, RFC 8460, RFC 6698/7672 |
| (e)(2)(ii) Encryption | Addressable | Encrypt ePHI in transit when appropriate | TLS for SMTP, enforced by MTA-STS or DANE | RFC 8461, RFC 7672 |
Read every row as “this protocol helps satisfy this safeguard” — never “the regulation requires this protocol.” The mapping is our analytic cross-reference, not a regulatory claim. Two rows deserve a closer look:
- (d) Person or entity authentication is the row most people skip. DMARC enforcement policies explained shows why
p=nonedoes not actually stop spoofed mail — onlyp=quarantineorp=rejectdoes. - (e) Transmission security is where TLS alone is not enough. Opportunistic TLS can be stripped; MTA-STS for transmission security enforces it and TLS-RPT reports when a downgrade happens, while DANE pins certificates via DNSSEC.
How common is the gap this table describes? It is the norm, not the exception.
40.8% of domains publish no email authentication at all (2,243,877 of 5,499,028 scanned)
In the same scan, only 12.8% of domains enforce DMARC with p=quarantine or p=reject — see our state-of-email-authentication study for the full dataset. The §164.312(d) person-or-entity-authentication gap is the default state of the internet — see the full DMARC enforcement gap breakdown for the per-protocol numbers — which is exactly why a risk analysis of email keeps landing on the same controls.
Is email HIPAA-compliant? Encryption, BAAs, and Gmail or Microsoft 365
Email can be HIPAA-compliant when the platform supports it, a Business Associate Agreement (BAA) is signed, and it is configured correctly. The product alone is never “HIPAA compliant.” And HIPAA does not flatly require email encryption — it is addressable under §164.312(e)(2)(ii).
On encryption specifically, HHS FAQ #2001 is the controlling answer: “The final Security Rule made the use of encryption an addressable implementation specification… [it] must therefore be implemented if, after a risk assessment, the entity has determined that the specification is a reasonable and appropriate safeguard… If the entity decides that [it] is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure.” Patients may also request unencrypted email after being warned of the risk. So whether email is HIPAA-compliant is never a yes/no about a product — it is a question about your configuration and paperwork.
For the two platforms most readers actually run:
- Google Workspace can support compliant email only with a signed Business Associate Amendment and correct configuration. Per Google, customers who have not signed a BAA “must not use PHI in Google Workspace or Cloud Identity services,” and covered services “must be configured by IT administrators to help ensure that PHI is properly protected.” Google itself only excludes the legacy free edition; the point that consumer @gmail.com cannot be used follows from the fact that it has no Admin console to accept a BAA — a clarification made by third-party compliance specialists (Paubox, Patient Protect), not by Google.
- Microsoft 365 offers a BAA by default through its Data Protection Addendum, but states plainly that “using Microsoft services doesn’t on its own achieve HIPAA compliance.” Microsoft scopes coverage by in-scope service rather than by SKU; the exclusion of Outlook.com and Microsoft 365 Personal/Family is attributed to named third parties (HIPAA Journal, AccountableHQ), not Microsoft.
The takeaway ties back to the table: a BAA plus TLS handles confidentiality, but DMARC, SPF, and DKIM handle the distinct spoofing and impersonation threat. Per NIST SP 800-177, those are different problems — you need both layers.
What the December 2024 NPRM (RIN 0945-AA22) would change
In December 2024, HHS proposed amending the Security Rule (NPRM RIN 0945-AA22, published January 6, 2025 at 90 FR 898). It would remove the addressable/required distinction and make encryption of ePHI in transit and at rest, plus multi-factor authentication, required. As of mid-2026 it is still proposed, not law — which is the single most important fact about it.
The verbatim proposals from OCR’s Fact Sheet are specific: “Remove the distinction between ‘required’ and ‘addressable’ implementation specifications and make all implementation specifications required with specific, limited exceptions”; “Require encryption of ePHI at rest and in transit, with limited exceptions”; “Require the use of multi-factor authentication, with limited exceptions”; and “Require network segmentation.”
For the mapping table above, the effect is direct: today’s Addressable rows — encryption, integrity controls, the mechanism to authenticate ePHI — would become Required. The de-facto baseline becomes an explicit one. But the proposed rule still would not name DMARC, SPF, or DKIM; it stays technology-neutral, so the analytic mapping remains the bridge between HIPAA’s rules and the protocols that satisfy them.
Where email actually fails in HIPAA breaches
Email is consistently the #2 location of breached PHI in HHS OCR’s Reports to Congress for large (500+) breaches — 32% of reports in CY2020, 24% in CY2021, and 22% in CY2022. That is a real but declining share, presented here as neutral evidence rather than a scare tactic.
The broad “Hacking/IT Incident” category that subsumes phishing dominated large breaches at 74% in CY2022, but OCR publishes no standalone phishing count, so there is no official “phishing %” to cite. The enforcement reasoning is worth reading carefully: in recent actions against PIH Health (2025) and Top of the World Ranch Treatment Center (2026), OCR cited a deficient risk analysis after an email or phishing compromise — not the absence of DMARC. (Settlements were $600,000 and $103,000, respectively.) That is precisely the mechanism that makes email authentication the expected baseline: the required risk analysis should have surfaced and mitigated the email threat.
Other regulatory mandates with email-auth implications
HIPAA is one of several mandates that push email authentication without always naming it. NIS2 in the EU ties email security to risk-management obligations for essential and important entities; DORA does the same for EU financial-sector ICT risk; and PCI DSS pairs anti-phishing controls with DMARC for entities handling cardholder data.
For the framework closest to HIPAA’s posture, see PCI DSS email-authentication requirements — it shows how a mandate can require the outcome (anti-phishing controls) without naming the protocol. For the EU angle, our NIS2 email security guide walks the directive’s transposition (17 October 2024) and what it expects of in-scope operators.
Frequently asked questions
Does HIPAA require DMARC?
No — HIPAA does not name DMARC, SPF, or DKIM. §164.312 is technology-neutral. But the required §164.308(a)(1) risk analysis applied to open-network email makes DMARC and TLS the de-facto baseline you must implement or document an equivalent for.
Does HIPAA require emails to be encrypted?
No, not flatly. HHS states encryption is an “addressable” specification under §164.312(e)(2)(ii) — implement it if your risk analysis finds it reasonable and appropriate, or document why not and use an equivalent. Patients may also request unencrypted email after being warned.
Is email HIPAA-compliant?
Email can be HIPAA-compliant when the platform supports it, you sign the vendor’s Business Associate Agreement, and you configure it correctly. No email product is “HIPAA compliant” on its own. Consumer accounts (personal Gmail, Outlook.com) are excluded because no BAA covers them.
Is Gmail or Google Workspace HIPAA compliant?
Google Workspace can support HIPAA-compliant email once you sign Google’s Business Associate Amendment and configure covered services correctly. Google excludes the legacy free edition; consumer @gmail.com has no Admin console to accept a BAA, so it cannot be used for ePHI.
Is Microsoft 365 or Outlook HIPAA compliant?
Microsoft 365 business and enterprise plans can support HIPAA compliance under the BAA available by default through the Data Protection Addendum — but Microsoft states using its services “doesn’t on its own achieve HIPAA compliance.” Outlook.com and Microsoft 365 Personal/Family are excluded.
What is §164.312 in HIPAA?
§164.312 is the Technical Safeguards section of the HIPAA Security Rule (45 CFR Part 164). It sets five standards — access control, audit controls, integrity, person-or-entity authentication, and transmission security — and labels each implementation spec “Required” or “Addressable.” Only unique user ID and emergency access are flatly Required.
Will the 2025 HIPAA Security Rule update make encryption mandatory?
It might. The December 2024 NPRM (RIN 0945-AA22) proposes removing the addressable/required distinction and requiring encryption in transit and at rest plus MFA. As of mid-2026 it is still proposed, not law — comments closed March 2025 and OCR is still reviewing them.
The bottom line
- HIPAA names no email protocol; §164.312 is deliberately technology-neutral.
- The required §164.308(a)(1) risk analysis is what makes DMARC, SPF, DKIM, and TLS the practical baseline for ePHI over email.
- The centerpiece mapping shows which protocol helps satisfy which §164.312 sub-paragraph — an analytic cross-reference, not a regulatory mandate.
- The December 2024 NPRM would harden today’s “Addressable” rows into “Required” — but it is still proposed, not law.
- Email is HIPAA-compliant only under a signed BAA, on a supporting platform, configured correctly.
Getting HIPAA email authentication right starts with one record — our walkthrough on how to create a DMARC record covers the syntax. Before you document your risk decision, confirm your domain actually publishes — and enforces — the controls in the table above.