Is email authentication required for HIPAA compliance?

21 June 2026 · 13 min read

Short answer: HIPAA does not contain a rule that says "you must publish a DMARC record." The word DMARC appears nowhere in the regulation, and neither do SPF, DKIM or BIMI. But that is not the same as saying email authentication is optional for a covered entity or business associate. HIPAA's Security Rule requires you to assess risks to electronic protected health information and to put reasonable, addressable safeguards in place. Email is one of the most common ways protected health information leaves an organisation, and email spoofing is one of the most common ways attackers get into a healthcare organisation in the first place. Once you look at it that way, email authentication stops being a tick-box exercise and becomes a concrete, defensible control that maps directly onto requirements you already have to meet. This article explains what HIPAA actually expects, where SPF, DKIM and DMARC fit in protecting both patient data and patient trust, and a practical authentication baseline a healthcare practice or vendor can stand up without breaking legitimate mail.

We will keep the language plain. You do not need to be a security engineer to follow it, and we will define each technical term the first time it appears.

What HIPAA actually says about email

HIPAA, the Health Insurance Portability and Accountability Act, is enforced in the United States by the Department of Health and Human Services through its Office for Civil Rights. Two parts of HIPAA matter for email:

The Privacy Rule, which governs how protected health information (PHI) may be used and disclosed.
The Security Rule, which governs how electronic protected health information (ePHI) must be protected with administrative, physical and technical safeguards.

The Security Rule is the part that bears on authentication. It does not hand you a checklist of named technologies. Instead it is deliberately technology-neutral and risk-based. It asks you to do a few things that, taken together, point straight at email authentication:

Conduct a risk analysis: identify the risks to the confidentiality, integrity and availability of ePHI across all the places it lives and moves, including email.
Apply transmission security: guard against unauthorised access to ePHI that is being transmitted over a network. Email is a network transmission.
Apply integrity controls: ensure ePHI is not improperly altered or destroyed, and be able to confirm that it has not been.
Apply person or entity authentication: verify that a person or entity seeking access is the one claimed.

Several of these safeguards are labelled addressable rather than required. People misread "addressable" as "ignore if you like." It does not mean that. Addressable means you must assess whether the safeguard is reasonable and appropriate for your environment, implement it if it is, and if you decide not to, document why and what you did instead. A decision to leave your domain trivially spoofable, with no compensating control, is very hard to defend in front of an auditor or after a breach. So while HIPAA never types the letters D-M-A-R-C, a competent risk analysis of email will surface spoofing and tampering as real risks, and email authentication is the standard, widely accepted answer to both.

If you want to see where your own domain stands right now before reading further, run it through the free DMARC checker. It takes a few seconds and the rest of this article will make more sense against your real configuration.

The two threats authentication addresses: spoofing and tampering

To see why authentication maps onto HIPAA, you have to separate two distinct dangers, because email mixes them up.

Spoofing is when someone sends mail that falsely claims to come from your domain. Email was designed in a trusting era and ships with no built-in proof of sender. The "From" address your recipients see is just a label the sender typed. Nothing in the base protocol stops a fraudster putting billing@yourclinic.org in that label and sending a convincing message to a patient, a colleague or an insurer. In healthcare this is not abstract. Attackers impersonate clinics to harvest patient logins, impersonate finance staff to redirect payments, and impersonate IT to trigger password resets that open the door to the systems holding ePHI. The damage lands on patients and on your reputation even though your own servers were never touched. We cover the mechanics in why your domain can be spoofed.

Tampering is when the content of a genuine message is altered in transit, or when a forged message is dressed up to look genuine. HIPAA's integrity safeguard is concerned precisely with ePHI being improperly altered. A receiving server needs a way to confirm that the message it got is the message that was actually sent, unchanged.

Email authentication answers both. SPF and DKIM give receiving mail servers a way to check that a message claiming to be from your domain really was authorised by it, and DKIM additionally proves the signed content has not changed. DMARC ties those checks to the visible From address and tells the world what to do when they fail. None of this is healthcare-specific technology. It is the same machinery Gmail, Microsoft 365 and Yahoo use for every domain on earth. Healthcare just has an unusually strong reason to get it right, because the data and the trust at stake are unusually sensitive.

SPF: which servers may send for you

SPF stands for Sender Policy Framework. It answers a narrow question: is the server that delivered this email on the list of servers I have authorised to send for my domain?

You publish one TXT record in DNS (the Domain Name System, the public directory of the internet) listing your legitimate sending sources: your mail platform, your patient-communications tool, your billing or appointment-reminder service, and so on. A simple record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

