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

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.

This 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.

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.

What does NIS2 require for email security?

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.

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.

The one binding clause that mentions email is in the Implementing Regulation. Its Annex, point 6.7.2(k), requires in-scope entities to:

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).

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).

Article 21(2)(d), (g), (h): the three controls that map to email

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.

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.

The legal hooks behind the rows are concrete:

• (h) — encrypt the channel. The Implementing Regulation’s point 6.7.2(i) requires “trusted channels … isolated using logical, cryptographic or physical separation,” and point 9.2(a) names “data in transit” as something the cryptography policy must protect.
• (d) and (g) — name modern mail standards. Point 6.7.2(k) supplies the “modern e-mail communications standards” language, and Recital 19 adds that entities should “deploy email and web application filters to reduce exposure to malicious content.”

Which protocols satisfy NIS2 Article 21? DMARC, SPF, DKIM, MTA-STS, DANE, TLS-RPT

Six protocols cover the email side of NIS2: SPF, DKIM, and DMARC authenticate the sender; MTA-STS, DANE, and TLS-RPT secure and monitor the transport. None is legally named by NIS2, but together they implement the “modern e-mail communications standards” the Implementing Regulation asks for.

• SPF (RFC 7208) authorizes which IPs may send for your domain. It serves the supply-chain hook (d): a published SPF record ending in ~all or -all lets receivers reject mail from servers you never authorized. Read SPF Softfail vs Hardfail to understand the difference.
• DKIM (RFC 6376) attaches a cryptographic signature to each message. It serves both (d) and (h): the signature proves the message wasn’t altered and that it came from a key your domain controls.
• DMARC (RFC 9989) ties SPF and DKIM together with alignment and an enforcement policy. It serves (d) and (g). Enforcement — p=quarantine or p=reject — is the part that matters, and only 12.8% of domains reach it.
• MTA-STS (RFC 8461) publishes a TLS policy over HTTPS so senders refuse to fall back to plaintext. It serves the (h) cryptography-in-transit hook.
• DANE (RFC 6698/7672) pins TLS certificates in DNS via DNSSEC. It is the strongest transport control under (h) — and the rarest, at 0.0% adoption.
• TLS-RPT (RFC 8460) collects transport-failure reports. It is the visibility layer for (h): without it, a broken MTA-STS or DANE policy fails silently. No vendor names TLS-RPT in a NIS2 context.

Who must comply? Essential vs important entities

NIS2 splits in-scope organisations into essential and important entities — but both must implement the same ten Article 21(2) measures. Only the supervision regime and the maximum fines differ.

Two things put you in scope: your sector and your size. Annex I (“sectors of high criticality”) and Annex II (“other critical sectors”) define the sectors; the size floor comes from Commission Recommendation 2003/361/EC.

Within a covered sector, size sets the tier:

• Essential: an Annex I entity above the medium-enterprise ceiling — 250+ staff, or more than EUR 50 million turnover.
• Important: a covered entity at 50+ staff OR more than EUR 10 million turnover or balance sheet.

Some entities — qualified trust-service providers, TLD registries, DNS providers — are essential regardless of size.

ENISA’s published estimate puts roughly 160,000 entities in scope across the EU; Germany’s BSI has cited about 29,500 affected German entities. Both are third-party authority estimates, not DMARCguard figures. The two tiers differ only in supervision and penalty ceilings.

Those figures are the regulation’s ceilings, stated as a duty-of-care benchmark rather than a threat. Through the latest available sources, no national authority has published a named NIS2 fine.

How EU Member States already name email protocols

No Member State names email-auth protocols inside its NIS2 transposition law itself — but at least four (the Netherlands, Denmark, Czechia, and Poland) already impose binding requirements that name SPF, DKIM, and DMARC through public-sector baselines or anti-abuse statutes, and several more name them in national guidance.

The binding mandates each stem from a specific national instrument, not from NIS2:

