Email Security Under NIS2: ‘DMARC’ Appears 0 Times in the Law — What CIR 6.7.2(k) Requires Instead

No: neither the NIS2 Directive nor its implementing regulation names DMARC, SPF or DKIM. We searched the official EUR-Lex text of both, and the protocol names appear zero times. But for eleven types of digital provider, one clause does create a binding email-security duty. Point 6.7.2(k) of the Annex to Implementing Regulation (EU) 2024/2690 requires an implementation plan for “internationally agreed and interoperable modern e-mail communications standards”. ENISA’s guidance lists SPF, DKIM and DMARC among the standards to consider, so in practice they form the core of that plan. Every other essential and important entity has to decide for itself, through its risk assessment, whether to deploy them, and has to be able to defend that decision.

Who Is Bound by What: The Short Answer

In plain terms: whether email authentication is a legal duty, a risk-based choice or a commercial requirement depends on what kind of organisation you are. Find your row below.

Who you are	What applies to your email	Status
DNS provider, TLD registry, cloud, data centre, CDN, managed service provider, managed security service provider, online marketplace, search engine, social network or trust service provider	Implementing Regulation 2024/2690, Annex point 6.7.2(k), which is directly applicable	Binding: a documented plan to deploy modern email standards, plus measures to speed up deployment
Any other essential or important entity	Article 21(1)–(2) NIS2, as transposed into your national law	Risk-based: no protocol is named. Your risk assessment has to justify what you deploy, and what you don’t
Dutch government bodies and (semi-)public institutions	The national “comply or explain” list of open standards	Government policy: DMARC, SPF and DKIM are expected unless the body explains why not
Anyone sending about 5,000+ messages a day to Gmail	Google’s sender guidelines	Commercial: SPF, DKIM and DMARC are required for delivery, not by law

A quick decision path:

1. Essential or important entity under your national NIS2 law? If not, only mailbox-provider rules can apply.
2. One of the eleven provider types in Article 1 of the implementing regulation? Then point 6.7.2(k) applies word for word.
3. Otherwise, Article 21 applies through national law. Use 6.7.2(k) as the benchmark and record your decision in the risk register.

What the Law Actually Says About Email

In plain terms: the Directive never treats email as a security topic. Every time it uses the word, it’s about contact details. The email-security wording sits in the implementing regulation, and only one sentence of it is binding.

Article 21(1) of Directive (EU) 2022/2555 requires measures that are “appropriate and proportionate”. They must take account of “the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation”. Article 25(1) then tells Member States to encourage standards “without imposing or discriminating in favour of the use of a particular type of technology”. The Directive is technology-neutral by design. That is why no protocol name appears in it.

Provision	Binding?	What it says	Email relevance
NIS2 Art 21(2)(h)	Yes (via national law)	Policies on cryptography and, where appropriate, encryption	Can cover TLS for mail in transit and S/MIME for sensitive content
NIS2 Art 21(2)(j)	Yes, “where appropriate”	“Secured voice, video and text communications”	Arguably reaches email. The Directive doesn’t say so explicitly
NIS2 Recital 89	No	Awareness of “phishing or social engineering techniques”	The Directive’s only mention of phishing
CIR Recital 19	No	“Deploy email and web application filters”	Inbound filtering
CIR Recital 20	No	“Safe email use and web browsing, protection from phishing”	User hygiene and training
CIR Annex 6.7.2(k)	Yes, for the eleven provider types	Implementation plan for modern email standards	The only operative email-security duty in either text

Recitals explain intent but create no obligations. Only Article 21 and point 6.7.2(k) bind. One structural detail matters for audits: the regulation files point 6.7 under Annex section 6, which implements Article 21(2)(e) (security in acquisition, development and maintenance). It is not filed under the cryptography measure in Article 21(2)(h).

Inside Point 6.7.2(k): Four Phrases That Decide the Obligation

In plain terms: the clause asks for a plan, not a finished configuration. That plan has to cover recognised standards and show how you’ll speed things up. There is no “where appropriate” opt-out.

Here is the full text of Implementing Regulation (EU) 2024/2690, Annex point 6.7.2(k). The relevant entities shall “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”. Four phrases carry the weight:

• “Adopt an implementation plan”. The thing you deliver is a document: dated, owned and approved. A DMARC record stuck at p=none for two years, with no plan behind it, is weaker evidence than a written plan that shows you’re halfway through.
• “Internationally agreed and interoperable”. This points to open standards, not vendor features. Until May 2026, someone could object that DMARC’s own specification, RFC 7489, was published as Informational rather than as an Internet standard. RFC 9989 replaced it in May 2026 as a Standards Track document, which removes that objection.
• “Modern e-mail communications standards” (plural). Authentication alone is half the job. Transport encryption (STARTTLS, DANE) belongs in the plan too.
• “Establish measures to accelerate such deployment”. Without milestones, the plan doesn’t meet the clause.