v=spf1 marks it as SPF, each include: pulls in a named provider's servers, and -all means anything not listed is not authorised. SPF has two limits that matter for any compliance baseline:

It checks the hidden envelope sender, not the visible From address a human reads, so on its own it does nothing about the address patients actually see.
It breaks on forwarding, because the forwarding server is not in your record.

There is also a hard rule: an SPF record may trigger at most ten DNS lookups when evaluated, and exceeding it returns a state called PermError that receivers may treat as no SPF at all. Healthcare organisations accumulate sending tools quickly (reminders, surveys, billing, portals) and quietly blow past this limit. Check your own count with the SPF checker, and if you are over, read fix a failing SPF record. Our automatic SPF flattening keeps you under ten lookups without manual surgery.

SPF proves: this message came from a server I authorised. Useful, but incomplete.

DKIM: a tamper-evident signature

DKIM stands for DomainKeys Identified Mail. Where SPF is about which server sent the mail, DKIM is about the message itself. It uses a pair of cryptographic keys. Your provider holds a private key and uses it to sign outgoing mail; you publish the matching public key in DNS. The receiving server fetches the public key and verifies the signature.

The maths only works one way, which buys you two things at once and both map onto HIPAA:

Authentication: the signature could only have been made by a holder of your domain's private key, so the message really was authorised by your domain.
Integrity: the signature is computed over the message content, so if the From line, subject or body were altered after signing, verification fails. This is exactly the integrity property HIPAA's Security Rule asks you to be able to demonstrate for ePHI.

Confirm your domain is signing correctly with the DKIM checker. The product page for our managed signing is at /products/dkim.

DMARC: the policy that protects the visible From

SPF and DKIM each prove something useful, but neither, on its own, protects the address your patients actually read, and neither tells receivers what to do on failure. That is DMARC: Domain-based Message Authentication, Reporting and Conformance.

DMARC does three jobs:

Alignment: it requires that the domain validated by SPF or DKIM matches the visible From domain your recipients see. This is the piece that finally protects the human-readable address, closing the gap SPF and DKIM leave open.
Policy: it lets you tell the world what to do with mail claiming to be from you that fails authentication. The policy values are p=none (monitor only, take no action), p=quarantine (send to spam) and p=reject (refuse outright).
Reporting: it asks receivers to send you aggregate reports, daily XML summaries of who is sending mail using your domain and whether it passed. This is your visibility into both your legitimate senders and anyone impersonating you.

A DMARC record at _dmarc.yourclinic.org looks like this:

v=DMARC1; p=reject; rua=mailto:reports@yourclinic.org; adkim=s; aspf=s

p=reject is the goal state. At reject, a message that forges your domain in the From line and fails authentication is refused by the receiving server before it ever reaches the patient or colleague it was aimed at. That is the control that actually stops spoofed phishing carrying your clinic's name. From a HIPAA standpoint it is a clean, demonstrable safeguard against the impersonation that so often precedes a breach. See the DMARC product page and our guide on how to check DMARC is working.

Why a covered entity should not jump straight to p=reject

Here is the trap. Knowing that p=reject is the goal, a well-meaning practice manager publishes it on Monday morning. By Wednesday the appointment-reminder service, the patient-survey tool and the billing platform, none of which were properly aligned, are all failing DMARC, and legitimate patient mail is being rejected. In healthcare a self-inflicted mail outage is not a minor inconvenience: missed reminders mean missed appointments, and a billing platform that cannot reach patients has real consequences.

The safe path is the whole reason DMARC includes a monitoring mode:

Start at p=none. This changes nothing about delivery. It simply turns on reporting so you can see every system sending mail using your domain, including the ones nobody documented.
Read the aggregate reports and fix alignment for each legitimate sender, bringing your reminder tool, survey tool, billing platform and mail host into SPF and DKIM alignment one by one. The raw XML is unreadable by hand, so use the DMARC report analyzer or read how to read a DMARC aggregate report.
Move to p=quarantine, often on a percentage of mail first, watching that nothing legitimate is caught.
Reach p=reject once the reports show only known, aligned senders failing.

This staged journey, from p=none to p=reject with no email outage, is exactly what DMARC Engine is built to manage. It watches the reports, tells you which senders still need fixing, and advances policy only when the evidence says it is safe. That is the difference between a control that protects patients and a misconfiguration that disrupts their care. Our done-for-you DMARC enforcement explains the managed version.

Where MTA-STS and TLS fit the transmission-security requirement

