NIS2 is in force — what it means for DMARC, SPF, and MTA-STS

The German implementation of the EU NIS2 directive, the NIS2UmsuCG, entered into force on 6 December 2025. The registration deadline for affected companies was 6 March 2026 — it has passed. Late registrations remain possible but do not eliminate the standalone administrative offense of missing the original deadline.

That is the bureaucratic surface. The substantive obligation runs deeper: §30 of the revised BSIG (the German Federal Office for Information Security Act) requires “appropriate and proportionate technical, operational, and organizational measures” against cyber risks. The law leaves the specifics open by design, but email authentication falls within the scope by standard interpretation. And under §38 BSIG, company management is personally liable for failure to implement appropriate measures.

This article maps SPF, DKIM, DMARC, and MTA-STS to the specific NIS2 requirements they help fulfill.

Who is affected?

Before NIS2, roughly 4,500 companies in Germany were regulated by the BSI — mostly operators of critical infrastructure. After the implementation law took effect, that number is approximately 29,500. The jump comes from two expansions: significantly more sectors (18 instead of a handful) and lower thresholds.

A company falls under NIS2 if it operates in one of the 18 sectors (including energy, transport, banking, health, digital infrastructure, IT services, public administration, food production, postal services, waste management, chemicals, digital service providers, research, and manufacturers of certain industrial products) and either employs more than 50 people or generates more than €10 million in annual revenue.

Companies must self-assess. The BSI does not perform automatic identification. An official self-check tool is available at betroffenheitspruefung.bsi.de.

What §30 BSIG actually requires

§30 lists ten categories of mandatory measures, including:

Risk analysis and information system security policies
Incident handling
Business continuity (backup, recovery, crisis management)
Supply chain security
Cyber hygiene practices and training
Cryptographic measures
Personnel security, access control, asset management
Multi-factor authentication
Secure communications
Network and information system security

Notably absent from the law itself: specific products, standards, or protocols. §30 is deliberately framework-level. A regulation by the Federal Ministry of the Interior is expected to provide further specificity. Until that regulation arrives, ISO 27001 and the BSI IT-Grundschutz are recognized reference points.

Why email authentication falls under §30

Email authentication is not named in the law. It is nonetheless mandatory, for three structural reasons.

First, “security of network and information systems”. §30 para. 2 no. 10 covers protective measures against email-based attack vectors. Phishing and business email compromise remain at the top of attack patterns against German companies according to the 2025 Bitkom Wirtschaftsschutz study. A risk management strategy that does not enforce email authentication is difficult to argue as “appropriate” before an auditor.

Second, “supply chain security”. §30 para. 2 no. 4 requires security measures for relationships with suppliers and service providers. This covers inbound and outbound email communication with third parties. If your own domain is spoofable because DMARC sits at p=none, your suppliers are equally exposed.

Third, “cryptographic measures”. §30 para. 2 no. 8 requires cryptographic controls. DKIM cryptographically signs outbound mail, and MTA-STS enforces TLS transport between mail servers. Both are established cryptographic mechanisms whose absence would need justification.

Practical mapping: NIS2 obligation to email configuration

The §30 requirements where email authentication plays a direct or supporting role:

Risk analysis and security concepts (§30 para. 2 no. 1)

Email is a central attack vector. A risk analysis that does not address SPF, DKIM, and DMARC leaves an obvious gap. Concrete questions: Is your domain spoofable? Do you detect spoofing attempts at all? How quickly?

Incident handling (§30 para. 2 no. 2)

DMARC aggregate reports provide daily data on authentication failures. Systematic analysis of these reports is the foundation for email-based incident detection. Without analysis, the incident goes unnoticed.

Supply chain security (§30 para. 2 no. 4)

Securing supplier relationships includes checking their email authentication. “What is your DMARC policy?” belongs in supplier questionnaires, IT security audits for outsourcing arrangements, and contracts with IT service providers.

Cyber hygiene and training (§30 para. 2 no. 7)

Authentication does not replace training, but it reduces the burden on employees. With DMARC at p=reject, obvious spoofing attempts never reach the inbox. What remains — look-alike domains, compromised supplier mailboxes — are the harder cases where training is actually useful.

