---
title: "Does HIPAA Require DMARC? §164.312 Email Auth Mapping [2026]"
description: "Does HIPAA require DMARC? Not by name. How §164.312 technical safeguards map to DMARC, SPF, DKIM, MTA-STS, TLS-RPT — plus the Dec 2024 NPRM."
publishedAt: 2026-06-18
tags: ["hipaa", "compliance", "dmarc", "email-authentication", "164-312", "ephi", "healthcare"]
faq:
- question: "Does HIPAA require DMARC?"
answer: "No — HIPAA does not name DMARC, SPF, or DKIM. The §164.312 technical safeguards are 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 either implement or document an equivalent for."
- question: "Does HIPAA require emails to be encrypted?"
answer: "No, not flatly. HHS states encryption is an addressable implementation 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 of the risk."
- question: "Is email HIPAA-compliant?"
answer: "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 like personal Gmail and Outlook.com are excluded because no BAA covers them."
- question: "Is Gmail or Google Workspace HIPAA compliant?"
answer: "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."
- question: "Is Microsoft 365 or Outlook HIPAA compliant?"
answer: "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."
- question: "What is §164.312 in HIPAA?"
answer: "§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."
- question: "Will the 2025 HIPAA Security Rule update make encryption mandatory?"
answer: "It might. The December 2024 NPRM (RIN 0945-AA22) proposes removing the addressable/required distinction and requiring encryption in transit and at rest plus multi-factor authentication. As of mid-2026 it is still proposed, not law — comments closed March 2025 and OCR is still reviewing them."
---
# 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](/tools/hipaa-email-readiness/)
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](/learn/spf/) (Sender Policy
Framework, RFC 7208), [DKIM](/learn/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:
1. **§164.306(a)** — general security requirements.
2. **§164.306(d)(3)** — the addressable decision process.
3. **§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](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312))
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.
- **(b) Audit controls (Standard):** "Implement hardware, software, and/or
procedural mechanisms that record and examine activity in information systems
that contain or use electronic protected health information."
- **(d) Person or entity authentication (Standard):** "Implement procedures to
verify that a person or entity seeking access to electronic protected health
information is the one claimed."
- **(e)(1) Transmission security (Standard):** "Implement technical security
measures to guard against unauthorized access to electronic protected health
information that is being transmitted 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](/learn/dmarc/) shows why `p=none` does
not actually stop spoofed mail — only `p=quarantine` or `p=reject` does.
- **(e) Transmission security** is where TLS alone is not enough. Opportunistic
TLS can be stripped; [MTA-STS for transmission security](/learn/mta-sts/)
enforces it and [TLS-RPT](/learn/tls-rpt/) reports when a downgrade happens,
while [DANE](/learn/dane/) pins certificates via DNSSEC.
How common is the gap this table describes? It is the norm, not the exception.
In the same scan, only 12.8% of domains enforce DMARC with `p=quarantine` or
`p=reject` — see our
[state-of-email-authentication study](/research/email-authentication/) 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](/blog/dmarc-enforcement-gap/) 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.
The comment period closed March 7, 2025; OCR reported receiving roughly 4,745
comments and said it would read every one. OCR's Unified Agenda had targeted a
May 2026 step from NPRM toward a final rule, which had not occurred as of
publication, and OCR has not confirmed when — or whether — it will finalize the
rule as written. Be skeptical of any vendor content
that presents the NPRM as today's enforceable law — it is not. See the
[Federal Register notice (90 FR 898)](https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information)
and the implementation companion,
[NIST SP 800-66 Rev. 2](https://csrc.nist.gov/pubs/sp/800/66/r2/final).
## 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](/learn/pci-dss/) — 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](/blog/nis2-email-security/) walks the
directive's transposition (17 October 2024) and what it expects of in-scope
operators.
{/* TODO: link /blog/dora-email-authentication/ once live (publishes 2026-06-29; not live on this post's 2026-06-18 publish date). */}
## 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](/blog/how-to-create-dmarc-record/) covers the
syntax. Before you document your risk decision, confirm your domain actually
publishes — and enforces — the controls in the table above.