Authentication proves who sent a message and that it was not altered. HIPAA's transmission-security safeguard is also concerned with whether the message could be read or intercepted on the wire. That is a question of encryption in transit, and it is where two more records earn their place.

MTA-STS stands for Mail Transfer Agent Strict Transport Security. By default, the encryption between mail servers is opportunistic: if a TLS (Transport Layer Security) connection cannot be established, many servers will quietly fall back to sending in plain text, and an attacker positioned in the network can strip encryption or read the contents. For a message carrying ePHI that is a transmission-security gap. MTA-STS lets you publish a policy that says "mail servers must use TLS to deliver to me, and must refuse to fall back to plaintext." Its companion, TLS-RPT (TLS Reporting), sends you reports when a sender's TLS connection to your domain fails, so a downgrade attack or a broken configuration does not stay invisible.

Check both with the MTA-STS checker and the TLS-RPT checker, and see the MTA-STS product page. For a healthcare organisation building a defensible record of transmission-security controls, enforced TLS via MTA-STS is a strong, concrete addition that pairs naturally with the authentication stack.

A caveat worth stating plainly: none of these standards encrypt the message at rest in the recipient's mailbox, and they do not replace end-to-end encryption or a secure patient-portal channel where one is required for the most sensitive disclosures. They protect the From identity, the integrity of the content, and the encryption of the hop between servers. They are necessary, not sufficient, and an honest risk analysis treats them as one layer among several.

BIMI and the patient-trust dimension

HIPAA is about more than the letter of the safeguards: it exists to protect patients, and patient trust is part of what a clinic is defending. BIMI, Brand Indicators for Message Identification, lets a verified logo show next to your messages in supporting inboxes, but it only works once you are at DMARC enforcement (p=quarantine or p=reject). It is not a security control in the way SPF, DKIM and DMARC are, and it does not feature in HIPAA. It is worth a mention only because the same enforcement work that satisfies your risk analysis also unlocks a visible trust signal for patients who are increasingly wary of healthcare phishing. You can explore it with the BIMI checker and the BIMI product page; just remember enforcement comes first.

A practical authentication baseline for covered entities

If you want a defensible, plain-English baseline to bring to a risk analysis, this is a reasonable target for a healthcare practice or a business associate that handles ePHI by email:

Inventory every system that sends mail using your domain. Reminders, surveys, billing, the patient portal, your help desk, your mail host. You cannot secure senders you have not listed. The DMARC report analyzer will surface ones you forgot once monitoring is on.
Publish SPF covering every legitimate sender, and keep it under the ten-lookup limit. Verify with the SPF checker.
Enable DKIM signing on every sending platform, so each one signs with a key aligned to your domain. Verify with the DKIM checker.
Publish DMARC at p=none with a rua reporting address, and actually read the reports. This is the visibility step, and it is where most of the real work happens.
Fix alignment for each legitimate sender until the reports are clean.
Advance the DMARC policy to p=quarantine, then p=reject, on the evidence, not the calendar.
Add MTA-STS in enforce mode with TLS-RPT to satisfy transmission-security and catch encryption downgrades.
Document the lot. The records, the policy decisions, the dates and the reasoning. HIPAA rewards a documented, risk-based process, and your DMARC reports are dated evidence that the controls are live and working.

For the broader picture of the modern requirements that drive all of this, including the sending-volume thresholds at Gmail and Yahoo, see our requirements page. The free DMARC checker is the fastest way to see your starting point, and if a term here is unfamiliar the glossary defines each one.

Where DMARC Engine fits

The honest summary is this. HIPAA does not name email authentication, but a competent risk analysis of email will identify spoofing and tampering as genuine threats to ePHI and to patients, and SPF, DKIM and DMARC are the standard, accepted controls for both. The hard part is not knowing that p=reject is the goal. The hard part is getting there without rejecting legitimate patient mail, keeping SPF under its lookup limit as you add tools, signing every sender correctly, enforcing TLS, and keeping dated evidence that it all works.

DMARC Engine is a done-for-you hosted platform that handles exactly that, on Cloudflare, taking a domain safely from p=none to p=reject with no email outage. It manages SPF flattening, DKIM, MTA-STS and BIMI, reads your aggregate reports for you, and emails you when something needs attention. You can run the free diagnostic tools above with no account, and when you are ready to manage enforcement properly the dashboard lives at app.dmarcengine.com. None of this is legal advice, and your compliance posture is ultimately yours to document, but the authentication layer of it is precisely the part we make straightforward.