NIS2 Email Security: Mapping Article 21 Controls to DMARC, MTA-STS, and Dane

meysamazad2 pts0 comments

NIS2 Email Security: Article 21 → DMARC, MTA-STS, DANE | DMARCguardSkip to main content<br>17 min readShare

NIS2 Email Security: Mapping Article 21 Controls to DMARC, MTA-STS, and DANE<br>NIS2 compliance is now a board-level duty across the EU. The transposition deadline was 17 October 2024, and national enforcement is rolling out right now — Germany’s law took effect 6 December 2025 — yet the email-security controls NIS2 implies are barely deployed.<br>Key finding12.8% / 0.3% / 0.0% of domains enforce DMARC, publish MTA-STS, and run DANE respectively<br>Source: DMARCguard scan of 5,499,028 domains, Feb 2026This guide is for IT admins and founder-operators at in-scope EU entities — and the suppliers they pull in under Article 21(2)(d) — who need to know which email controls actually satisfy the Network and Information Security Directive (EU) 2022/2555. We give you a letter-by-letter map of Article 21(2)(d), (g), and (h) to the email-auth protocols, copy-paste DNS checks, and a backward-planned deployment timeline for 2026 audit readiness.<br>One honest note up front: NIS2’s text names no protocol. This guide shows the defensible interpretation and cites the exact clauses, so you can tell the difference between what the law says and what vendors claim it says.<br>What does NIS2 require for email security?<br>NIS2 does not name a single email protocol. The Network and Information Security Directive (EU) 2022/2555, Article 21(2), requires “appropriate and proportionate technical, operational and organisational measures” — and the only explicit email obligation in the binding text sits in Commission Implementing Regulation (EU) 2024/2690, which calls for “modern e-mail communications standards” without naming SPF, DKIM, DMARC, MTA-STS, DANE, or TLS-RPT.<br>The Directive’s chapeau is deliberately broad. Article 21(1) requires entities to “take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems,” and Article 21(2) frames those measures around an “all-hazards approach” covering at least ten listed areas (EUR-Lex, Directive (EU) 2022/2555). None of the ten names a protocol.<br>The one binding clause that mentions email is in the Implementing Regulation. Its Annex, point 6.7.2(k), requires in-scope entities to:<br>adopt an implementation plan for the deployment of internationally agreed and interoperable modern e-mail communications standards to secure e-mail communications to mitigate vulnerabilities linked to e-mail-related threats and establish measures to accelerate such deployment

That clause binds only a defined set of digital-sector entities — DNS providers, TLD registries, cloud, data-centre and CDN providers, MSPs, MSSPs, online marketplaces, search engines, social networks, and trust-service providers (EUR-Lex, Implementing Regulation (EU) 2024/2690).<br>If you are not a digital-sector entity, the email duty still reaches you — just indirectly. It comes through the general cryptography duty in Article 21(2)(h) and the secured-communications duty in 21(2)(j), as transposed nationally, with the Annex as the best-practice benchmark. ENISA’s June 2025 Technical Implementation Guidance (v1.0, 170 pages) fills in practical detail, but it is explicitly non-binding and technology-neutral, and it does not mandate any named protocol either (ENISA guidance).<br>Article 21(2)(d), (g), (h): the three controls that map to email<br>Three of Article 21(2)‘s ten measures map directly to email authentication: (h) cryptography and encryption maps to transport security (MTA-STS, DANE, TLS-RPT, TLS); (d) supply-chain security maps to sender authentication on you and your suppliers (DMARC, SPF, DKIM); and (g) basic cyber hygiene maps to DMARC enforcement as a baseline. This map is our interpretation — NIS2 names no protocol — but it is the defensible reading of the text.<br>Here is the wedge no vendor publishes: the legal sub-paragraph, what it requires in plain terms, the protocols that satisfy it, and where adoption actually sits.<br>Article 21(2) sub-paragraph (verbatim hook)What it requires (plain)Email-auth protocols that satisfy itFirst-party adoption (Feb 2026)(h) “policies and procedures regarding the use of cryptography and, where appropriate, encryption”Encrypt mail in transit; resist STARTTLS downgradeMTA-STS (RFC 8461), DANE (RFC 6698/7672), TLS-RPT (RFC 8460)MTA-STS 0.3%; DANE 0.0% (30 domains)(d) “supply chain security … relationships between each entity and its direct suppliers”Trust mail from suppliers; stop spoofed sendersDMARC enforcement (RFC 9989), SPF (RFC 7208), DKIM (RFC 6376)30.4% publish DMARC; only 12.8% enforce(g) “basic cyber hygiene practices and cybersecurity training”Baseline anti-spoofing hygieneDMARC enforcement (p=quarantine / p=reject)12.8% enforce; 40.8% have no auth

NIS2 Article 21(2) sub-paragraphs mapped to email-auth protocols. The mapping is DMARCguard's reasoned interpretation; the Directive and Implementing Regulation...

email article security nis2 dmarc dane

Related Articles