---
title: "NIS2 Email Security: Article 21 → DMARC, MTA-STS, DANE"
description: "NIS2 compliance: map Article 21(2) to email auth — DMARC, SPF, MTA-STS, DANE, TLS-RPT. The control map, copy-paste DNS checks, and a 2026 readiness plan."
publishedAt: 2026-06-01
tags: ["nis2", "compliance", "dmarc", "mta-sts", "dane", "tls-rpt", "email-authentication", "article-21"]
faq:
- question: "Does NIS2 require DMARC?"
answer: "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)."
- question: "What does NIS2 say about email security?"
answer: "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."
- question: "When is the NIS2 compliance deadline?"
answer: "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."
- question: "Do important entities face lighter requirements than essential entities?"
answer: "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."
- question: "Does NIS2 apply to small businesses?"
answer: "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)."
- question: "Is DANE mandatory under NIS2?"
answer: "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.'"
- question: "What email controls should I deploy first for NIS2?"
answer: "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."
---
# 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.
{/* TODO link /blog/dmarc-enforcement-gap/ on "12.8% enforce" — publishes 2026-06-11 */}
## 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](https://eur-lex.europa.eu/eli/dir/2022/2555/oj)).
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](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng)).
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](https://www.enisa.europa.eu/publications/nis2-technical-implementation-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.
| Article 21(2) sub-paragraph (verbatim hook) | What it requires (plain) | Email-auth protocols that satisfy it | First-party adoption (Feb 2026) |
| ------------------------------------------------------------------------------------------------------ | --------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------- |
| **(h)** "policies and procedures regarding the use of cryptography and, where appropriate, encryption" | Encrypt mail in transit; resist STARTTLS downgrade | [MTA-STS](/learn/mta-sts/) (RFC 8461), [DANE](/learn/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 senders | DMARC 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 hygiene | DMARC enforcement (p=quarantine / p=reject) | 12.8% enforce; 40.8% have no auth |
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."
Neither Article 21(2), the Implementing Regulation Annex, nor ENISA's guidance
names SPF, DKIM, DMARC, MTA-STS, DANE, or TLS-RPT. Mapping these protocols to
the NIS2 measures is a reasoned reading of the text, not a citation of a named
requirement. We state this plainly because every honest compliance decision
starts with knowing where the law ends and interpretation begins.
## 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](/learn/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](/blog/spf-softfail-vs-hardfail/) to understand the
difference.
- **[DKIM](/learn/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](/learn/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](/blog/what-is-dane/).
- **[TLS-RPT](/learn/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.
{/* TODO link /blog/mta-sts-vs-dane/ on the MTA-STS vs DANE choice — publishes 2026-06-25 */}
## 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.
A common error treats the size test as "50 employees AND EUR 10M." It is OR. A
30-employee firm in a covered sector with EUR 15 million in turnover is in
scope. Sub-threshold suppliers aren't directly regulated, but in-scope
customers must assess them under Article 21(2)(d) — so small vendors inherit
the requirements contractually.
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.
| Criterion | Essential entity | Important entity |
| -------------------------- | ------------------------------------------------- | ------------------------------------------------- |
| Typical size floor | 250+ staff or > EUR 50M turnover (Annex I) | 50+ staff or > EUR 10M turnover / balance sheet |
| Article 21(2) measures | Same ten measures | Same ten measures |
| Supervision | Proactive / ex-ante (audits without a trigger) | Reactive / ex-post (action on evidence) |
| Maximum administrative fine | ≥ EUR 10M or 2% of worldwide turnover, whichever higher | ≥ EUR 7M or 1.4% of worldwide turnover, whichever higher |
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:
| State | Protocols named | Force | Primary instrument |
| --------------- | ------------------------------------------ | -------------------------------------------- | --------------------------------- |
| Netherlands | SPF, DKIM, DMARC, STARTTLS, DANE | Mandatory (comply-or-explain) | Forum Standaardisatie |
| Denmark | DMARC (p=reject), SPF (~all or -all), DKIM | Mandatory (state minimum requirements, 2024) | CFCS |
| Czechia | SPF, DKIM, DMARC | Mandatory (binding protective measure, 2021) | NÚKIB |
| Poland | SPF, DKIM, DMARC | Statutory; fines up to 3% of revenue | Act of 28 July 2023 |
| Germany | SPF, DKIM, DMARC (+DANE, MTA-STS, TLS-RPT) | Technical guideline / certification basis | BSI TR-03182 / TR-03108 |
| Italy | SPF, DKIM, DMARC (+MTA-STS, TLS-RPT, DANE) | Guidance, tied to NIS2 base measures | ACN guidelines |
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](/tools/bsi-nis2/) 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](https://thepuchiherald.com/microsofts-new-email-rules-spf-dkim-dmarc-or-bust-a-cisos-sarcastic-guide/),
"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](/tools/domain-health-check/).
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](https://datatracker.ietf.org/doc/html/rfc7672#section-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](/tools/dmarc-checker/),
[MTA-STS checker](/tools/mta-sts-checker/), and
[DANE checker](/tools/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.
1. **Confirm whether you're in scope.** Apply the sector-plus-size test (OR-logic),
and decide whether you are an essential or important entity. The
[NIS2 readiness check](/tools/nis2-readiness/) walks the criteria for you.
2. **Authenticate the sender.** Publish SPF (`~all` or `-all`) and DKIM on every sending
domain. This covers the supply-chain (d) and cyber-hygiene (g) hooks.
3. **Move DMARC to enforcement.** Progress `p=none` → `p=quarantine` → `p=reject`.
Enforcement is the 12.8% gap — presence alone doesn't satisfy (g).
Use [p=none Escape Plan](/tools/pnone-escape-plan/) to get a plan for your domain.
4. **Add transport security.** Publish an MTA-STS policy, and DANE if your zone is
DNSSEC-signed, for the Article 21(2)(h) encryption-in-transit hook.
5. **Add TLS-RPT.** Publish a `_smtp._tls` record so transport failures generate
JSON reports instead of failing silently.
6. **Document the implementation plan.** Point 6.7.2(k) requires a written,
accelerating deployment plan, not just deployed records — and assess your
suppliers under 21(2)(d). The
[NIS2 supplier questionnaire](/tools/nis2-supplier-questionnaire/) gives you a
reusable assessment.
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](/tools/dora-compliance/) 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](/tools/hipaa-email-readiness/)
does the same for that regime. Neither names a protocol either — the same
email-auth stack answers all three, documented once.
{/* TODO link /blog/dora-email-authentication/ — publishes 2026-06-29 */}
{/* TODO link /blog/hipaa-email-authentication/ — publishes 2026-06-18 */}
## 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.