Email authentication for healthcare and HIPAA

11 May 2026 · 14 min read

Healthcare runs on email. Appointment reminders, lab results, referral letters, prior-authorisation requests, patient statements and the steady traffic between clinics, billing companies, pharmacies and insurers all move through inboxes. That makes the healthcare From address one of the most impersonated identities online, because a message that appears to come from a hospital, a clinic or a benefits administrator is one that patients and staff open without hesitation. Email authentication, meaning SPF, DKIM and DMARC working together, is how you stop other people sending mail that claims to be from your healthcare domain, and how you keep your own legitimate mail out of the spam folder where a missed result genuinely matters.

This article is specifically about email authentication in a healthcare and HIPAA context. It is not a generic DMARC explainer. It covers what HIPAA does and does not say about email, why DMARC sits in the "addressable" and "reasonable safeguards" part of the rules rather than being named outright, how protected health information (PHI) interacts with DMARC reporting, the particular sender sprawl that healthcare organisations carry, and the staged path to enforcement that does not knock out an appointment-reminder system on day one. If you want the underlying mechanics first, what is DMARC, what is SPF and what is DKIM are the companion pieces, and the glossary defines every term used below.

What HIPAA actually says about email (and what it does not)

There is a persistent myth that HIPAA "requires DMARC". It does not, by name. HIPAA predates DMARC by well over a decade, and the Security Rule is deliberately technology-neutral so that it does not go stale every time a new protocol appears. What HIPAA does require is a set of outcomes, and email authentication is one of the most practical ways to deliver several of them.

The relevant pieces of the HIPAA Security Rule for email are:

• Transmission security (45 CFR 164.312(e)(1)). A covered entity must "implement technical security measures to guard against unauthorised access to electronic protected health information that is being transmitted over an electronic communications network." Email is exactly such a network.
• Integrity controls (164.312(e)(2)(i)), an addressable specification. You must implement measures to ensure that electronically transmitted PHI is not improperly modified without detection.
• Person or entity authentication (164.312(d)). You must verify that a person or entity seeking access is the one claimed.
• The risk analysis and risk management requirements (164.308(a)(1)). You must identify risks to electronic PHI and put reasonable and appropriate safeguards in place.

Two words matter enormously here: required versus addressable. HIPAA marks some specifications "required" and others "addressable". Addressable does not mean optional. It 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. Email authentication falls squarely into the territory where, for almost any organisation handling PHI by email, "we chose not to authenticate our domain" is a very hard position to defend in a risk analysis.

So the honest framing is this. HIPAA does not say "publish a DMARC record." HIPAA says you must guard transmitted PHI against unauthorised access, protect its integrity, authenticate entities, and manage risk reasonably. DMARC, SPF and DKIM are direct, low-cost, well-understood controls that address spoofing, tampering and sender authentication. When an auditor or the Office for Civil Rights asks how you protect against attackers impersonating your domain to extract PHI, "we enforce DMARC at p=reject and monitor it" is a clean answer. "We have no domain authentication" is the start of a finding.

The threat HIPAA is actually worried about: PHI by impersonation

The reason this matters in practice is that the biggest email risk to a healthcare organisation is rarely interception in transit. It is impersonation. Attackers do not need to break your mail server if they can simply send mail that looks like it came from it.

Consider how PHI leaks through spoofing:

• A message appearing to come from records@yourclinic.com asks a patient to "confirm your details" on a fake portal, harvesting names, dates of birth, insurance IDs and clinical history.
• A message appearing to come from your billing domain tells a patient their statement is ready and routes them to a credential-stealing page.
• An attacker spoofs a physician's address to a pharmacy or a lab to extract or alter a record.
• Business email compromise targets your finance team with a spoofed message from the practice manager, redirecting a supplier payment.

In each case the visible From header is forged. DMARC exists precisely to make a forged From header fail. It binds the domain in the From address that a human reads to authentication that the receiving server checks, and it tells that server what to do when the binding breaks. Without DMARC, a receiver has no instruction from you, so a spoofed message from your domain frequently lands in the inbox looking entirely legitimate. We walk through the mechanics of this in email spoofing explained and the money side in invoice fraud and the spoofed look-alike domain.

