DORA Compliance for Email: Map DMARC to Art. 9-11 | DMARCguard Skip to main content<br>17 min read Share

DORA Compliance for Email: Mapping Sender Authentication to Articles 9, 10 and 11<br>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.<br>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.<br>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.<br>One caveat, stated up front<br>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)<br>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).<br>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.”<br>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:<br>Art. 9(3)(a) → transmission (the data-in-transit duty).<br>Art. 9(4)(b) → network and infrastructure management (segmentation and isolation).<br>Art. 9(4)(c) → access control.<br>Do not cite the network-security or access-control clauses as “data-in-transit” duties.<br>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.<br>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.<br>Mapping DMARC, SPF, MTA-STS and TLS-RPT to DORA Articles 9, 10 and 11<br>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.<br>DORA provision (verbatim hook)What it asks forEmail control (interpretation)RFCArt. 9(2) / 9(3)(c) — authenticity & integrity of dataProve a message is from who it claimsSPF + DKIM + DMARC...