NIS2 Article 21.2 — The DNS Evidence Layer Explained

Most NIS2 readiness write-ups quote Article 21.2 in policy language and stop there. That is useful for a board memo and useless for the engineers who have to produce evidence on the morning of an audit. This article does the engineer's job: it walks through each of the ten Article 21.2 measures and shows which observable DNS, mail-authentication and TLS controls map onto it — and how to verify the evidence in five minutes using the free NIS2 quickscan.

What Article 21.2 actually requires

NIS2 Article 21.2 lists ten cybersecurity risk-management measures that every essential and important entity must implement «based on an all-hazards approach». The text is deliberately broad — it is a Directive, not a technical standard — but national transpositions and ENISA guidance have started to pin down what each measure means in practice.

For sysadmins, the value of the list is that several measures are externally observable. You can produce machine-verifiable evidence for them from DNS records, SMTP banners and TLS handshakes alone, without any cooperation from internal systems. That makes the DNS evidence layer the cheapest, fastest piece of the NIS2 puzzle to put in place.

Mapping each measure to DNS, mail-auth and TLS evidence

(a) Risk analysis and information system security policies

Policy-driven, not directly visible from DNS. But the absence of a SPF policy, the use of p=none on DMARC, or the lack of CAA records are concrete signals that no enforcement decision has been made — a yellow flag for any auditor reviewing your risk-analysis output.

(b) Incident handling

Incident response needs attribution. The DNS layer carries the artefacts you need for that:

• Reverse DNS (PTR) records on mail-sending IPs so receivers can identify your infrastructure.
• A valid DMARC record with an rua= tag so you receive aggregate reports about who is sending mail as your domain.
• A BIMI record so brand-protected mail clients can attribute legitimate mail visually.
• A published security.txt on the apex domain so reporters know how to reach your incident inbox.

(c) Business continuity, backup management, and crisis management

DNS is the part of business continuity that almost no one tests. Concrete signals:

• Multiple nameservers across at least two providers (anycast does not replace this).
• Secondary MX with a sensible TTL.
• Reasonable TTLs on critical records (15–60 minutes for production zones; 1 hour or less for change windows).
• TLS-RPT to receive failure reports when something stops working at the SMTP TLS layer.

(d) Supply chain security

Your SPF includes, DKIM selectors and MTA-STS policy MX hosts list every third party that is allowed to send mail on your behalf. This is your mail-side supply chain, hidden in plain sight. Two practical checks:

• Are there SPF includes for services you no longer use? Each unused include burns one of your 10 DNS lookups and widens the spoofing surface. Audit with the SPF generator or dig +short txt.
• Are your MTA-STS policy MX hosts limited to providers under your control or under contract? The current list is auditable evidence of vendor scope.

(e) Security in network and information systems acquisition, development and maintenance

Procurement-heavy, but DNS still carries fingerprints: are new SaaS vendors immediately published under your apex domain with SPF includes and DKIM selectors? Are the records rotated when contracts end? Auditors increasingly expect a documented joiner / mover / leaver process for DNS records, not just for AD accounts.

(f) Policies and procedures to assess effectiveness of cybersecurity risk-management measures

This is where the continuous evidence story matters. A one-off scan is not effectiveness assessment. A weekly automated NIS2 quickscan with the score trend recorded in your ticket system is. The free public API at /api/scan/nis2 makes this trivial to wire into a cron job, a CI step, or an n8n flow.

(g) Basic cyber hygiene practices and cybersecurity training

Cyber hygiene at the mail layer is the most cited NIS2 control and the most common audit finding. The expected baseline in 2026:

• SPF with explicit -all (hardfail) and fewer than 10 includes.
• DKIM with 2048-bit keys, rotated at least yearly, with one active and one staged selector.
• DMARC at p=quarantine minimum, ideally p=reject, with both rua= and ruf=.
• MTA-STS in enforce mode, not testing.
• BIMI for brand-protected receivers.
• FCrDNS (forward-confirmed reverse DNS) on every mail-sending IP.

