DMARC for healthcare: a heavily spoofed sector, often poorly protected

What the data shows

Here too, the finding is measurable, not anecdotal. Our DMARC Observatory tracks the public posture of healthcare-sector domains, classified as protected (p=reject), enforcing (p=quarantine), observation-only (p=none) or unprotected. The recurring result joins that of the public sector and finance: a notable share of organisations that patients use daily are not enforcing, leaving their consumer-facing domain exposed.

As elsewhere, the trick is to check the domain patients actually see in their inbox — the one for appointment notices and results — and not just the organisation's institutional portal.

That gap has a particular social cost in healthcare: a patient phished in their hospital's name does not merely lose money or credentials, they lose trust in a channel their care sometimes depends on. A missed appointment because a real notice was mistaken for fraud, a result viewed on a fake page — the consequences go beyond the usual financial harm. It is precisely because health email carries stakes of care, and not only of money, that securing the legitimate domain matters even more than in other sectors.

NIS2 and the healthcare sector

Healthcare is explicitly among the sectors covered by the NIS2 directive, which mandates cyber risk-management measures and puts liability on leadership. For an in-scope organisation, email authentication — an obvious, auditable, low-cost anti-spoofing control — is one of the first points an inspection will examine. What was good practice becomes an obligation, doubled with real protection for patients.

The resource challenge

Healthcare shares with the public sector a structural difficulty: cyber resources often inadequate for the exposure. Public hospitals operate under budget constraints, labs and practices have no security team, and the application estate is fragmented across many providers. Email security there is rarely the priority topic — until the incident.

It is precisely in that context that tooling which automates diagnosis and guides remediation makes the difference: it reduces a project that would seem insurmountable to a series of simple decisions, portable by a provider or a small IT team. In a sector where the security budget is always contested, reducing a domain-protection programme to a handful of guided decisions is often the difference between a project that ships and one that stays on a wishlist for another year.

A worked example: the fake test result

Let us break down a typical sector attack. An analysis lab left its consumer-facing domain at p=none. An attacker emails patients with a message displaying the lab's authentic address, announcing that their results are available and inviting a portal login to view them, with a link to a credential-harvesting page mimicking the portal. The emotional stake — a medical result pending — disables suspicion even more effectively than a financial pretext. Patients enter their credentials, sometimes health data, on a page the attacker controls.

For the lab, this is a breach of sensitive data involving its own domain, with a probable notification duty and lasting damage to patient trust. The same email, domain at p=reject, would have been rejected at delivery, never reaching an inbox. In a sector where data is especially protected and trust especially fragile, this policy shift is not a technical detail: it is a patient-protection measure.

Organisations, labs, insurers: different profiles

"Healthcare" covers players with very different realities, and the approach adapts to each:

• Hospitals combine a vast application estate (patient records, booking, results, billing) and a strong budget constraint. The stake there is mainly the exhaustive mapping of sending sources before any tightening.
• Labs and practices send results and notices in bulk, often via one or two line-of-business tools. The estate is simpler, compliance faster, but the per-message exposure is high.
• Insurers and complementary health funds handle reimbursements and contract data; their profile is closer to finance, with high transactional volume and a direct financial fraud motive.

Identifying the right profile helps calibrate the effort: a practice does not need the same arrangement as a large hospital, but both need a domain in enforcement.

Health information security: an already demanding frame

The healthcare sector already operates under reinforced security requirements — certified hosting of health data, information-system security policies, sector obligations. Email authentication slots in naturally as an expected measure: it protects a channel through which notices, results and patient exchanges travel, and it produces the auditable evidence that feeds those frameworks. Far from being one more project, DMARC is a brick that serves several obligations at once — securing processing under GDPR, resilience under NIS2, and the good hygiene expected by healthcare-specific frames.

The patient-awareness challenge

There is a limit that technique alone does not cross: DMARC protects the exact domain, but not the look-alike domains an attacker would register to imitate the organisation. This is why protecting the domain gains from being paired with a clear message to patients — reminding them, on official materials, of the legitimate address and the channels the organisation really communicates through. That education does not replace authentication: it complements it. A domain at p=reject eliminates direct forgery, the most dangerous because the most credible; awareness reduces the margin of the variants technique does not cover. Both layers together form a far more robust defence than either alone.

When trust is the treatment channel

It is worth stating plainly why healthcare deserves extra urgency. In many care pathways, email is not a marketing nicety — it is how results, appointments and instructions actually reach the patient. When that channel becomes untrustworthy, the damage is not only a fraud loss: patients may start ignoring legitimate messages, missing appointments or delaying care because they can no longer tell real from fake. A spoofable domain therefore erodes the very reliability the care relationship depends on. Driving the domain to p=reject restores that reliability at its foundation, letting patients trust that a message bearing the organisation's name really is its own. Few sectors have a channel where the cost of lost trust is measured in missed care rather than missed sales — which is exactly why healthcare cannot afford to leave it at p=none.

The roadmap

1. Diagnosing the domain with a free DMARC analyzer to learn the starting point, with nothing to install.
2. Publishing DMARC at p=none and using the aggregate reports to map every sending source — line-of-business software, booking platforms, results providers.
3. Aligning every legitimate source on SPF and DKIM.
4. Ramping policy to quarantine then reject, watching the reports (the method).
5. Locking down dormant subdomains with the DMARCbis np tag, at near-zero risk.

Checking an organisation's domain

The first step is free and immediate. The domain patients receive mail from, run through our free DMARC analysis, returns an instant verdict, and the sector's posture is there to compare in the DMARC Observatory.

Bringing a multi-domain healthcare estate to p=reject without a dedicated team is exactly what Thomas, the virtual CISO, makes accessible: he names every sending source, generates the precise DNS to publish, assesses per-domain readiness and says when each can be enforced without risk to legitimate mail. Analyze a domain for free · explore the Observatory · get started with Thomas.