Cryptographic measures (§30 para. 2 no. 8)

DKIM is cryptographic signing of email content. MTA-STS enforces TLS for SMTP. Both belong in any cryptographic concept that covers email traffic.

Secure communications (§30 para. 2 no. 9)

In a narrow reading, this covers internal communications. In a broader reading, external email communication with authorities and business partners falls under the same heading.

What DMARC means in practice — and where most setups fail

The key finding from our own analysis: 87% of the 503 DACH domains we analyzed had a DMARC record. Only 56% enforced it.

Concretely: roughly one in three domains with DMARC sits at p=none. In that configuration, reports flow in, but receiving mail servers are instructed to deliver spoofed messages anyway. From the perspective of an auditor or a cyber insurer after an incident, the argument “DMARC is configured” with p=none is difficult to sustain. Configured is not enforced.

The healthcare sector shows similar numbers: 83% adoption, 56% enforcement. Education is worse: 88% adoption, 26% enforcement. For NIS2 compliance, “appropriate measures” with p=none is a difficult position to defend.

The progression from p=none to p=quarantine and finally p=reject is the operational implementation of the NIS2 requirement. Order matters: first review aggregate reports, identify your legitimate sending sources, configure SPF and DKIM correctly for each one, then progressively tighten the policy.

MTA-STS: the underestimated lever

MTA-STS is the second major gap. In our DACH study, 8% of the 503 domains had MTA-STS enabled. Healthcare: 15%. Education: 6%.

MTA-STS protects against TLS downgrade attacks: without it, an attacker with network access can suppress the TLS handshake between sending and receiving mail servers and read email traffic in plaintext. With MTA-STS in mode=enforce, the sending server refuses to communicate without TLS.

For NIS2, MTA-STS falls under “cryptographic measures” and “network and information system security”. Implementation takes a few DNS records and a static policy file over HTTPS — under an hour of work. The compliance documentation value is significant.

What management needs to understand

§38 BSIG places management explicitly under obligation. Management must approve and oversee the risk management measures from §30. In cases of failure to act, management can be held personally liable.

In practice: “IT handles that” is not a sufficient defense. Management must demonstrate that it understood the risks, approved appropriate measures, and verified their effectiveness. A documented DMARC strategy, regular reviews, and a clear escalation path for incidents are evidence that costs little and matters significantly in a worst-case scenario.

Fines under §65 BSIG can reach €10 million or 2% of worldwide annual revenue for essential entities, and €7 million or 1.4% for important entities. Reputational damage and potential claims from business partners whose data was compromised through insecure email communication can add substantially to the direct cost.

What to do now

Three concrete steps for IT leads in NIS2-affected companies:

1. Status check. What is your current DMARC policy? Is MTA-STS active? Is DNSSEC enabled? A free self-check of these values takes minutes, not hours.

2. Collect and analyze aggregate reports. If DMARC is set to p=none, reports are already arriving. Without systematic analysis, you are collecting data without using it. A DMARC monitoring tool is the pragmatic approach — building in-house rarely makes sense for mid-sized companies.

3. Progressive tightening. p=none is monitoring mode, not protection. p=quarantine routes suspicious mail to spam. p=reject rejects at SMTP level. The target should be p=reject — after careful preparation, so legitimate mail is not lost.

These three steps do not fulfill all §30 requirements. Risk management covers more than email authentication. But they close a concrete gap that is open in most companies and would be difficult to justify in an incident.

Outlook

The 2026 DACH study shows the pattern: most companies have taken the first step (setting up a DMARC record) and stopped before the second step (enforcement). With NIS2, stopping there has become more expensive — not because the law explicitly mandates email authentication, but because “appropriate technical measures” against phishing and spoofing cannot be seriously argued without these mechanisms.

In an audit or incident, “Why was DMARC at p=none?” will not be answered with “It was configured.” The correction is not difficult. It is a deliberate step that has been postponed in many companies for years.

For a 14-day free trial of the DMARCPulse platform and an analysis of your own domains: dmarcpulse.io.