Germany is the most relevant case for transport security: BSI Technical Guideline TR-03182 promotes SPF, DKIM, and DMARC, while the companion TR-03108 covers (START)TLS, DANE, MTA-STS, and TLS-RPT. France (ANSSI-PA-066), Spain (CCN-CERT/CCN-STIC), and Estonia (the E-ITS catalogue) name the protocols in guidance too. For reference, the UK — now outside the EU — mandated DMARC p=reject for service.gov.uk from October 2016 via the Government Digital Service.

The honest framing matters: these requirements predate or run parallel to NIS2. None appears inside a NIS2 transposition statute. If you operate in Germany, the BSI NIS2 readiness check maps your domain against the BSI’s own email-security expectations.

Does NIS2 require DMARC? Myths vs the legal text

No — NIS2 does not mandate DMARC. The Directive is technology-neutral and names no protocol; DMARC is a recommended way to meet Article 21(2)‘s “appropriate technical measures,” not a named requirement. The only email-adjacent control with explicit text is cryptography and encryption under Article 21(2)(h).

A common claim asserts that “DMARC is mandatory under NIS2.” It isn’t — that reading conflicts with the Directive text and with the consensus of legal and technical sources, which treat DMARC as an implied control rather than a named one. The distinction is not pedantry: it changes what you tell an auditor and how you justify your deployment plan.

Independent practitioners frame it the same way. As cybersecurity consultant Antonio Ieranò put it, “while NIS2 doesn’t explicitly list ‘Thou shalt implement DMARC’ (it’s technology-neutral in text), it does set out broad requirements that imply you need to secure all threat vectors — and email is definitely one of the biggest threat vectors.” Counsel reads it similarly: both Skadden, Arps and Bird & Bird describe NIS2 as risk-based and technology-neutral, with email authentication a recommended implementation of “appropriate technical measures” rather than a mandated control. Deploy DMARC because it is the defensible way to satisfy the obligation — not because a clause names it.

Verify your email-auth controls with these DNS checks

You can confirm every NIS2-relevant email control from the command line. Each dig query below shows whether the record exists and what policy it declares — run them against your own domain before an auditor does. Or run them all in your browser.

# SPF (RFC 7208) — authorizes sending IPs. Look for v=spf1 ... -all (hard fail).
dig +short TXT example.com

# DKIM (RFC 6376) — public key for a selector. Swap "selector1" for your selector.
dig +short TXT selector1._domainkey.example.com

# DMARC (RFC 7489) — the policy that ties it together.
# Enforcement means p=quarantine or p=reject. p=none is monitoring only.
dig +short TXT _dmarc.example.com

# MTA-STS (RFC 8461) — TLS policy over HTTPS, announced via a TXT record.
dig +short TXT _mta-sts.example.com
curl -s https://mta-sts.example.com/.well-known/mta-sts.txt

# DANE (RFC 6698 / 7672) — DNSSEC-pinned TLS. The answer MUST carry an RRSIG;
# RFC 7672 §2 says conforming senders ignore an unsigned TLSA record.
# Replace mail.example.com with each MX host.
dig +dnssec _25._tcp.mail.example.com TLSA

# TLS-RPT (RFC 8460) — transport-failure reporting. Look for v=TLSRPTv1; rua=...
dig +short TXT _smtp._tls.example.com

Two checks deserve a closer look. For DMARC, presence isn’t enough: a record with p=none is monitoring only, so confirm the policy reads p=quarantine or p=reject before you call it enforced. For DANE, the TLSA answer must carry an RRSIG line — RFC 7672 §2 requires conforming senders to ignore an unsigned TLSA record, so without DNSSEC the record provides no security benefit.

We built our scanner against the Tranco 5.5-million-domain list; that is how we know enforcement sits at 12.8% rather than the much higher “DMARC present” figure. If you’d rather skip the command line, the DMARC checker, MTA-STS checker, and DANE checker run the same validation in your browser and explain each result.

NIS2 email-auth readiness in 6 steps

Six steps take a domain from unauthenticated to NIS2-ready: confirm scope, deploy SPF and DKIM, move DMARC to enforcement, add MTA-STS, add TLS-RPT, then document the plan. Work backward from your national audit-readiness milestones — for example, Germany’s BSI registration window of roughly 6 March 2026 — rather than from any fixed pan-EU date, because none exists. This section doubles as your NIS2 compliance checklist.

