While HIPAA doesn't explicitly name DMARC, DKIM, or SPF as required technologies, these three email authentication protocols have become foundational tools for meeting HIPAA's requirements for safeguarding PHI and preventing unauthorized access or disclosure. HIPAA's Security Rule requires covered entities and business associates to implement administrative, physical, and technical safeguards that protect the confidentiality, integrity, and availability of electronic PHI.

SPF, DKIM, and DMARC don't encrypt email content, and they aren't a substitute for encrypted transmission or business associate agreements. Instead, they verify that an email originates from the domain it claims to be from.

According to Paubox's 2026 Healthcare Email Security Report, 170 email-related breaches were reported to the HHS Office for Civil Rights in 2025 and the organizations that experienced them shared common weaknesses. Nearly three quarters lacked effective DMARC enforcement. More than half had permissive or missing SPF records.

 

SPF: Sender Policy Framework

SPF works by letting a domain owner publish a list of IP addresses or servers authorized to send email on behalf of that domain. When a receiving mail server gets an email claiming to be from, for example, a hospital's domain, it checks the sending server's IP address against the SPF record published by that domain. If the IP isn't on the approved list, the message fails SPF authentication.

For healthcare organizations, SPF is useful because many providers use a mix of internal mail servers, EHR platforms, appointment reminder services, and marketing tools, all of which may send email "as" the organization. SPF ensures that only the platforms explicitly authorized are recognized as legitimate senders, reducing the chance that a malicious actor can send convincing spoofed messages from an unauthorized server.

NIST Technical Note 1945 displays this with a sample SPF record, a domain lists the specific IP addresses it sends from, followed by a final catch-all mechanism that tells receivers how to treat any address not on the list. The qualifier attached to that catch-all determines how strict the policy is, "hard fail" tells receivers to reject mail from unlisted addresses outright, while a "soft fail" flags it as suspicious without necessarily blocking it. NIST's own testing showed that some senders configure their SPF records to mark every IP address in existence as authorized. NIST found this in roughly 11% of the domains in its most recent dataset and recommends that they be treated as an error condition rather than a legitimate policy choice, since it defeats the purpose of SPF.

The Paubox report found that 46% of breached organizations used soft-fail SPF policies, meaning that even when email arrived from an unauthorized server, it was often still delivered to the recipient's inbox rather than blocked. Another 9% had no SPF record at all. These conditions are what allow spoofed messages to appear legitimate.

Learn more: What is SPF?

 

DKIM: DomainKeys Identified Mail

DKIM, rather than checking where an email came from, it verifies that the email's content hasn't been altered in transit and that it genuinely originates from the claimed domain. This is done through public-key cryptography which happens when the sending domain attaches a digital signature to each outgoing email, generated using a private key. The corresponding public key is published in the domain's DNS records. When the email arrives, the receiving server uses that public key to verify the signature, confirming both authenticity and integrity of the message.

For HIPAA regulated communication, DKIM's content-integrity function is similar to the Integrity standard under the Technical Safeguards (45 CFR § 164.312(c)(1)), which requires covered entities and business associates to implement mechanisms to authenticate that ePHI has not been improperly altered or destroyed. DKIM provides assurance that an email containing PHI or PHI-adjacent information hasn't been tampered with after it left the sending organization. It also helps establish a verifiable chain of custody for email content, which can be used during incident investigations or compliance audits.

NIST's technical note explains the mechanism that makes vendor-specific signing keys possible, every DKIM signature includes a selector, a label that points to a specific public key published at a DNS location, because each selector can point to its own distinct key, a domain isn't limited to a single organization-wide signing key. This is what allows a healthcare organization to issue a separate selector and key pair to a third-party platform such as an EHR vendor or appointment reminder service. If that vendor's key is ever compromised or the relationship ends, the organization can revoke that one selector without affecting the DKIM signatures on its own outgoing mail.

Learn more: DKIM: The very basics

 

DMARC: Domain-based Message Authentication, Reporting and Conformance

DMARC brings SPF and DKIM together and adds policy enforcement. DMARC requires that the domain used in SPF or DKIM checks actually matches the domain visible in the email's "From" header. This prevents attackers from passing SPF or DKIM checks using a technically valid but visually deceptive domain. This identity-verification function is related to the Person or Entity Authentication standard (45 CFR § 164.312(d)), which requires covered entities to verify that a person or entity seeking access to ePHI is who they claim to be even though this standard was written to govern user access to systems, not email sender verification.

DMARC also lets domain owners publish a policy instructing receiving servers what to do when an email fails authentication such as quarantine it (send to spam), reject it outright, or take no action but report the failure.

Despite this, the Paubox report found that 41% of breached organizations in 2025 had no DMARC record at all, and another 33% operated only in monitoring mode. In total, nearly three quarters of breached organizations had DMARC configurations that provided no enforcement.

NIST's technical note walks through a sample DMARC record built around a policy, the setting that tells receivers not to quarantine or reject failing messages, but to fall back to their own local handling instead. NIST notes this is the configuration that lets a domain owner collect visibility into how their mail is being authenticated across a range of receivers before committing to a stricter policy.

Learn more: What is DMARC?

 

Putting it together for HIPAA compliance

None of these three protocols alone provides complete protection, and none directly encrypts PHI. What they do is confirm that the email claiming to come from a healthcare organization actually did, and that it wasn't altered along the way. This supports the Security Management Process standard under the Administrative Safeguards (45 CFR § 164.308(a)(1)(i)), which requires covered entities and business associates to conduct an accurate and thorough risk analysis and implement risk management measures sufficient to reduce risks to a reasonable and appropriate level.

It's also worth separating these protocols from the Technical Safeguards' Transmission Security standard (45 CFR § 164.312(e)(1)), which governs encryption and integrity controls for ePHI in transit. SPF, DKIM, and DMARC authenticate the sender and protect against tampering or impersonation, but they are not themselves the encryption mechanism that standard requires.

Lastly, a full rollout, covering vendor identification, credential setup, and a gradual policy tightening, might take a few months for organizations with a complex email environment. For healthcare organizations weighing this against compliance priorities, planning for that timeline upfront can help avoid incomplete implementations that leave gaps in protection.

Read also: Secure, HIPAA compliant email for healthcare

 

FAQs

What is the difference between a HIPAA violation and a HIPAA breach?

A violation is any failure to comply with HIPAA rules, while a breach refers to the unauthorized acquisition, access, use, or disclosure of unsecured PHI.

 

Can patients opt out of receiving emails from their healthcare provider?

Yes, patients have the right to request restrictions on how their information is communicated, and providers must accommodate reasonable requests under the Privacy Rule.

 

Does using a personal email account to send work-related PHI constitute a breach?

Sending PHI through a personal or unsanctioned email account is a HIPAA violation because it bypasses the technical safeguards required under the Security Rule.

 

What role does staff training play in email security?

Human error remains a leading cause of email breaches, making regular and role-specific training a required administrative safeguard under HIPAA.