DORA and NIS2: where EU regulators land on email authentication in 2026

DORA became applicable on 17 January 2025. NIS2 had a 17 October 2024 transposition deadline, followed by uneven national implementation and Commission pressure on Member States that had not fully notified their laws. For security teams, the practical question is narrower than the legislative timeline: what evidence will a supervisor or auditor expect when phishing and impersonation risk comes up?

Neither the DORA regulation nor the NIS2 directive says "DMARC" in the main legal text. They use broader language: detection, protection, cyber hygiene, supply-chain security, secure communications, and measures appropriate to the risk. That is the point. The law defines the outcome; the technical baseline fills in the mechanics.

What DORA asks for

DORA applies to financial entities: banks, insurers, investment firms, payment providers, crypto-asset service providers, trading venues, and other financial-sector categories. It also formalises oversight of critical ICT third-party providers that those entities depend on.

The email-authentication case usually comes through Article 10 and the ICT risk-management RTS. Article 10 requires mechanisms to promptly detect anomalous activities and ICT-related incidents. The delegated RTS requires financial entities to maintain ICT security policies, network security controls, logging, access control, monitoring, and measures that fit the risk profile of the assets involved.

For large institutions this is usually mature already. The harder cases are fintechs, EMIs, crypto custodians, broker platforms, and specialist SaaS providers that grew their sender estate faster than their governance process. DORA does not need to name a DNS record for an auditor to ask how the organisation prevents its domains from being used in phishing.

What NIS2 asks for

NIS2 is broader than DORA. It covers essential and important entities across energy, transport, banking, health, drinking water, digital infrastructure, managed services, public administration, manufacturing of critical products, food, postal services, waste management, chemicals, and research. The exact scope depends on sector, size, and national transposition.

Article 21 sets the minimum cybersecurity risk-management measures. Two are directly relevant to email authentication:

• Supply-chain security - direct suppliers and service providers must be understood and governed. Email platforms, CRMs, support desks, billing systems, and marketing senders are part of that dependency map.
• Basic cyber hygiene and training - staff awareness matters, but so does removing cheap impersonation paths before the message reaches a user.

The NIS2 implementing regulation for the digital-provider subset does not turn the whole directive into a DMARC checklist. It does, however, point relevant entities toward modern email communication standards, phishing protection, safe email use, and controls that reduce exposure to malicious content. SPF, DKIM, and DMARC are the protocol-layer controls that make sender authentication observable.

Why "state of the art" matters

European cybersecurity rules lean heavily on state-of-the-art language because the laws age more slowly than technical controls. Email authentication is not new or exotic in 2026. DMARC has been deployed at internet scale for years, and public-sector guidance across Europe treats SPF, DKIM, and DMARC as normal controls for reducing domain spoofing.

That changes the burden of explanation. If an in-scope organisation leaves its primary domain at p=none, or owns twenty parked domains with no DMARC record, the question is no longer "does the regulation literally require this TXT record?" The question is "why is this known phishing control absent?"

What the evidence package should contain

The evidence looks similar across DORA, NIS2, PCI, and internal audit because the control problem is the same: prove that the domain estate is known, authenticated, monitored, and governed.

This is where aggregate DMARC reports matter. The record is intent. The report stream is operating evidence. It shows who actually sent mail, whether it aligned, which third party owns the source, and whether new unaligned senders were investigated.

The common gaps

Third-party senders are not owned. A CRM or support platform signs mail, but nobody can say who approved it, when the vendor was configured, or whether DKIM uses the organisation's domain. Under DORA and NIS2, that is both an email issue and a supplier governance issue.

Training is treated as the control. Awareness training helps, but it is weak evidence for domain impersonation risk by itself. If an attacker can spoof the organisation's own domain, the technical control is missing upstream of the user.

Parked and acquired domains are out of scope. Attackers do not care which domain the security team considers official. If a related domain has no SPF, no DKIM, and no DMARC enforcement, it is still useful for fraud. The same principle applies to defensive registrations, old regional domains, and abandoned campaign domains.

What to do first

1. Build the domain inventory, including non-sending domains and domains held by subsidiaries or acquired brands.
2. Publish DMARC reporting everywhere so the evidence stream starts before the audit request arrives.
3. Classify every source in the reports as authorised, forwarded, unknown, or unauthorised.
4. Fix DKIM alignment for owned senders, then promote policy through quarantine and reject where the data is clean.

DMARCify is not a DORA or NIS2 consultancy. It is the system that turns the email side of the requirement into evidence: domain inventory, sender classification, aggregate reports, DNS-change history, and a policy path that can be explained to a supervisor.