A pragmatic 2026 sequence: ship SPF, DKIM, and DMARC enforcement first; add MTA-STS, DANE, and TLS-RPT next; and keep the written plan current, because auditors will ask to see the plan as much as the records.

NIS2, DORA, and HIPAA — how the mandates overlap

NIS2 is one of several regimes pushing email authentication as a baseline. DORA (the EU financial sector’s Digital Operational Resilience Act) and HIPAA (US healthcare) ask for the same email controls under different legal language — if you deploy SPF, DKIM, DMARC enforcement, and TLS-in-transit for NIS2, you have already covered most of what the others expect.

DORA’s ICT risk-management articles (Articles 9–11) require protection, detection, and the integrity of data in transit, supervised in markets like Germany by BaFin; the DORA compliance check maps your domain against them. HIPAA’s Security Rule (45 CFR §164.312) calls for transmission security and integrity controls for electronic protected health information, and the HIPAA email readiness check does the same for that regime. Neither names a protocol either — the same email-auth stack answers all three, documented once.

Frequently asked questions

Does NIS2 require DMARC?

No. The NIS2 Directive (EU) 2022/2555 is technology-neutral and names no email protocol. DMARC (RFC 9989) is a recommended way to meet Article 21(2)‘s “appropriate technical measures,” not a named requirement. The only email-adjacent control with explicit text is cryptography under Article 21(2)(h).

What does NIS2 say about email security?

NIS2 itself says nothing protocol-specific. The binding email obligation lives in Commission Implementing Regulation (EU) 2024/2690, Annex point 6.7.2(k): in-scope digital entities must “adopt an implementation plan for the deployment of internationally agreed and interoperable modern e-mail communications standards.” It names no protocol; SPF, DKIM, DMARC, MTA-STS, and DANE are the standards that satisfy it.

When is the NIS2 compliance deadline?

Member States were required to transpose NIS2 into national law by 17 October 2024 (Article 41), and measures apply from 18 October 2024. Transposition ran late: Germany’s law took effect 6 December 2025; France, Ireland, the Netherlands, and Spain were still finalising theirs into mid-2026. There is no separate pan-EU deadline — check your country’s status.

Do important entities face lighter requirements than essential entities?

No. Both essential and important entities must implement the same ten Article 21(2) measures. Only the supervision regime (proactive/ex-ante for essential, reactive/ex-post for important) and the maximum fines differ — EUR 10M/2% versus EUR 7M/1.4% of worldwide turnover.

Does NIS2 apply to small businesses?

It can. Scope uses OR-logic, not AND: an entity in a covered sector is in scope at 50+ employees OR more than EUR 10 million in annual turnover or balance sheet. A 30-employee firm with EUR 15 million turnover qualifies. Sub-threshold suppliers can still inherit requirements contractually under Article 21(2)(d).

Is DANE mandatory under NIS2?

No EU instrument names DANE (RFC 6698/7672). It maps to the Article 21(2)(h) cryptography obligation as our interpretation. Some Member States expect it — the Netherlands lists DANE on its comply-or-explain standards, and Germany’s BSI covers it in TR-03108 — but NIS2 itself requires only “modern e-mail communications standards.”

What email controls should I deploy first for NIS2?

Start with sender authentication: publish SPF and DKIM, then move DMARC to enforcement (p=quarantine or p=reject). Add MTA-STS and TLS-RPT for transport security, and DANE if your zone is DNSSEC-signed. Document the deployment plan — Implementing Regulation point 6.7.2(k) requires the plan, not just the records.

Where to go from here

NIS2 compliance for email comes down to five facts. NIS2 names no protocol. Article 21(2)(d), (g), and (h) map to SPF, DKIM, and DMARC enforcement plus MTA-STS, DANE, and TLS-RPT. The same ten measures apply to both essential and important entities. Enforcement — not mere presence — is the gap, with 12.8% DMARC enforcement, 0.3% MTA-STS, and 0.0% DANE in our February 2026 scan. And point 6.7.2(k) wants the documented deployment plan, not just the records.