If you are working out what NIS2 means for your organization's email, this guide is for you. NIS2 is the European Union's updated cybersecurity law, formally Directive (EU) 2022/2555. It widens the older rules to cover many more organizations and sets tougher requirements for the security measures they have to put in place.
One of the first questions people ask is whether it requires DMARC, the standard that stops other people sending email as your domain. The honest answer has two parts. NIS2 never names DMARC anywhere in its text. But it does require organizations to protect their email against spoofing, and to do it at a level that blocks forged mail rather than only monitoring it. In practice, this is what DMARC at enforcement gives you.
This guide covers who NIS2 applies to, where email authentication fits into its requirements, and what to do if NIS2 applies to your organization, whether you manage your own DNS or rely on someone who does.
No, not by name. NIS2 does not mention DMARC, SPF, or DKIM anywhere in its text. What it requires is that organizations in scope take appropriate and proportionate measures to manage their cybersecurity risk, and that they can show evidence of it.
Email authentication is how you meet part of that obligation. Spoofed email is one of the most common ways an attacker can breach your security, and preventing forged email from being sent from your domain is exactly the kind of measure the directive expects. This is what DMARC is designed for, so the practical answer to whether NIS2 requires DMARC is close to "yes," even if it's not explicit.
NIS2 covers medium-sized and large organizations across 18 sectors, including energy, transport, banking, healthcare, drinking water, digital infrastructure, public administration, and postal services. If you run a medium-sized or large organization in one of these sectors, you are likely covered, even if you have never thought of yourself as critical infrastructure.
NIS2 sorts these organizations into two tiers. Essential entities, the larger operators in the most critical sectors, face proactive supervision and the steepest penalties. Important entities, the rest of the organizations in scope, face lighter oversight that mostly applies after an incident.
Essential entities can face fines of up to 10 million euros or 2% of total worldwide annual turnover, whichever is higher, as a penalty for non-compliance. Important entities face up to 7 million euros or 1.4% of turnover. NIS2 also holds senior management personally accountable.
NIS2 sets out its security obligations in Article 21, which lists the risk-management measures affected organizations have to take. The list is deliberately broad: network security, access control, encryption, incident handling, and basic cyber hygiene, among others. Email authentication is not called out on its own, because the directive describes the security results it expects, not the specific methods or technologies you use to achieve them.
NIS2 goes further for one group of organizations. The directive has its own implementing regulation, the Commission Implementing Regulation (EU) 2024/2690, which sets binding technical rules for digital-infrastructure providers such as DNS providers, cloud operators, and managed service providers. It turns Article 21's general language into concrete requirements for them. After it was adopted, the EU cybersecurity agency ENISA published technical implementation guidance in June 2025, setting out how to meet each rule and what evidence an auditor will look for. Email authentication, including SPF, DKIM, and DMARC, is part of its email-security and network-security measures.
If your organization is not one of those digital-infrastructure providers, the implementing regulation does not bind you directly, but NIS2 itself still applies. Its general duty under Article 21 expects proportionate security measures, and protecting your domain against spoofing is a clear example. Email authentication is the standard way to do it.
Because NIS2 names no specific technology, it is fair to ask whether something other than DMARC could keep you compliant. For general email threats, several tools help: a secure email gateway, an anti-phishing filter, link and attachment scanning, and staff security-awareness training. Each has a place in a security program.
None of them solve the specific problem, though. These tools check mail as it arrives in your own inboxes. They do nothing to stop someone forging your domain so a scam email looks like it came from you, sent to your customers, partners, or staff. This threat runs outbound rather than inbound, and the only established way to address it is email authentication. SPF and DKIM prove a message is authorized to use your domain. DMARC then ties these checks to the domain name your recipients see, tells receiving servers how to handle mail that fails, and reports the results back to you. There is no real substitute.
Two related controls often come up here, and neither replaces authentication. Encryption in transit, through MTA-STS and TLS-RPT, also appears in the NIS2 technical guidance, but it protects mail while it travels rather than proving who sent it. BIMI depends on DMARC at enforcement too: it puts your logo next to your messages in the inbox, so it is a reward for doing authentication well, not an alternative to it.
So the choice NIS2 leaves you is not which standard to adopt. It is how you run the one that already exists: which provider, which tooling, and whether you operate it in-house or through a monitoring service. This is also why an auditor expects to see email authentication in place, even though the directive never spells it out.
Publishing a DMARC record is not the same as being protected by it. A record set to p=none tells receiving mail servers to watch and report, but to deliver spoofed messages anyway. To block mail that fails authentication, the policy has to move to p=quarantine or p=reject. This is the line between monitoring and protection, and the level these rules ask for.
Most domains have not crossed it. In DMARCeye's Q1 2026 dataset, most European country domains are still at the monitoring-only policy: roughly 39% of .de domains, 50% of .fr domains, and 43% of .nl domains are at p=none. Czech domains are the most exposed in the set, at about 69% p=none and only one in ten at p=reject. A domain in this group has a DMARC record an auditor can see, but no enforcement behind it.
These figures come from DMARCeye's Q1 2026 industry report on the state of DMARC adoption.
This pattern is not unique to NIS2. The same enforcement bar shows up in the PCI DSS anti-phishing requirement and in the Google and Yahoo sender rules: a record that blocks nothing does not count. If you are not sure what your own domain publishes, you can check it here.
The path to an enforcement policy is the same whether the reason is NIS2, PCI DSS, or not wanting your domain spoofed. The order matters, because moving too fast is how legitimate mail gets blocked.
Start by finding every service that sends email as your domain: your own mail platform, but also the marketing tool, the invoicing system, the helpdesk, and anything else that mails on your behalf. Authenticate each one for SPF or DKIM so its mail passes cleanly. Then read your DMARC aggregate reports for a few weeks to confirm nothing legitimate is failing, and only then move the policy to p=quarantine and on to p=reject. The complete implementation guide walks through each step in detail.
A note for the marketing and communications people likely reading this: if you do not manage your organization's DNS, this is not a change you make alone. The DMARC record lives in DNS, so the move to enforcement belongs to whoever controls your domain's records, usually IT or an external provider. Your part is to make sure every sending tool you own is on the list above, so nothing legitimate gets caught when the policy tightens.
This is the gap DMARCeye's free plan is built to close. It reads your DMARC reports and shows you which senders are passing and which are failing. Then it tells you what to fix next, so moving from monitoring to enforcement is a series of clear steps, not a guess.
NIS2 entered into force at EU level, with a transposition deadline of 17 October 2024 for member states to write it into national law. Many missed that deadline, and national laws have been rolling out on their own timelines since.
In practice, your exact obligations depend on your country's implementing law, not just the directive. The technical direction is settled, though: the implementing regulation and ENISA's guidance describe what good looks like, and email authentication at an enforcement policy is part of it. Check your national transposition status before scoping a compliance project.
NIS2 does not hand you a checklist with DMARC on it. It hands you a duty to manage email risk and prove you are doing it, and email authentication at an enforcement policy is how you meet it. Reading the directive as "DMARC is now mandatory" overstates it. Treating enforcement as optional understates it. The accurate position is in between.
The work is knowing every service that sends as you, getting each one authenticated, and moving to enforcement without breaking legitimate mail. DMARCeye exists to make this work visible and manageable, domain by domain, so compliance becomes a side effect of doing email security properly.