NIS2 and DMARC: Why No Law Tells You What to Do

Part 5 of the DMARCbis series. Start with the overview.

What's in it for me?

Four parts of this series went into the technology: what DMARCbis changes, what full participation means, why a standard is not a mandate. That leaves a question that comes up in customer conversations well before any technical detail: what's in it for me?

It is a fairer question than it sounds. DMARC mainly protects the people who receive your mail from falling for a forged sender. Those recipients include your own staff, though, and an internal mail gets questioned far less often than one from outside. Anyone spoofing your domain is usually aiming at exactly that: the apparent instruction from management to accounts payable, the invoice with the altered bank details. The rest of the benefit is indirect, through your domain's reputation and through nobody sending nonsense in your name. So anyone allocating a tight budget eventually asks the obvious follow-up: do I actually have to? Is there a legal basis that requires this of me?

It depends. If you go looking for an answer in the letter of the law, you will not find DMARC there. No provision names the protocol. But concluding from that that NIS2 is irrelevant to your email security misses the point just as badly. The obligation does not come from the law directly. It comes by a detour, and this final part of the series traces it.

This is where my expertise ends. I can explain what a DMARC record does technically, not what a law requires of you. Raphael Köllner takes that part: a lawyer and Microsoft MVP for compliance, so someone at home in both worlds, the legal one and the Microsoft 365 one. I asked him for the legal context. In passing, one of his answers disproved an assumption I had been working with. Thanks for that, it is worth more than confirmation.

Why the law names no technology

NIS2 is an EU directive, not a regulation that applies directly. It first had to be translated into national law, in Germany through the NIS2 implementation act, which carries the requirements into the BSI Act and has been in force since December 2025.

That translation deliberately leaves room. Raphael calls this an opening clause: points the directive leaves open for the member states to fill themselves. Here the German legislator settled on the "state of the art". Technology changes faster than legislation does. A law that named SPF, DKIM and DMARC explicitly would be out of date at the next change of protocol and would have to be passed again.

The price is the vagueness we started with. What state of the art means in practice is not in the law; it is filled in from outside, through BSI publications and, in other statutes, through legal definitions.

Raphael puts the consequence plainly:

NIS2 is explicitly not an IT project, and run as an IT project it only goes wrong.

Implementation takes lawyers and IT people together, because whether a technical measure meets the state of the art is a question that is neither purely technical nor purely legal.

Which is why this is not about NIS2 as a whole. That would be its own subject. This is about one slice of it: what NIS2 means for email security, and specifically for DMARC.

Does this even apply to you?

Whether it applies to you comes down to two questions. First: what sector are you in? The law lists them in Annexes 1 and 2 to the BSI Act, from energy and transport through health and water to digital services, IT service providers and parts of manufacturing. The lists are more precise than the sector headings suggest: for each sector they name an industry and a specific type of entity, and if you find yourself in there, you are covered. Second: how big is your company? Under section 28 of the BSI Act it becomes relevant at 50 employees, or at over 10 million euros in both turnover and balance sheet total. Some types of entity are covered regardless of size, among them operators of critical installations and DNS service providers.

Meet both criteria and you are directly in scope, in one of the law's two categories, which correspond to what NIS2 calls essential and important entities. The difference is mostly about supervision, not about the technical requirements. Miss the criteria and you are not directly in scope, which is genuinely the case for a lot of smaller companies.

That does not settle it, though, because NIS2 also requires companies in scope to secure their supply chain. They have to bring their suppliers in so that the requirements hold along the chain. For the supplier this does not land as a statutory duty but as a contractual one: it is not the legislator asking something of them, it is their client, who is on the hook themselves.

In practice the difference is slim. Raphael puts it this way: anyone who wants to work with NIS2-regulated companies has to meet the rules, and that runs from the mid-sized business down to the freelancer. The law's size thresholds are no protection against being pulled in through your client.

For email security that is the route that actually matters. Very few companies get a letter from the BSI. A great many do end up with a supplier questionnaire on their desk, as part of a tender, a contract renewal or a customer audit. In it are questions about encryption, access control and, yes, how email communication is secured. Turn up with nothing there and you either go back and fix it or drop out of the running, long before any supervisory authority has heard of you.

Where "state of the art" gets specific for email

NIS2 itself stays deliberately technology-neutral. The law prescribes no protocol; it requires measures that meet the state of the art, an undefined legal concept that shifts over time and is nowhere spelled out in the statute. That is legally sound, and no help at all to anyone who wants to know whether their SPF and DKIM setup is enough.

The BSI fills that gap with two technical guidelines that get specific where the law stays abstract.

TR-03182, "Email Authentication", sets testable requirements for running a mail infrastructure: SPF, DKIM and DMARC, so that a message can be attributed to its stated sender beyond doubt. Meet the requirements and you can demonstrate as much through a conformance certification.

TR-03108, "Secure Email Transport", adds the transmission side: encrypted transport, so that nobody can read along or alter the message unnoticed. The two guidelines are explicitly designed as a pair; authentication and transport together are what add up to secure email communication.