This is why DMARC maps onto HIPAA's authentication and integrity requirements so neatly. SPF and DKIM provide the authentication of the sending source; DMARC provides the policy and the alignment check that ties it to the readable identity; and the reporting stream gives you the ongoing visibility that a risk-management programme is supposed to have.

Alignment is the part that matters for PHI

A subtlety that catches healthcare IT teams out: SPF and DKIM passing is not the same as DMARC passing. DMARC requires alignment, meaning the domain that authenticated must match the domain in the visible From header.

Here is why that is not pedantry. Many healthcare organisations send through third parties: a patient-engagement platform for reminders, a clearinghouse or billing service for statements, a CRM for outreach. By default those platforms often sign mail with their own domain and use their own return-path. The message can show SPF pass and DKIM pass and still fail DMARC, because what passed authenticated someplatform.com, not yourclinic.com. To a patient the message reads as coming from your clinic; to DMARC it is unaligned and therefore indistinguishable from a spoof.

Two flavours of alignment exist:

• SPF alignment requires the envelope-sender domain (the return-path / MAIL FROM) to match your From domain. This is why a custom return-path on your sending platform matters.
• DKIM alignment requires the d= signing domain in the DKIM signature to match your From domain. This is usually achieved by publishing the platform's DKIM CNAMEs on your own domain so it signs as you.

You only need one of the two to align and pass for DMARC to pass, but you want both wherever you can, because DKIM survives forwarding while SPF does not, and healthcare mail gets forwarded constantly between practices, referral networks and patient mailboxes. We cover the difference in SPF vs DKIM: which one aligns and the forwarding problem in forwarding and DMARC. You can check your own alignment right now with the DMARC checker, the SPF checker and the DKIM checker.

A worked example: a clinic's records

Suppose yourclinic.com sends staff mail through Microsoft 365, appointment reminders through a patient-engagement platform, and statements through a billing service. A correct, enforced posture looks roughly like this.

An SPF record that authorises every legitimate source and nothing else:

v=spf1 include:spf.protection.outlook.com include:_spf.reminders-vendor.com include:_spf.billing-vendor.com -all

A DMARC record at full enforcement, with both aggregate and forensic reporting pointed at your monitoring:

_dmarc.yourclinic.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourclinic.com; ruf=mailto:dmarc@yourclinic.com; fo=1; adkim=s; aspf=s; pct=100"

And a subdomain policy so that an unused subdomain cannot be used to spoof you, which is a common gap in larger health systems with many subdomains:

_dmarc.yourclinic.com  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourclinic.com"

You do not start at p=reject. You arrive there. The whole point of the staged rollout below is to reach this record without a single legitimate reminder, result or statement being rejected on the way. The DMARC generator will assemble a syntactically correct record for your chosen stage.

Does DMARC reporting itself create a PHI problem?

This is the question a privacy officer will, and should, ask. DMARC produces two kinds of reports, and you must understand the difference before pointing them anywhere.

Aggregate reports (RUA) are XML summaries sent by receiving mail providers, typically once a day. They contain counts of messages grouped by sending IP, the authentication results (SPF pass/fail, DKIM pass/fail, alignment) and the disposition. They contain no message content, no subject lines and no recipient addresses. An aggregate report tells you "147 messages from this IP claiming to be your domain failed DMARC." It does not tell you who they were to or what they said. Aggregate reports do not contain PHI, and they are the workhorse of a DMARC programme. See DMARC RUA and RUF reports and reading your first DMARC report.

Forensic / failure reports (RUF), requested with the ruf= tag, are different and deserve caution. When a provider supports them (most large ones no longer send them), a failure report can include message headers and sometimes portions of the message itself. In a healthcare setting, a From, To and Subject line alone can constitute PHI: "Subject: Your oncology appointment with Dr Patel" reveals a great deal. So a RUF stream that lands in an arbitrary mailbox, or worse a third-party analyser that stores it without a Business Associate Agreement, is a genuine privacy exposure.

