NIS2 and email authentication: what the directive actually expects

DMARC: the control NIS2 makes hard to dodge

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the standard that tells receiving servers what to do with a message that claims to come from a domain but fails SPF and DKIM authentication. At an enforcement policy — p=quarantine or, better, p=reject — it makes spoofed messages get rejected or quarantined before they ever reach an inbox.

Why does this particular control tick so many NIS2 boxes?

• It is technical and standardised: a public DNS entry, verifiable by anyone, with no proprietary software.
• It is auditable: the posture is public and readable in seconds. An auditor can observe it without even making contact.
• It produces evidence: aggregate DMARC reports (RUA) continuously document who sends in the company's name, feeding directly into incident detection and supply-chain monitoring.
• It is inexpensive: no licence, a rollout measured in weeks, and a manageable risk under a gradual ramp-up.

In short, it is exactly the kind of "appropriate and proportionate" measure the directive calls for: an unbeatable benefit-to-cost ratio against a proven risk.

"But NIS2 doesn't say DMARC"

True, and deliberately so. The European legislator writes outcome obligations, not technical recipes that would be obsolete before transposition. It expects "appropriate measures" and lets the state of the art define which ones. For email domain anti-spoofing, the state of the art is SPF + DKIM + DMARC: there is no recognised alternative. When a sector framework, a cyber-insurance questionnaire or an auditor looks for concrete evidence that this risk is managed, it is the DMARC policy they check.

The market signal already points the same way, regulation aside: the Gmail and Yahoo sender requirements have made DMARC a prerequisite for any bulk sending since 2024. Between the regulatory push and the pressure from major mailbox providers, the window in which a domain could sit at p=none without consequence is closing.

What to do, concretely

Here is the sequence an in-scope CISO should start without waiting for final transposition at home:

1. An inventory of every domain. Not just the main one: secondary brands, campaign domains, legacy domains inherited from an acquisition, and those that send no mail at all. Each is a potential spoofing surface.
2. DMARC published at p=none first. The initial goal is to observe, not block. The aggregate reports reveal the full real sending estate — almost always broader than the team assumed.
3. Alignment of every legitimate source. SPF and DKIM get fixed for each platform (ERP, CRM, marketing tool, billing provider) until it passes aligned, with DKIM alignment as the target, since it survives forwarding.
4. A deliberate policy ramp-up. First quarantine, then reject, with the reports watched at each step. The detailed procedure is in getting to p=reject without breaking legitimate email.
5. A lock on non-existent subdomains. With DMARCbis, the np tag closes subdomains that send nothing but remain spoofable — a near-zero-risk hardening.
6. Retention of the evidence. Archiving the reports and the posture history builds the audit trail that proves active risk management, not a box ticked once.

The real stake: from none to reject

The most common trap, under NIS2 as elsewhere, is to believe that a published DMARC record is enough. A domain at p=none offers no protection: it merely observes spoofing without blocking it. In front of an auditor, "we have DMARC" says nothing; "our consumer-facing domain has been at p=reject for six months, with continuous monitoring" is a defensible claim. That is the difference between paper compliance and real posture — and it is also the underlying story in finance, where enforced DMARC protects the most-spoofed brands, a line of reasoning that transfers directly to public bodies caught by NIS2.

DORA compliance for the financial sector follows exactly the same operational-resilience logic: an organisation caught by both regimes can treat them as a single authentication project, described in detail on the finance side in DORA's email requirements. And to turn this obligation into reusable audit evidence, DMARC slots naturally into an ISO 27001 management system.

The clock is ticking

Transposition of NIS2 is under way across member states, at different speeds, but the direction is identical everywhere. The trap is that email-authentication compliance cannot be improvised the night before an inspection. Between publishing DMARC at p=none, collecting several weeks of reports to map the real sending estate, aligning each source and carefully ramping to p=reject, the work typically spans one to three months — more for a large multi-domain group. Starting early buys the time to do it without breaking legitimate mail; starting late forces a choice between brutal enforcement, risky for deliverability, and a compliance delay that is now sanctionable.

There is also a governance reason. Because NIS2 puts personal liability on directors, the question "is our domain spoofable?" is no longer a technical-team matter: it is a question the board must be able to answer, with evidence. A domain at p=reject with a monitoring history is an answer presented calmly to a board or an authority alike; a p=none forgotten for two years is a risk nobody wants to own by name.

One project, several regimes

A closing point worth making to anyone weighing the effort: this work is not spent once and forgotten under a single heading. The same enforced posture, archived reports and documented ramp-up satisfy NIS2's risk-management duty, feed the security limb of GDPR, and slot into an ISO 27001 management system as reusable evidence. The exercise is not three separate files; it is one solid control, presented under three regulatory angles. For a stretched security team, that reuse is often the deciding argument — the cheapest compliance is the control implemented once, then pointed at from wherever it is needed.

Checking exposure right now

The good news: assessing where a domain stands takes seconds and costs nothing. Our free DMARC analyzer returns an instant verdict on its current policy, and the DMARC Observatory then puts each sector side by side at a glance — public administration is among the tracked sectors, and the recurring finding is that a notable share of entities remain in observation-only mode.

Bringing a multi-domain estate to p=reject while keeping a clean audit trail is exactly what Thomas, the virtual CISO, is built to carry: he names every sending source, generates the DNS to publish, assesses per-domain readiness on rolling data, and signals when each can be enforced safely. Analyze a domain for free · explore the Observatory · get started with Thomas.