Introduction
The EU's NIS2 directive came into force across member states with national transposition deadlines through 2024 and into 2025. It significantly broadened the scope of organisations subject to cybersecurity hygiene obligations, raised the technical-control baseline expected of in-scope entities, and made executive-level accountability explicit in a way the original NIS directive didn't. For MSPs who serve EU clients, NIS2 changed both the conversation and the contractual reality.
DMARC isn't named by name in the NIS2 directive itself, but the technical-control expectations that NIS2 codifies make email-authentication discipline functionally mandatory for in-scope entities. This article is the regulatory-landscape companion to the DMARC for MSPs pillar and a working orientation for MSPs who suddenly have NIS2-impacted clients asking what their DMARC obligations are.
This article is written for orientation, not legal advice. The actual obligations on any specific entity depend on its national-law transposition, its sectoral classification, and the specifics of its operating model. Treat this as a starting point for the conversation with the client's compliance counsel, not a substitute for it.
Why this topic matters
NIS2 expanded the in-scope universe substantially — many mid-market organisations that were comfortably outside the original NIS scope are now squarely in. The expansion brought with it expectations around supply-chain security, incident reporting, technical-control baselines, and executive accountability that mid-market organisations weren't previously held to. For their MSPs, this means the conversation about email authentication moved from "nice to have" to "demonstrably required" almost overnight.
The MSPs who responded fastest to this shift won meaningful new managed-service revenue. The ones who didn't watched competitors take it.
What NIS2 actually requires (at the level a DMARC practice cares about)
The directive itself is broad and abstract. The relevant articles for an email-authentication practice are the ones covering technical controls, incident reporting, and supply-chain risk management. Read with that filter, the practical expectations land at:
A baseline of technical and organisational measures appropriate to the risk. The directive lists categories (risk analysis, incident handling, business continuity, supply chain, secure development, vulnerability management, access control, cryptography). Email authentication doesn't appear as a named category — but it's a sub-component of several of them. Phishing prevention is part of incident-handling discipline; domain-impersonation defence is part of cryptography (DKIM specifically); supply-chain risk includes the senders authorized to mail on the entity's behalf.
Incident reporting timelines. Significant incidents trigger short reporting clocks — initial notification within 24 hours, intermediate update within 72 hours, final report within a month. A successful brand-impersonation phishing campaign that hits a covered entity is a candidate for the reporting clock; aggregate DMARC reporting is one of the practical ways to detect such campaigns early.
Supply-chain security obligations. Covered entities are explicitly required to consider the cybersecurity practices of their direct suppliers. For an MSP serving a covered entity, this means the MSP itself is now in the client's supply-chain risk assessment — and the MSP's own posture (including its own DMARC) becomes part of the client's compliance story.
Executive accountability. The directive makes management bodies explicitly responsible for cybersecurity risk-management compliance. A CISO can no longer absorb all the accountability silently; the management body must understand the risks and approve the controls. "We have DMARC at p=reject" is the kind of concrete control statement executives can understand and approve.
The exact phrasing of these obligations varies by national transposition. The shape, however, is consistent across member states.
Who's in scope
NIS2's scope is the most significant shift from the original NIS. The categories that matter for an MSP's client conversations:
Essential entities. Large organisations in critical sectors — energy, transport, banking, financial market infrastructure, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space. The strictest obligations; mandatory supervision; significant administrative penalties for non-compliance.
Important entities. Large and medium-sized organisations in important sectors — postal and courier, waste management, manufacturing of chemicals, food, manufacturing of medical devices, manufacturing of computers, electrical equipment, machinery, motor vehicles, transport equipment, manufacturing not otherwise classified, digital providers (online marketplaces, search engines, social networks), research. Slightly lower threshold for supervision; obligations are similar in shape.
Microenterprises are generally out of scope, but exceptions exist for specific high-criticality activities (e.g., trust service providers, DNS service providers, domain name registries) — those are in scope regardless of size.
The companion article on NIS2 essential vs important entities walks the classification in more depth from a DMARC-practice perspective.
Why DMARC has become the default email-authentication expectation under NIS2
NIS2 doesn't say "you must have DMARC" anywhere. It says you must have appropriate technical controls; appropriate is defined in part by the state of the art. The state of the art for preventing domain impersonation is DMARC at p=quarantine or p=reject with active monitoring. A covered entity that publishes p=none and ignores aggregate reports is hard to defend as having appropriate controls when an incident happens.
The pattern that's emerged across NIS2-impacted engagements:
Auditors ask about DMARC posture as a standard line item. Even auditors who don't know DMARC deeply have learned to ask whether p=reject is in place, what the DMARC pass rate is, and whether there's monitoring discipline behind it. Covered entities answer these questions for every audit cycle.
Insurers ask about DMARC as a precondition for cyber-insurance renewal. Cyber-insurance underwriters tightened their email-authentication questions through 2024-2025. Covered entities (and their suppliers) increasingly find that DMARC posture is a renewal-blocker if it's not at p=reject with active monitoring.
Boards ask about DMARC as part of executive briefings. Once the board is briefed on NIS2 accountability, the natural question is "what concrete controls do we have?" DMARC at p=reject is a concrete, briefable control that executives can understand.
The MSPs winning NIS2-driven managed-service revenue are the ones who can answer all three questions in writing for any client domain, on demand. The ones losing it are the ones whose answer is "we'd need to check."
What changed in the MSP conversation
Pre-NIS2, a typical MSP DMARC conversation went something like: "your client should consider DMARC, we can help, here's the value." Post-NIS2, the conversation went: "your client has DMARC obligations under NIS2 (or under their NIS2-covered customers' supply-chain requirements), the auditor is asking next quarter, we can help, here's the timeline."
The shift in tone matters. The DMARC engagement is no longer optional discretionary spend — it's compliance spend with a deadline. That has three commercial implications:
Procurement happens faster. Compliance projects don't go through the "is this worth doing" filter the way discretionary projects do. The buying conversation compresses.
Procurement happens at a different budget line. Compliance budgets are often larger and more available than IT-improvement budgets. The price point an MSP can quote without flinching goes up.
Procurement happens at a different decision level. Compliance projects are signed off by the executive committee, not just the IT manager. The deals are larger, slower to close once they're at that level, but stickier once signed.
For MSPs that didn't reorient their pitch around the regulatory tailwind, none of this revenue showed up. For MSPs that did, the post-NIS2 year was the best DMARC-practice year on record.
The supply-chain dimension
NIS2's supply-chain provisions are often the under-appreciated part of the directive for MSPs. The provisions mean covered entities have to consider the cybersecurity practices of their direct suppliers — which includes their MSPs.
In practical terms, this means:
Your MSP-side DMARC posture is now a client-facing artefact. Clients want to know that their MSP isn't itself a phishing vector. "We're at p=reject on every domain we own" becomes a slide in the sales deck for engagements with NIS2-covered prospects.
Sub-contractors and partners get scrutinised too. If you white-label a DMARC platform from another provider, that provider's posture flows through to your client. Document the chain; be ready to answer "what's your platform vendor's NIS2 posture" because the question will come up.
Out-of-scope organisations are being pulled into scope through their customers. A mid-market manufacturing client who didn't think NIS2 applied to them often discovers their largest customer is in scope, and that customer is now asking the manufacturer to demonstrate appropriate controls — including DMARC. The compliance gradient propagates downstream.
The MSP that anticipates this — by documenting their own posture, their platform vendor's posture, and the per-client DMARC-control attestation — sells through the supply-chain conversation rather than getting stuck in it.
Where DMARC discipline shows up in the NIS2 narrative
A compact pattern for documenting DMARC as a NIS2-relevant control:
Risk reduction story. DMARC at p=reject prevents direct-impersonation phishing. Direct-impersonation phishing is one of the highest-volume initial-access vectors for the kind of breach that triggers the NIS2 incident-reporting clock. Reducing the volume of successful impersonation attempts reduces the realistic incident-reporting frequency.
Supply-chain-attestation story. DMARC posture across the supplier's owned domains is part of the supplier's hygiene posture. Documenting p=reject across every owned domain is a one-line attestation that other technical-control questions have to fight for.
Audit-evidence story. Aggregate DMARC reports are documented evidence of authentication discipline over time. The historical record is auditable — "we've been at p=reject continuously since Q2 2024 with the following pass rate distribution" is an answer auditors recognise as substantive.
Detection-capability story. The aggregate-report flow detects spoofing attempts even when they fail. Early warning of an active spoofing campaign feeds the incident-handling discipline NIS2 expects, which is part of why the report-monitoring discipline matters — not just publishing the record.
Each of these is a thread the MSP can tell concretely about a specific client. The compounding effect over time is that the DMARC engagement becomes a structural part of the client's compliance posture rather than an isolated technical control.
What the practice should do now
A short list of changes an MSP DMARC practice should make in light of NIS2:
Update the discovery template to ask about NIS2 scope. "Is your organisation in scope for NIS2 directly, or for any of your major customers' supply-chain provisions?" This isn't a question your MSP discovery template asked two years ago; it should be the first question now.
Develop a NIS2-attestation document per client. A one-page artefact stating the DMARC posture across all client-owned domains, the historical record (when did each domain reach p=reject, what's the pass rate trend), and the operational cadence (who reviews reports, how often, what's the escalation path for incidents). Clients ask for this; have it ready.
Document your own MSP-side posture. Every MSP-owned domain at p=reject, the platform vendor's NIS2 posture, the change-control discipline of your own DMARC engagements. Bring this to the procurement conversation.
Update the contract templates. SLA language around incident reporting (especially the 24/72/30 timeline NIS2 expects), supply-chain attestations, and DMARC-specific monitoring commitments. The articles on MSP MSA/SOW scoping and DMARC change-management policy cover the operational mechanics.
Train the sales team on the NIS2 angle. The pre-sales conversation now has a regulatory tailwind. Salespeople who can carry the compliance angle credibly close deals faster and at higher prices than those who pitch DMARC on its technical merits alone.
What this article doesn't try to do
This article is a working orientation, not a compliance manual. It doesn't try to be a substitute for legal counsel on the specifics of any NIS2 transposition. It doesn't list every member state's transposition status. It doesn't enumerate every technical-control category in the directive. And it doesn't claim that DMARC alone satisfies any specific NIS2 obligation — it's one control among many that NIS2 implicitly expects.
What it does try to do is help an MSP DMARC practice orient itself to the regulatory landscape that emerged through 2024-2025 and translate that landscape into specific commercial and operational moves.
Tools mentioned
- DMARC Record Generator — compose compliant DMARC records for client domains
- DMARC Validator — verify the published record meets the posture you've committed to
- Email Header Analyzer — triage individual deliverability or impersonation events
- DNS Lookup — verify DMARC publication across resolvers as part of the audit-evidence record
Related articles
- NIS2 essential vs important entities and DMARC — scope-classification implications
- NIS2 obligations for MSPs — supply-chain provisions in depth
- NIS2 incident reporting and DMARC aggregate reports — using DMARC reports as detection input
Author: DMARC AI editorial team Last updated: June 2026