The practical guidance for healthcare:

• Rely on aggregate (RUA) reports for your day-to-day programme. They give you the visibility you need without content.
• If you use RUF at all, keep fo=1 for diagnostics but treat the destination mailbox as in-scope for PHI: encrypted, access-controlled, retention-limited, and covered by your risk analysis. Many healthcare organisations deliberately omit ruf= entirely for this reason, and that is a defensible choice.
• If you send DMARC reports to a third-party processor (any hosted analyser, including ours), confirm a Business Associate Agreement is in place before forensic data flows to them, and prefer a processor that lets you keep RUF off while still getting full aggregate analysis.

DMARC Engine processes aggregate reports by default and treats failure-report handling as an explicit, opt-in decision precisely because of this distinction. You can analyse a report you already hold with the DMARC report analyzer to see exactly what a given report does and does not contain.

Sender sprawl is the real healthcare problem

The technical reason DMARC rollouts stall in healthcare is not the protocol. It is the inventory. A mid-sized health system routinely sends legitimate mail from a startling number of sources, and every one of them has to be brought into alignment before you can safely enforce. Typical sources include:

• Microsoft 365 or Google Workspace for staff mail.
• A patient-engagement / appointment-reminder platform.
• An EHR or practice-management system that emails results, summaries and portal notifications.
• A medical billing service or revenue-cycle management vendor sending statements.
• A clearinghouse for claims correspondence.
• A secure-messaging or e-prescribing gateway.
• Survey and patient-satisfaction tools (HCAHPS and similar).
• Marketing and newsletter platforms for outreach and wellness campaigns.
• Help-desk / ticketing systems and scheduling tools.
• Scanners, MFPs and on-premise applications that "email a document" from a server in the building.

That last category, the photocopier that scans-to-email and the ageing on-prem application server, is where healthcare DMARC projects most often come unstuck. Those devices were configured years ago, nobody remembers the relay path, and they will start failing DMARC the moment you enforce. This is exactly what aggregate reports are for: they surface every IP sending as you, including the ones you forgot. We cover the "who is this unexpected source?" workflow in DMARC reports show unknown sources.

Two SPF traps are endemic to this sprawl. First, each vendor wants an include: in your SPF record, and SPF has a hard limit of ten DNS lookups; healthcare organisations blow through it routinely and earn a permerror that silently breaks SPF for everyone. See SPF too many DNS lookups and how SPF flattening works; our SPF flattening product keeps the record valid and under the limit automatically as vendors come and go. Second, more than one v=spf1 record on the same domain is itself a permerror; if two teams each "added SPF", you have a problem, covered in fix multiple SPF records.

The staged rollout that does not break clinical email

Nobody should go from no policy to rejection overnight in an environment where a bounced lab result has clinical consequences. The standard, safe progression has three stages, and it is the same one we detail in reach p=reject without breaking email and from p=none to p=reject safely.

1. Monitor with p=none. Publish a DMARC record that changes nothing about delivery but collects aggregate reports. Run it for two to four weeks. Use the reports to build the complete inventory of legitimate senders described above, and bring each one into SPF or DKIM alignment. Crucially, p=none provides no protection; it is a measurement phase, not a destination. A domain left at p=none for a year is still wide open to spoofing, a false comfort we describe in the false security of p=none.

1. Quarantine, often with sampling. Move to p=quarantine. You can use pct= to ramp gradually, for example pct=25 so a quarter of failing mail is quarantined while you watch the reports for any legitimate source you missed. Sampling is explained in DMARC pct sampling. At this stage failing mail goes to spam rather than being dropped, which is the right safety margin for clinical traffic. Watch for the quarantine but mail still in inbox edge cases.

