DORA and email: what the regulation expects of email authentication

DMARC within the DORA framework

DMARC answers several DORA requirements at once, which makes it a high-leverage control:

• Protection (pillar 1). At an enforcement policy, DMARC prevents direct spoofing of the domain — a concrete, durable protection measure against a first-rank attack vector.
• Detection (pillar 1). Aggregate reports continuously reveal who sends in the entity's name, including illegitimate sources or forgotten providers. It is a permanent sensor plugged into the exposure surface.
• Incident management (pillar 2). The history of reports and posture documents the entity's diligence and helps qualify a spoofing incident when one occurs.
• Third-party risk (pillar 4). A sending estate almost always includes providers (billing, statements, marketing, e-signature). Mapping and aligning those sources is exactly the dependency inventory DORA calls for on the email side.

As for any institution that sends mail in volume, the underlying reasoning is the one developed for DMARC in banking: financial brands are the most spoofed in the world, and enforced DMARC is the first structural line of defence.

The consumer-domain trap

One point deserves special attention for financial groups. Many run a polished, protected corporate domain — the one for press releases and investor relations — while the consumer-facing brand domain, the one clients actually receive statements and alerts from, lags at p=none. Attackers do not target the corporate domain: they target the one clients recognise and trust.

Under DORA, this asymmetry is a dangerous blind spot. Any compliance assessment must look first at the domain clients see in their inbox, not just at the holding company. Our per-domain check pages give the verdict for the exact domain entered, which makes it easy to distinguish a protected corporate from an exposed consumer domain.

The compliance roadmap

The sequence is that of any large sender, executed with the documentary rigour DORA demands:

1. Mapping the entire sending estate, business by business, region by region, provider by provider. DMARC goes up at p=none, and the reports reveal the unsuspected sources.
2. Aligning every legitimate source on SPF and DKIM, aiming for durable DKIM alignment.
3. Treating each brand domain separately, prioritising the consumer domain.
4. Ramping policy to quarantine then reject, watching the reports — the full method is in getting to p=reject without breaking legitimate email.
5. Documenting and retaining. Archived reports, decisions and posture history: that is the probative material DORA demands, and it reuses as-is in an ISO 27001 arrangement.

If the group also falls under NIS2 for its non-strictly-financial activities, both projects run as one: the authentication foundation is identical, only the supervisory regime changes, as detailed on the NIS2 and email authentication side.

Classification, reporting and email's role

DORA requires classifying ICT-related incidents and reporting the most serious ones to competent authorities within short deadlines, with an initial report, an intermediate report, then a final report. The severity criteria include the number of clients affected, the duration, the geographic spread and the financial losses — all thresholds that a successful spoofing campaign can cross quickly. A fake email appearing to come from the bank and harvesting the credentials of thousands of clients is not a minor incident: it is potentially a reportable major incident, with the full weight of notification, investigation and communication it implies.

Hence the value of a control that acts at the root. Each spoofed message DMARC blocks upstream is an incident that does not happen — so no threshold crossed, no report, no regulatory investigation. Conversely, the absence of authentication leaves open an incident path that will have to be handled reactively, under the pressure of the regulatory clock. Reducing the frequency of spoofing incidents directly reduces the DORA notification load — an operational argument as much as a security one.

A concrete scenario

Let's take a mid-sized asset manager. An attacker spoofs the consumer-facing domain clients receive their statements from, which stayed at p=none. He sends a portfolio of clients a perfectly credible email announcing a "change of bank details for redemptions", displaying the firm's authentic address. A few clients follow the instruction; funds leave for an account the attacker controls.

DORA sequence: the event probably exceeds the severity thresholds (clients affected, financial losses), triggering a notification to authorities, an internal investigation, crisis communication, and the inevitable review of the question "why was the domain spoofable?". The answer "it was at p=none" is untenable before a regulator that expects demonstrable resilience. The same incident, with the domain at p=reject, would simply never have reached the clients' inboxes: the forged message would have been rejected at delivery. That is the difference between a control that merely observes and one that protects.

This scenario is nothing exceptional; it replays, with minor variants, whenever a financial domain stays in observation-only mode. And it illustrates why DORA insists so much on demonstration: what counts is not having a plan, but being able to prove the control was in place, active and monitored at the time of the events. An enforced DMARC record, together with its report history, is exactly that kind of proof — dated, public, tamper-evident.

Turning the work into reusable proof

There is a strategic upside to doing this well once: the audit trail travels. The same dossier — p=reject posture, archived RUA reports, documented ramp-up, key management — serves directly to demonstrate diligence under NIS2 for any non-financial activities, and answers the security questions a GDPR review raises. DORA's insistence on demonstrable, tested resilience is demanding, but it rewards controls that are public, dated and continuously monitored. Email authentication is exactly that kind of control, which is why it belongs early in a resilience programme rather than as an afterthought once an incident has already forced the question. It is also one of the rare measures whose benefit an executive can see at a glance — a public record that flips from none to reject — which makes it unusually easy to report upward and to defend in front of a supervisor.

Where the domain actually stands

As always, the first step is free and immediate. A pass of the domain clients actually receive mail from through our free DMARC analyzer gives an instant verdict; the DMARC Observatory then places the institution among its peers, tracking the public posture of major financial brands across several countries.

Bringing a large regulated estate to p=reject with a usable audit trail is precisely the mission of Thomas, the virtual CISO: he identifies every sending source, produces the exact DNS to publish, assesses per-domain readiness on rolling data, and flags when each domain can be enforced without risk to legitimate mail. Free domain analysis · exploring the Observatory · getting started with Thomas.