DORA Compliance for Email: Mapping Sender Authentication to Articles 9, 10 and 11
DORA compliance for email starts with one fact: DORA — Regulation (EU) 2022/2554 — has applied to EU financial entities since 17 January 2025, and it names no email protocol. Its Article 9 duty to preserve the authenticity, integrity and confidentiality of data, whether at rest, in use or in transit is where DMARC, SPF, DKIM, MTA-STS and TLS-RPT actually do the work.
That gap — between a technology-neutral regulation and the concrete email controls that satisfy it — is what this guide closes. If you are an IT administrator or compliance owner at one of the 20 categories of “financial entities” listed in DORA Article 2(1)(a)–(t), you have read plenty of vendor pages that stop at transport encryption. Almost none map sender authentication to a numbered DORA Article. This one does.
You will get the exact Article-to-protocol map, an email-control checklist, the BaFin and German-language position, and the interpretive caveat that keeps every claim defensible.
What DORA actually requires of email (and what it doesn’t)
DORA does not mention email, DMARC, SPF or DKIM anywhere in its text. The binding hooks for email security are Article 9(2) (authenticity, integrity and confidentiality of data in transit), Article 9(3)(a) (security of the means of transfer of data), and Article 9(3)(c) (authenticity and integrity) — operationalised by the Level-2 standard, RTS (EU) 2024/1774, at Article 6 (encryption policy) and Article 14(1) (securing information in transit).
That is the whole of what DORA “requires of email”: not a protocol, but an outcome. Article 9(2) sets it out in full — financial entities must “maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit.” The means is left to the entity. Article 9(3)(a) then asks ICT solutions to “ensure the security of the means of transfer of data,” and Article 9(3)(c) to “prevent … the impairment of the authenticity and integrity … and the loss of data.”
The transmission clause is 9(3)(a) — nothing else. These are three different sub-paragraphs with three different jobs, and conflating them is a common slip:
- Art. 9(3)(a) → transmission (the data-in-transit duty).
- Art. 9(4)(b) → network and infrastructure management (segmentation and isolation).
- Art. 9(4)(c) → access control.
Do not cite the network-security or access-control clauses as “data-in-transit” duties.
For email, the single most relevant Level-2 clause is RTS Article 14(1). The Level-2 detail lives in Commission Delegated Regulation (EU) 2024/1774 (the RTS on ICT risk management, adopted 13 March 2024). Article 6(2) requires the entity’s encryption policy to cover “the encryption of data at rest and in transit” and “the encryption of internal network connections and traffic with external parties.” Article 14(1) goes further: financial entities must implement tools to ensure “the availability, authenticity, integrity and confidentiality of data during network transmission” and “the secure transfer of information between the financial entity and external parties.” That phrase — secure transfer to external parties — is the closest hook email security has in the entire framework. No protocol is named.
This is where competitor guidance is genuinely strong, and worth crediting before the pivot: transport encryption, recipient multi-factor authentication on sensitive messages, and data-loss prevention for human error are all real controls that real vendors cover well. What none of them do is connect the sender-authentication layer — proving a message is from who it claims — back to a specific Article. That is the rest of this guide.
Mapping DMARC, SPF, MTA-STS and TLS-RPT to DORA Articles 9, 10 and 11
The mapping runs three ways. Protection (Article 9) is met by sender authentication plus encrypted transport. Detection (Article 10) is met by treating DMARC aggregate and forensic reporting as anomaly telemetry. Response (Article 11) is met by enforcement posture as containment, with failure reports retained as incident evidence. Below is the DORA Articles 9–11 mapping no competitor publishes — sender authentication tied to numbered provisions, every row labelled as interpretation.
| DORA provision (verbatim hook) | What it asks for | Email control (interpretation) | RFC |
|---|---|---|---|
| Art. 9(2) / 9(3)(c) — authenticity & integrity of data | Prove a message is from who it claims | SPF + DKIM + DMARC p=quarantine|reject — anti-spoofing / anti-BEC on the sender side | 7208 / 6376 / 7489 |
| Art. 9(3)(a) — security of the means of transfer; RTS Art. 6(2) / 14(1) — secure transfer to external parties | Encrypt mail in transit; prevent TLS downgrade | MTA-STS in enforce mode + TLS-RPT; DANE where DNSSEC is supported | 8461 / 8460 / 6698, 7672 |
| Art. 10 — detection (anomalies + alert thresholds) | Telemetry to detect anomalous activity | DMARC aggregate (rua) + forensic (ruf) reports as a detection feed | 7489 |
| Art. 11 / 11(7) — response + evidence retention | Contain incidents; keep records for root-cause | Enforcement (DMARC p=reject, MTA-STS enforce) as containment; TLS-RPT + ruf as evidence | 8460 / 7489 |
| Art. 28-30 — ICT third-party risk | Inventory third-party ICT services | SPF include: chain + DKIM third-party signers = your email-vendor inventory | 7208 / 6376 |
Reading the rows in order:
Article 9(2) and 9(3)(c) — authenticity and integrity. The duty to preserve authenticity and integrity is, for email, the duty to prove a message genuinely originates from your domain. SPF authorises sending hosts, DKIM cryptographically signs the message, and DMARC ties both to the visible From: domain and sets an enforced policy. A DMARC record at p=quarantine or p=reject is the control that turns “we publish records” into “spoofed mail is actually rejected.” This is distinct from the recipient-side MFA that some vendors map to Articles 20 and 21: that secures who reads a message; sender authentication secures who sent it. Both matter; only one is covered here.
Article 9(3)(a) and RTS Articles 6(2) / 14(1) — encryption in transit. “Security of the means of transfer of data” and “secure transfer … between the financial entity and external parties” describe encrypted, downgrade-resistant transport. MTA-STS in enforce mode tells sending servers to require TLS and refuse to fall back to cleartext, and DANE does the same where DNSSEC is deployed. Pick one for your transport-security posture depending on your DNS — our MTA-STS vs DANE comparison covers the trade-off.
Article 10 — detection. Article 10 requires mechanisms “to promptly detect anomalous activities” and to “define alert thresholds.” DMARC aggregate reports (rua) give you a daily feed of every source sending as your domain; TLS-RPT reports surface failed or downgraded TLS handshakes. Routed to a monitored mailbox, these are precisely the anomaly telemetry Article 10 asks for — a sudden spike in unauthenticated sources is a detectable signal.
Article 11 — response and evidence. Article 11(2)(c) calls for containment measures, and Article 11(7) requires entities to “keep readily accessible records of activities before and during disruption events.” Enforcement — DMARC p=reject, MTA-STS enforce — is the containment: it stops spoofed and downgraded mail at the door. The ruf failure reports and TLS-RPT records are the retained evidence that feeds root-cause analysis (DORA’s explicit root-cause duty sits in Article 13, fed by the Article 11(7) records).
Articles 28-30 — third-party risk. Your SPF include: chain and your list of DKIM third-party signers are, in effect, an inventory of every vendor authorised to send mail as you. That maps cleanly onto the ICT third-party risk register DORA requires — an under-used way to keep your email-vendor list honest.
The email-authentication checklist DORA’s data-in-transit duties imply
Six controls, each tied to the Article it serves: publish SPF with -all or ~all, sign with DKIM, enforce DMARC at p=quarantine or p=reject, deploy MTA-STS in enforce mode with TLS-RPT, add DANE where DNSSEC is in place, and route DMARC rua and ruf to a monitored mailbox. None is named in DORA; each is a defensible way to meet a duty that is.
0.3% of domains deploy MTA-STS — 15,997 of 5,499,028 scanned (DMARCguard, Feb 2026). The encryption-in-transit control Article 9(3)(a) most directly implies is the one almost no domain has.
The wider picture from the same scan is sobering for a sector DORA holds to “high standards” of data-in-transit protection. DMARC adoption sits at 30.4% (1,670,975 domains), but only 12.8% actually enforce with p=quarantine or p=reject — the rest publish p=none, which detects but never contains: the enforcement gap most domains never close. SPF is more common at 56.0% (3,077,219 domains), yet 4.8% of those records (148,655) exceed the RFC 7208 ten-lookup limit and fail validation (see how to fix SPF too many DNS lookups). DANE is effectively absent: 30 domains out of 5.5 million.
- Publish SPF with an enforcing qualifier (
-allor~all) and keep the record inside the ten-DNS-lookup limit. (Art. 9(2) authenticity.) - Sign all mail with DKIM so receivers can verify message integrity. (Art. 9(3)(c) integrity.)
- Enforce DMARC at
p=quarantineorp=reject— notp=none. Enforcement is what turns the policy into containment. (Art. 9(2), Art. 11 response.) - Deploy MTA-STS in
enforcemode with a TLS-RPT reporting address to require encrypted transport and detect downgrades. (Art. 9(3)(a), RTS Art. 14(1).) - Add DANE where DNSSEC is signed, for cryptographically pinned transport security. (Art. 9(3)(a).)
- Route
ruaandrufto a monitored mailbox so the reports become a detection feed and a retained evidence trail. (Art. 10 detection, Art. 11(7) evidence.)
You can also start with a quick DMARC record check or a full domain health check to see where you stand before working through the list.
BaFin, MaRisk, BAIT and VAIT — what changed for German financial entities
Since 17 January 2025, BaFin supervises ICT risk for German Finanzunternehmen under one DORA framework (IKT-Risikomanagement). The sectoral outsourcing rules in MaRisk and MaGo remain in force “parallel und komplementär,” but the ICT-risk technical content has moved to DORA.
The xAIT timeline has a phased-repeal caveat that vendor blogs routinely compress. KAIT, VAIT and ZAIT lapsed at the end of 16 January 2025. BAIT did not vanish on that date — institutions running DORA ICT-risk management from 17 January 2025 were excluded from BAIT’s scope and Chapter 11 was repealed, but the full repeal lands only at the end of 31 December 2026. Writing “BAIT abolished in January 2025” without that caveat is inaccurate for the transition-group institutions still under it.
MaRisk itself does not address email. Its nearest IT-security provision is the AT 7.2 “Schutzziele” — the protection goals of Integrität, Verfügbarkeit, Authentizität and Vertraulichkeit (integrity, availability, authenticity and confidentiality), the BSI’s classic Grundwerte der Informationssicherheit. Those four goals are exactly what sender authentication and encrypted transport serve, but MaRisk names no mechanism. On the supervisory plumbing: BaFin is now Germany’s national reporting hub for ICT incidents in the financial sector, the Deutsche Bundesbank is joint implementer, and the ECB supervises significant institutions — none of which changes the substantive Article 9 duties on the entity.
For German-language searches, the binding regulation uses specific spellings. This is the canonical terminology, drawn from the German EUR-Lex edition and BaFin’s own publications — not a loose translation:
| English term | Binding German term (EUR-Lex / BaFin) | Where |
|---|---|---|
| data in transit | ”übermittelt” / “Datenübermittlungsmittel” | Art. 9(2), 9(3)(a) |
| authenticity & integrity | ”Authentizität und Integrität” | Art. 9(2), 9(3)(c) |
| ICT risk management | ”IKT-Risikomanagement” | BaFin DORA overview |
| ICT third-party risk | ”IKT-Drittparteienrisiko(management)“ | BaFin Aufsichtsmitteilung |
| encryption / cryptographic controls | ”Verschlüsselung und kryptografische Kontrollen” | RTS 2024/1774 Art. 6 |
| network security | ”Netzwerk- und Infrastrukturmanagement” | Art. 9(4)(b) |
| financial entity | ”Finanzunternehmen” | DORA Art. 2 (DE) |
A note on the German wording: the binding text uses übermittelt and Datenübermittlungsmittel; the colloquial Daten bei der Übertragung is a common rendering but is not the regulation’s own phrasing, so we treat it as a synonym only. And the same defensibility caveat applies in German as in English: no BaFin or DORA primary source names an email-specific or DMARC/SPF/DKIM requirement. Email authentication is a means of meeting the general authenticity-, integrity- and transmission-security duties — not a named regulatory mandate.
Who must comply, and since when
DORA applies to 20 categories of “financial entities” listed in Article 2(1)(a)–(t) — credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, insurers and certain intermediaries, market infrastructures, credit rating agencies, crowdfunding service providers and more — and it has applied since 17 January 2025 with no general grandfathering of the core obligations. Article 64 is explicit: the Regulation “shall apply from 17 January 2025,” and as a Regulation it is “binding in its entirety and directly applicable in all Member States” — no national transposition required, unlike a Directive.
A few scope details worth knowing:
- Proportionality. Article 16 provides a simplified ICT-risk framework for small and non-interconnected firms, and microenterprises (fewer than 10 staff and under EUR 2 million turnover or balance sheet) receive further reliefs.
- ICT third-party service providers (Article 2(1)(u)) are not “financial entities” themselves but are pulled in through the Article 28-30 contractual regime, and directly under the Oversight Framework only if designated critical under Article 31. Per the European Supervisory Authorities (ESAs), the first 19 critical providers were designated on 18 November 2025 — large cloud and platform operators including Amazon Web Services, Google Cloud, Microsoft, Oracle, SAP and Deutsche Telekom.
- The framing is “already in scope,” not a looming deadline. DORA is live; the question is whether your controls are.
DORA vs NIS2 vs HIPAA — the same email controls, three mandates
DORA, NIS2 and HIPAA each impose technology-neutral data-protection duties that the same sender-authentication and encrypted-transport stack satisfies. None names DMARC — but a single SPF/DKIM/DMARC/MTA-STS/TLS-RPT deployment maps to all three. This is the core of the DORA/NIS2 overlap: you are not building three email programmes, you are building one and citing it three ways.
| Mandate | Scope | Binding hook (no protocol named) | Shared email control |
|---|---|---|---|
| DORA | EU financial sector (Art. 2 financial entities) | Art. 9(2)/(3) authenticity & integrity in transit | SPF + DKIM + DMARC enforce; MTA-STS + TLS-RPT |
| NIS2 | EU essential & important entities | Art. 21(2) cyber-hygiene & comms-security measures | SPF + DKIM + DMARC enforce; MTA-STS + TLS-RPT |
| HIPAA | US protected health information (PHI) | Security Rule §164.312 transmission security & integrity | SPF + DKIM + DMARC enforce; MTA-STS + TLS-RPT |
For the per-Article detail, see our NIS2 email-security guide (the Article 21 mapping) and our HIPAA email-authentication guide (the §164.312 mapping). The pattern is identical each time: a technology-neutral obligation, an unfilled mapping, and the same stack that closes it.
Frequently asked questions
Which DORA Article covers email authentication?
None names it explicitly. The relevant hooks are Article 9(2), 9(3)(a) and 9(3)(c) — the duties to preserve the authenticity, integrity and confidentiality of data in transit and to secure the means of data transfer — operationalised by RTS (EU) 2024/1774, Articles 6 and 14(1). Sender-authentication protocols are one way to meet these technology-neutral duties.
Does DORA require DMARC?
No. DORA names no email protocol. But DMARC with p=quarantine or p=reject is a reasonable means of meeting the Article 9 duty to preserve the authenticity and integrity of data in transit and to secure the means of data transfer. The mapping is interpretation of a technology-neutral obligation, not a literal requirement to deploy a named protocol.
How does BaFin examine email controls under DORA?
BaFin enforces DORA Article 9 directly and has published no email-specific or DMARC/SPF/DKIM requirement. KAIT, VAIT and ZAIT were repealed with effect from the end of 16 January 2025, and BAIT is fully repealed with effect from the end of 31 December 2026. MaRisk’s AT 7.2 protection goals remain the nearest IT-security wording.
Is DORA compliance required in the UK?
DORA is an EU Regulation; it binds EU and EEA financial entities, not UK-only firms. UK groups with EU subsidiaries, or that provide ICT services to EU financial entities, are pulled in through those entities and the Article 28-30 third-party regime.
What are the penalties for DORA non-compliance?
Competent authorities may impose administrative measures and periodic penalty payments under DORA’s enforcement provisions; for critical ICT third-party providers the regime includes a daily lump-sum mechanism. This guide focuses on meeting the controls, not on penalty figures.
DORA vs NIS2 — same email requirements?
Different scope — the financial sector versus essential and important entities — but overlapping technology-neutral duties. The same SPF/DKIM/DMARC/MTA-STS/TLS-RPT stack maps to both, and neither names a protocol. See our NIS2 email-security guide for the Article 21 mapping.
The bottom line
DORA compliance for email is less complicated than vendor pages suggest, because the regulation is honest about being technology-neutral:
- DORA names no protocol. Articles 9, 10 and 11 are the email hooks — protection, detection and response — and RTS (EU) 2024/1774 Articles 6 and 14(1) supply the encryption and transmission detail.
- The sender-authentication → Article map is the gap nobody else fills. Vendors stop at transport encryption and recipient MFA; tying SPF, DKIM and DMARC to specific Articles is the missing piece.
- German entities follow BaFin’s xAIT → DORA transition — KAIT/VAIT/ZAIT gone from 16 January 2025, BAIT fully repealed from 31 December 2026, MaRisk’s AT 7.2 protection goals the nearest wording.
- One stack, three mandates. The same controls satisfy NIS2 and HIPAA.
- Enforcement is what counts. A
p=nonerecord detects but never contains; Article 11 response meansp=rejectand MTA-STSenforce.
The fastest way to know where your domain stands is to test it.