1. Reject at p=reject. Once aggregate reports show only your known senders passing and the unknown-source noise has been resolved, move to p=reject; pct=100. Now any message that forges your domain is refused outright at the receiving server, before it reaches a patient or a staff inbox. This is the posture that actually satisfies the spirit of HIPAA's transmission-security and authentication requirements, and it is the only stage that stops impersonation rather than merely observing it.

Add a subdomain policy (sp=) so that subdomains you do not actively send from cannot be exploited; large health systems accumulate subdomains and attackers love an unprotected one. See the subdomain policy tag. Throughout, expect to hit the classic "DMARC fails but SPF and DKIM pass" alignment confusion, which we untangle in DMARC fails but SPF and DKIM pass.

Where MTA-STS and BIMI fit the HIPAA story

DMARC, SPF and DKIM authenticate the sender. Two adjacent controls strengthen the rest of the picture, and both have a healthcare angle.

MTA-STS addresses transmission confidentiality directly. Plain SMTP between mail servers can fall back to an unencrypted connection, and an active attacker can strip TLS so that mail, potentially carrying PHI, crosses the network in clear text. MTA-STS lets you publish a policy that says "always use TLS to reach my servers, and refuse to deliver if you cannot verify it." For an organisation that must guard PHI in transit under 164.312(e), enforced inbound TLS is a concrete, documentable safeguard. Check yours with the MTA-STS checker and read the background in RFC 8461 MTA-STS explained.

BIMI is about trust signalling rather than security, but it has real value for patient confidence. Once you are at enforcement, BIMI lets your verified logo appear next to your messages in supporting inboxes, which makes a genuine clinic message visually distinguishable from a spoof at a glance. BIMI requires DMARC at p=quarantine or p=reject first, so it is a reward for finishing the rollout, not a shortcut. See do you need BIMI and the BIMI checker.

Documentation: turning controls into compliance evidence

A control that you cannot evidence does not help you in an audit. The HIPAA risk-management process is as much about documentation as configuration, so treat your email authentication as something you can show, not just something that is true.

Practical evidence to keep:

• A record of the risk decision: that you assessed domain spoofing as a risk to PHI and implemented SPF, DKIM and DMARC as the addressable safeguard, with dates.
• The DMARC policy history showing the staged progression from p=none to p=reject, demonstrating a managed rollout rather than a guess.
• Ongoing aggregate-report monitoring, showing that enforcement is maintained and that new senders are detected, which is exactly the "ongoing risk management" HIPAA wants rather than a one-off project.
• Change alerts, so that if someone weakens the policy back to p=none, removes an SPF include or a DKIM selector breaks, you find out the same day rather than at the next audit.

That last point is the difference between a control and a control you can rely on. DNS changes, vendors rotate keys, a well-meaning admin "fixes" a record and quietly disables your protection. Continuous monitoring with change alerts is what keeps the enforced state enforced and gives you the audit trail. Our requirements page maps the sender expectations that Gmail, Yahoo and Microsoft now enforce, which overlap heavily with what a healthcare risk analysis should already cover; see also Gmail, Yahoo and Microsoft now require DMARC.

The practical takeaway

HIPAA never says "DMARC", but it asks for exactly what DMARC delivers: protection of transmitted PHI against unauthorised access, integrity of what you send, authentication of who is sending, and a risk-management programme that keeps working. SPF and DKIM authenticate your sources, DMARC ties that authentication to the address a patient actually reads and tells receivers to reject forgeries, MTA-STS keeps the transport encrypted, and aggregate reporting gives you the ongoing visibility a risk analysis demands, without exposing PHI as long as you handle failure reports carefully. The work that takes the time is not the protocol; it is inventorying every legitimate sender in a sprawling healthcare estate and bringing each into alignment before you enforce, then keeping it that way.

Start by seeing where you stand: run your domain through the DMARC checker to read your current policy and alignment. If the staged rollout to p=reject, the sender inventory and the BAA-aware report handling are more than your team wants to own, our done-for-you hosted service takes a healthcare domain from p=none to p=reject with no mail outage and keeps it monitored, with change alerts so the enforced state, and your evidence, stays intact.