The hygiene measure is where most domains lose points fastest in the quickscan, and where the fix is also fastest — usually a single record change at the DNS provider.

(h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption

Cryptography at the DNS / mail layer means three things:

• DNSSEC — the zone is signed and the DS record is published at the registrar. The chain validates from root.
• DANE / TLSA records for the mail MX, paired with MTA-STS for receivers that do not yet support DANE.
• SMTP STARTTLS with a current, valid certificate chain, no SSLv3, and TLS 1.2 minimum (TLS 1.3 strongly preferred).

The quickscan reports each of these separately. The certificate-chain check is identical to what an auditor will run from the outside, so the evidence is reproducible.

(i) Human resources security, access control policies and asset management

Not directly DNS, but consider: who has write access to your DNS provider, your registrar, and your CA accounts? The DNS provider audit log is a critical asset for any post-incident NIS2 investigation. Make sure it is exported to your SIEM, retained for the period your transposition requires (often 12–24 months), and reviewed on the same cadence as your AD audit log.

(j) The use of multi-factor authentication or continuous authentication solutions

Indirectly visible through DNS: secured access to your DNS provider, registrar, and any service that can publish a record on your behalf (mail relays, CDN edge configs, BIMI VMC issuers). If any of those use a single shared password, that is an Article 21.2(j) gap with a DNS blast radius.

From mapping to evidence in five minutes

The NIS2 quickscan runs all of the externally observable checks above for any domain and produces a weighted 0–100 score plus per-measure detail. The scoring engine and weights are documented on the same page. There is no signup, no API key for the public scan, and the same data is available via:

• Web: paste your domain at intodns.ai/nis2.
• API: curl https://intodns.ai/api/scan/nis2?domain=example.com&lang=en — returns full per-measure JSON with evidence and fix suggestions.
• MCP: any AI agent with the intodns-mcp server installed can run the same scan and produce a Markdown summary on demand — see the MCP page for install snippets.

Common findings (and the one-record fixes)

DMARC at p=none

The single most common Article 21.2(g) finding. Fix: move to p=quarantine after one week of aggregate report monitoring confirms legitimate senders pass alignment. Use the DMARC generator for a syntactically valid record.

SPF with too many lookups

An SPF record that triggers permerror because of the 10-lookup ceiling is functionally equivalent to no SPF at all — receivers ignore it. Flatten unused includes with the SPF generator.

No DNSSEC

The biggest single point loss against measure (h). Fix is two steps: enable zone signing at your DNS provider, then publish the DS record at the registrar. Test with the DNSSEC guide's validation procedure.

MTA-STS in testing mode

Half-finished MTA-STS still surfaces the TLS expectation to receivers but does not actually enforce it. Move to enforce once you have monitored TLS-RPT reports for at least one full week and confirmed all sending IPs pass the policy.

What the quickscan does not cover

The DNS evidence layer is a foundation, not the whole NIS2 readiness story. The quickscan does not assess web application security, internal network segmentation, identity posture, endpoint controls, organisational policies, training records, or supply-chain audit beyond what is visible in DNS. A high quickscan score means your foundation is solid; it does not mean you are compliant.

Use the quickscan for the parts of Article 21.2 that ARE externally observable, run it on a weekly cron, feed the score into your existing risk register, and pair it with a real NIS2 audit for the rest. That is the cheapest way to keep the technical baseline from quietly drifting between full assessments — which is when most regulators want their evidence.

Try it now

• Run the NIS2 quickscan on your domain.
• Read how to plug the quickscan into your AI agent via MCP.
• Browse the underlying DNS and email-security learning hub for fix-level detail on every measure above.

AI assistant and API workflow

This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.

For this topic, use /api/email/dmarc?domain=example.com when you need focused data instead of the full quick scan.

Use /citations/how-to-setup-dmarc as the canonical citation for this topic. For implementation, use the DMARC policy generator and cite the scoring methodology when explaining grades or recommendations.