Two more details matter. Unlike point 6.7.2(g), point (k) carries no “where appropriate” qualifier. That means the documented-reasoning route in Article 2(2) isn’t available for skipping the plan, although proportionality still shapes what goes in it. And point 6.7.3 requires review “at planned intervals” and after significant incidents. Point (k) sits next to point (l), which covers DNS security best practice. As our network security segmentation model shows, section 6.7 is a single control family, so one owner should manage both.

Which Standards Belong in the Plan

In plain terms: ENISA names five standards. Most of the vendor guides we reviewed cover only three. SPF, DKIM and DMARC stop people spoofing your domain. STARTTLS and DANE protect mail while it travels between servers.

ENISA’s Technical Implementation Guidance (June 2025) tells entities to “consider” STARTTLS, DANE, DMARC, DKIM and SPF. It calls this an “indicative, non-exhaustive list”, alongside spam filtering and URL sandboxing. Its footnote points to the European Commission’s internet standards page for email, which lists the same five.

Standard	What it stops	IETF specification	Named by ENISA?
SPF	Mail sent from servers you haven’t authorised (checks the envelope sender)	RFC 7208, Standards Track (2014)	Yes
DKIM	Tampering in transit. A signature ties the message to a domain	RFC 6376, Standards Track (2011)	Yes
DMARC	Spoofing of the visible From: domain. It also sets the policy and requests reports	RFC 9989, Standards Track (May 2026)	Yes
STARTTLS	Plaintext transfer between mail servers	RFC 3207, Standards Track (2002)	Yes
DANE for SMTP	Downgrade and man-in-the-middle attacks on STARTTLS. Requires DNSSEC	RFC 7672, Standards Track (2015)	Yes
MTA-STS	The same threat as DANE, without needing DNSSEC	RFC 8461, Standards Track (2018)	No, but Germany’s BSI accepts it

SPF and DKIM alone don’t stop spoofing. SPF checks the envelope sender (the Return-Path), not the From: address your staff actually see. An attacker can pass SPF for a domain they own while displaying yours. DMARC closes that gap through alignment: the visible From: domain must match a domain that passed SPF or DKIM. RFC 9989 also changed the policy record. The pct sampling tag is gone, a t test-mode flag replaces it, and receivers now locate policies by walking the DNS tree rather than using the Public Suffix List. A plan written in 2025 may reference syntax that has now been retired.

A Phased Plan That Meets Point 6.7.2(k)

In plain terms: start by monitoring and inventorying, then move to enforcement. Each phase has an owner and a date. Those dates are the “measures to accelerate” the clause asks for.

Phase	Action	Effort	Owner
1. Inventory	List every domain, including parked and non-sending ones, and every service that sends as you (CRM, payroll, ticketing)	Medium	IT / CISO
2. Lock non-sending domains	SPF v=spf1 -all plus DMARC p=reject on every domain that never sends mail	Low	IT
3. Monitor	Publish DMARC p=none with an aggregate-report (rua) address, and fix SPF/DKIM for each legitimate sender	Medium	IT, suppliers
4. Enforce	Move to p=quarantine, then p=reject, once reports show only aligned legitimate mail	Medium	CISO approves
5. Transport	Enforce TLS; deploy MTA-STS with TLS reporting, or DANE if your DNS is DNSSEC-signed	High	IT / DNS provider
6. Review	Re-run the plan at planned intervals and after incidents (point 6.7.3)	Low	Compliance

SPF allows a maximum of 10 DNS-querying terms; beyond that, RFC 7208 returns a permanent error, so piling up include: statements for every SaaS tool silently breaks SPF. As a general guideline, most practitioners keep a domain at p=none for at least one full business cycle (often 4–8 weeks) before enforcing, so that quarterly or monthly senders show up in the reports. Phase 3 is also a supplier exercise. Every marketing or billing platform that sends as your domain has to be configured correctly, which ties this work to your supply chain security controls under Article 21(2)(d).

Evidence a Supervisor Can Ask For

In plain terms: ENISA’s evidence list for point 6.7 doesn’t include an email plan, so you have to design your own audit trail.

ENISA’s “examples of evidence” for 6.7 include network diagrams, firewall rule sets and a transition plan for network-layer protocols. Nothing in that list covers point (k). Supervisors still have the power to ask. Article 32(2)(g) allows requests for “evidence of implementation of cybersecurity policies” from essential entities, and Article 33(2)(f) gives the same power for important entities, exercised ex post. A defensible file contains:

• The approved implementation plan: scope (all domains), target standards, milestones and owners
• A domain inventory showing the SPF, DKIM and DMARC status of each domain
• DMARC aggregate-report summaries showing the move from p=none to enforcement
• A list of authorised third-party senders, with the date each was configured
• TLS or MTA-STS reporting, plus email-filter logs (ENISA names these under malware protection)
• Review records under point 6.7.3, including any revision after an email-borne incident
• For entities outside the eleven provider types: the risk-register entry recording what you chose to deploy, and why

Article 20(1) makes the management body approve the Article 21 measures and oversee their implementation. Get the plan signed at board level, not just by IT.

Fines, Incidents and the Business Case

