---
title: "DORA Compliance for Email: Map DMARC to Art. 9-11"
description: "DORA compliance for email, mapped to Articles 9, 10 and 11. How DMARC, SPF, MTA-STS and TLS-RPT meet the regulation's data-in-transit duties."
publishedAt: 2026-06-29
tags: ["dora", "compliance", "email-authentication", "dmarc", "mta-sts", "tls-rpt", "nis2", "bafin"]
faq:
- question: "Which DORA Article covers email authentication?"
answer: "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."
- question: "Does DORA require DMARC?"
answer: "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."
- question: "How does BaFin examine email controls under DORA?"
answer: "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."
- question: "Is DORA compliance required in the UK?"
answer: "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."
- question: "What are the penalties for DORA non-compliance?"
answer: "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."
- question: "DORA vs NIS2 — same email requirements?"
answer: "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."
---
# 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](/learn/dmarc/), [SPF](/learn/spf/), [DKIM](/learn/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.
DORA's text is technology-neutral. Neither DORA nor its technical standard
(RTS (EU) 2024/1774) names DMARC, SPF, DKIM, MTA-STS, DANE or TLS-RPT. The
mappings below are reasoned interpretation of a general legal obligation — not
a requirement to deploy a specific, named protocol. We quote the binding text
verbatim so you can verify the reasoning for yourself.
## 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](/learn/mta-sts/) in `enforce` mode tells sending servers to
require TLS and refuse to fall back to cleartext, and [DANE](/learn/dane/) does
the same where DNSSEC is deployed. Pick one for your transport-security posture depending on
your DNS — our [MTA-STS vs DANE](/blog/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](/learn/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.
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](/blog/dmarc-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](/blog/spf-too-many-dns-lookups/)). DANE is
effectively absent: **30 domains out of 5.5 million**.
1. **Publish SPF** with an enforcing qualifier (`-all` or `~all`) and keep the
record inside the ten-DNS-lookup limit. _(Art. 9(2) authenticity.)_
2. **Sign all mail with DKIM** so receivers can verify message integrity.
_(Art. 9(3)(c) integrity.)_
3. **Enforce DMARC** at `p=quarantine` or `p=reject` — not `p=none`. Enforcement
is what turns the policy into containment. _(Art. 9(2), Art. 11 response.)_
4. **Deploy MTA-STS in `enforce` mode** with a TLS-RPT reporting address to
require encrypted transport and detect downgrades. _(Art. 9(3)(a), RTS
Art. 14(1).)_
5. **Add DANE where DNSSEC is signed**, for cryptographically pinned transport
security. _(Art. 9(3)(a).)_
6. **Route `rua` and `ruf` to 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](/tools/dmarc-checker/) or a
full [domain health check](/tools/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.
For the per-Article detail, see our [NIS2 email-security
guide](/blog/nis2-email-security/) (the Article 21 mapping) and our [HIPAA
email-authentication guide](/blog/hipaa-email-authentication/) (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](/blog/nis2-email-security/) 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=none` record detects but never contains;
Article 11 response means `p=reject` and MTA-STS `enforce`.
The fastest way to know where your domain stands is to test it.
{/* TODO (links): /blog/email-provider-market-share/ publishes 2026-07-02, AFTER this post's 2026-06-29 date — do NOT link it. Not referenced in this draft; noted for future "related posts" pass once it is live. */}