French healthcare and email impersonation: where things stand

What the barometer records, and how

The healthcare strand of the DMARC Observatory barometer tracks a corpus of French healthcare-institution domains — university and general hospitals, clinic groups, laboratory networks — and records them at the public DNS. The method is in no way intrusive: it reads what any resolver sees. The TXT record placed on _dmarc.example.com, the p= policy it declares, the fate of subdomains, the SPF record and its strictness, the public indicators of DKIM and BIMI.

Each domain is classified by its effective policy: reject (impersonation is rejected), quarantine (it goes to spam), none (monitoring without blocking), record absent, or invalid — a single syntax error is enough to strip a policy of any effect. The reading is redone every month, which produces two things a single snapshot never gives: a ranking at a date and a trajectory — who is progressing, who is stalling, who is regressing.

The useful hierarchy reads as follows: absent < invalid < none < quarantine < reject. A record set to p=none:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

blocks strictly nothing — it is a listening mode, indispensable to start, with no defensive value whatsoever. A hospital domain on p=none remains spoofable exactly as if it had no DMARC; the only difference is that attempts appear in its reports.

One firm principle follows from the monthly cadence: this article cites no percentage. A figure printed here would be wrong six months later and would go on being read all the same. The distribution by status, the ranking by institution and the monthly evolution live in the monthly edition, refreshed at each reading — that is what carries authority.

The structural patterns of the healthcare corpus

Without copying over the month's figures, four structural patterns recur in this corpus — and they point to the real worksites.

Large university hospitals relatively ahead. The most visible institutions are generally the best kept: an identified security team, regular audits, media exposure that forbids negligence. "Relative" remains the right word: the lead often shows as the presence of a record and of monitoring, not yet as a hardened policy across the whole perimeter.

The long tail. Behind the leading pack, the distribution stretches out: medium hospitals halfway there, small structures with no record at all, care homes absent from the subject. The average of such a corpus says almost nothing; the shape of the distribution says everything, and it is that shape the monthly edition makes visible.

Multiple domains per institution. A single hospital often accumulates a historical domain, the grouping's domain, per-site or per-activity domains — recruitment, foundation, events. The attacker picks the least guarded door: a strict policy on the main domain poorly protects an institution whose recruitment domain, the one that spontaneously writes to candidates, stays on none. Dormant domains — former identities, past mergers — lock down with two records all the same: an SPF v=spf1 -all and a DMARC p=reject. It is the least costly worksite in the whole sector.

Invalid records. Hospital DNS has often crossed several providers and several mergers; it keeps the scars — duplicated records, faulty syntax, an orphan reporting address. An invalid policy is equivalent to an absence, and only a regular reading detects it.

The current standard, DMARCbis (RFC 9989 to 9991), refines the reading of these records: the pct tag has disappeared in favour of the test mode t=y, policy discovery follows the DNS Tree Walk, and the np= tag covers non-existent subdomains — a favourite target of "technical" impersonations. The v=DMARC1 header remains backward-compatible. A mature policy for a hospital domain looks like:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; sp=reject; np=reject

Health data hosting, the CaRE programme, NIS2: a framework pushing the same way

The sector does not advance alone: three frameworks push, each in its own way, toward authenticated mail.

Health-data-hosting certification governs the storage of health data: an institution or its provider must entrust that data to a certified host. It is a necessary foundation, but it says nothing about the email channel: a hospital can be impeccable on the hosting of its patient record and leave its domain freely spoofable. The two subjects are disjoint, and the second long remained in the blind spot.

The CaRE programme, launched in late 2023 to accelerate the cybersecurity of healthcare institutions, changed the picture: earmarked funding, audits of the internet-facing surface, crisis exercises. Domain security — DNS, mail authentication — enters this movement naturally, because it ticks the programme's two boxes: inexpensive, with immediate effect.

NIS2, finally, brings part of the healthcare actors into the scope of essential entities: documented risk management, proportionate protection measures, incident notification. The directive does not name DMARC — like most texts, it imposes a result, not a means. But a domain left on p=none despite reports showing abuse becomes a position hard to defend before an auditor or an authority.

To this is added a pressure with no statute behind it: since 2024, Gmail and Yahoo require sender authentication at volume, and Microsoft followed in 2025. Appointment reminders that no longer arrive mean missed consultations — deliverability here is a public-health subject before it is a marketing one.

Remediating with the means of a hospital IT department

The DMARC remediation of a healthcare institution cannot be conceived like a bank's: no dedicated team, on-call duty already saturated, an information system where the patient record will always come before the DNS. The approach has to account for this — and it is possible, because DMARC lends itself well to discontinuous effort.

The first step carries no risk: publishing p=none with a reporting address and letting the data accumulate. No message is blocked, the inventory builds itself — the institution's mail service (often Microsoft 365 or a shared host), the appointment-booking platform, the payroll and HR tools, the institutional newsletters, the result servers. Each identified source is then aligned — SPF, DKIM — as work allows, between two emergencies.

The second move is locking down the domains that send nothing: a few minutes per domain, a definitive gain. The third is the step-by-step hardening of the main domain — quarantine then reject, drawing on DMARCbis's t=y test mode to mark the climb. At each step, the reports say whether a legitimate flow would be affected before it actually is.

The limiting factor is almost never the technique, it is the analysis time: raw XML reports, nobody at the hospital will read them. Tooled operation — aggregation, source identification, alerts — brings the subject down to a few decisions a month, a format compatible with a shared IT department. The complete tour of the subject for the sector, providers and business software included, is mapped out in the guide devoted to healthcare-institution mail.

Impersonating a healthcare domain is a patient risk

What truly sets this corpus apart from all the others still has to be named: the nature of the risk. Impersonating a banking domain steals money; the French banks barometer shows a sector that understood this long ago, driven by fraud and by its regulator. Impersonating a healthcare domain reaches people at the moment they are vulnerable.

A fake results message redirecting to a counterfeit portal harvests complete identities. A fake appointment cancellation delays care. A fake stay invoice diverts a family's payment. A fake message from management to a care worker opens the door to the information system — and the ransomware scenario returns, the one that cancels operating theatres. In each of these scenarios, the spoofed domain is the instrument, and the final victim is not the institution: it is the patient.

That is why protecting the domain is a matter of care safety in the same way as hand hygiene — an inexpensive preventive measure whose absence shows only at the moment of the incident. The mechanisms by which an unprotected domain gets exploited, and the countermeasures in the useful order, are detailed in preventing phishing in a domain's name.

In summary

French healthcare accumulates everything that draws impersonation: irrevocable data, a vital dependence on service continuity, a human surface under strain — and a landscape of extreme heterogeneity, from the audited university hospital to the care home with no IT staff. The DMARC posture of this landscape is measured at the public DNS, domain by domain; the useful reading is not "having a record" but "applying a policy", and p=none has never blocked a single impersonation. The structural patterns — university hospitals relatively ahead, long tail, multiple and dormant domains, invalid records — point to worksites whose first one costs almost nothing. Health-data hosting, CaRE and NIS2 push in the same direction, each through its own lever. The month's figures, for their part, live in the Observatory's monthly edition, refreshed reading after reading.

The extension comes in two moves. Running an institution's domain through the online analyzer situates its position within seconds on the same scale as the barometer — presence, validity, effective policy, subdomains. And creating an account opens continuous monitoring, aggregate reports in hand, to steer the policy toward p=reject at the pace a hospital IT department can genuinely hold.