In plain terms: a missing plan is an Article 21 infringement. A spoofing-led fraud may or may not also have to be reported. And the threat data alone justifies the cost.

Entity type	Maximum fine for infringing Article 21 (at least)	Legal basis	Imposed by
Essential	€10,000,000 or 2% of worldwide annual turnover, whichever is higher	Art 34(4)	National competent authority
Important	€7,000,000 or 1.4% of worldwide annual turnover, whichever is higher	Art 34(5)	National competent authority

The scope of the two obligations differs, and that matters here. Article 21(1) covers systems used “for their operations or for the provision of their services”. Article 23 reporting covers only incidents with significant impact on service provision. Corporate email is always operational, so a spoofing attack is always an Article 21 matter. Whether it also has to be reported depends on the impact, which our BEC significant incident test works through step by step.

The risk is measurable. The ENISA Threat Landscape 2025 found phishing behind 60% of observed intrusions, across 4,875 incidents from July 2024 to June 2025. The FBI’s 2025 IC3 report recorded $3.05 billion in business email compromise losses from 24,768 complaints. Those are US figures, but the attack technique is the same everywhere. DMARC doesn’t stop lookalike domains or compromised supplier mailboxes. That is why Recital 20’s “safe email use” points to staff training as well. Our guide to cybersecurity training requirements covers that layer, and MFA on email accounts, ideally phishing-resistant passkeys, covers account takeover.

National Rules and De Facto Mandates

In plain terms: some countries were ahead of NIS2, and mailbox providers have turned DMARC into a delivery requirement anyway.

• Netherlands: DMARC has been on the government’s “comply or explain” list since 18 May 2015. It covers all government domain names, including domains that send no mail.
• Germany: BSI technical guideline TR-03182 (February 2024) accepts only quarantine or reject policies, and states that eventually only reject will be accepted. It is voluntary. As SIDN reports, Germany has no Dutch-style comply-or-explain rule. Its companion guideline TR-03108 covers transport security, using STARTTLS, DANE, MTA-STS and TLS reporting.
• Google: since 1 February 2024, bulk senders (about 5,000+ messages a day to Gmail) must have SPF, DKIM and DMARC, with p=none as the minimum.
• EU level: Recital 8 of the implementing regulation called for a multistakeholder forum on these standards. The Commission’s Multi-Stakeholder Forum on Internet Standards Deployment runs an email work stream, and first draft guidelines were presented in June 2026. No final publication date has been set. Recital 8 says the guidance is “without prejudice” to the obligation, so waiting for it is not a defence.

Frequently Asked Questions

Is DMARC mandatory under NIS2?

Not by name. For the eleven provider types covered by Implementing Regulation 2024/2690, point 6.7.2(k) requires a plan to deploy modern email standards, and DMARC is one of the five standards ENISA lists. For other entities it is a risk-based decision under Article 21.

Is a DMARC record at p=none enough?

Not on its own. p=none only monitors. Point 6.7.2(k) asks for measures to accelerate deployment, so a plan should show a dated path to quarantine or reject, or a documented reason why a domain stays in monitoring mode.

Our email runs on Microsoft 365 or Google Workspace. Is the provider responsible?

The provider relays your mail and can sign it, but the DNS records for your domain (SPF, DKIM selectors, DMARC policy) are yours to publish and maintain. So are the plan and the evidence.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

How This Guide Was Verified

We searched the official English EUR-Lex texts of the Directive and Implementing Regulation 2024/2690 directly; that search produced the zero counts above. ENISA’s guidance was read in its full June 2025 PDF, and IETF document status was checked on the RFC Editor’s site on 7 October 2026. Where a step rests on practitioner judgement rather than binding text, the article says so.

Sources

1. Directive (EU) 2022/2555 (NIS2), Articles 20(1), 21, 25(1), 32(2), 33(2), 34(4)–(5) and Recital 89 — EUR-Lex
2. Commission Implementing Regulation (EU) 2024/2690, Articles 1–2, Recitals 8, 19, 20 and Annex points 6.7.2–6.7.3 — EUR-Lex
3. ENISA, NIS2 Technical Implementation Guidance, version 1.0, June 2025 (points 6.7, 6.9, 11.7)
4. European Commission (DG COMM and JRC), Internet standards: Email
5. European Commission, Multi-Stakeholder Forum on Internet Standards Deployment
6. IETF, RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
7. IETF, RFC 7489: DMARC (Informational, 2015; now obsolete)
8. IETF Standards Track RFCs: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 3207 (STARTTLS), RFC 7672 (DANE for SMTP), RFC 8461 (MTA-STS)
9. BSI, TR-03182 Email Authentication and TR-03108 Secure Email Transport
10. SIDN, “Germany’s BSI publishes detailed technical guidelines on e-mail authentication”, 6 May 2024
11. Forum Standaardisatie (NL), DMARC — comply-or-explain list
12. Google, Email sender guidelines
13. ENISA, Threat Landscape 2025 (press release)
14. FBI Internet Crime Complaint Center, 2025 Internet Crime Report