Neither TR is a law or an obligation. They are voluntary conformance certifications, by which an "email service provider" or, in the wording of the text, an "operator of an email service within their organisation" can demonstrate their own security independently. That second phrase is where the bridge is: it covers any company running its own mail operation, which is most of the ones NIS2 applies to.

A court or a supervisory authority having to judge whether a company met the state of the art has, in the BSI guidelines, a concrete and recognised yardstick to work from.

It is not a free pass, though. Raphael points out that under NIS2 the BSI is both the supervisory authority and an advisory body, so it supplies the interpretation it later measures against. You are still not obliged to follow it, and it can be wrong, or wrong two years later. The guidelines are strong evidence of the state of the art, not a guarantee.

DMARC is not in the law. But it is in the guideline that gives the law its substance, by name.

Two levels, not a contradiction

That resolves the apparent tension from part 4. There the subject was the protocol: RFC 9989 obliges nobody to deploy DMARC, and a receiver is not even allowed to enforce p=reject blindly. Read only that and you might take DMARC to be legally optional. That confuses two levels. The protocol describes how DMARC works if you use it, a technical arrangement between sender and receiver. Regulation asks something else, namely what can be expected of a company acting with due care.

The protocol says: nothing compels you technically. Regulation says: you are still expected to have email security that meets the state of the art.

What counts when it matters

This is where the most common mistake sits, and I made it myself: assuming it is enough to take a deliberate risk decision and document it properly. Raphael is unambiguous here. Under NIS2 there is no risk decision in that sense; the requirements have to be met. A well-reasoned decision not to meet them is not a route that is open to you.

Documentation is therefore not a substitute for implementation but the evidence of it: the actual configuration has to match what the documentation says. A policy describing something other than what the configuration does is not protection, it is a finding. For management this is not an abstract matter. They are personally liable for non-compliance and carry a duty to monitor and supervise. Delegating to IT does not discharge it.

There is room to move, but it sits a level down, in the question of what state of the art means in the specific case. Raphael gives an example from encryption: supervisory authorities say it has to be encrypted all the way into the mailbox, yet proxy-based solutions can also meet the state of the art. Which reading holds depends on the specific scope and on how soundly the legal reasoning is built.

Applied to DMARC: the "whether" is not yours to decide. What you have to do is show that your configuration meets the state of the art. This is where the points from part 4 pay off: clean alignment across SPF and DKIM, reports that actually get analysed, a policy chosen on purpose.

Conclusion: no law says DMARC

Back to the opening question. What's in it for me, and do I actually have to?

No law names DMARC. NIS2 stays technology-neutral and requires measures that meet the state of the art, and that term is filled in from outside, among other things by the BSI's technical guidelines, where SPF, DKIM and DMARC very much do appear. The path from the law to the actual technology takes a detour, but it does lead there.

Whether it catches you is decided less by your own sector than by your customers. And if it does catch you, there is less room than many hope: the requirements have to be met, and documentation only evidences that.

What is up for negotiation is not whether, but how you justify that your particular implementation meets the state of the art.

That leaves the first question, the one about benefit. Nothing changes about what would be worth doing anyway. Authenticate cleanly over SPF and DKIM, analyse the reports, choose the policy deliberately. That is good engineering, independent of any regulation, and it protects first of all the people who receive your mail, including the ones in your own building. The regulatory pressure comes on top. It is an additional reason, not a different one.

A follow-up question for Raphael Köllner

The BSI has two technical guidelines, TR-03182 and TR-03108, covering mail authentication and secure transport. Both are formally voluntary. How much weight does it carry in a dispute if a company follows them?

Under NIS2 the BSI is both supervisory authority and advisory body, in the same way the Federal Network Agency is for the AI Act or the data protection authorities are for the GDPR. It has to, and is meant to, provide answers on interpretation. You are not obliged to follow those answers, though, because guidelines can be wrong too, or wrong two years later.

And one more point that comes from Raphael, which I am leaving in unfiltered because it lands on my own trade as well: the assumption that a tool or an IT service provider will simply tell you what to do is misplaced. Neither can determine authoritatively what a particular company needs to implement. What a service provider can do is get the technical side right and document it defensibly. Judging whether that is enough in the specific case belongs at a table where someone with a legal eye is sitting too.

That closes the arc on DMARC. The subject itself is not closed: for ARC there is a proposal in motion to reclassify it as Historic, and with DKIM2 the IETF is working on a successor meant to solve the underlying problem of indirect mail flows. That is still a draft, not a standard, and it will most likely not become one in 2026 either. But there is movement, and with it material for further articles.

DMARCbis series

1. Overview

2. Tag changes

3. DNS tree walk

4. p=reject / full participation

5. NIS2 (this post)

Sources and further reading

• BSI TR-03182 "Email Authentication"

• BSI TR-03108 "Secure Email Transport"

• NIS2 implementation act, official reference in the Federal Law Gazette

• Federal Ministry of the Interior, legislative process and implementation status

• RFC 9989 (DMARCbis)

• Section 28 BSI Act: essential and important entities (size thresholds)

• BSI Act Annex 1: sectors of essential and important entities

• BSI Act Annex 2: sectors of important entities

• draft-ietf-dmarc-arc-to-historic (Reclassifying ARC as Historic)

• draft-ietf-dkim-dkim2-spec (DKIM2)