NIS2 ist in Kraft — was das für DMARC, SPF und MTA-STS bedeutet

Seit dem 6. März 2026 ist die NIS2-Registrierungsdeadline abgelaufen. Was bei vielen Unternehmen in Deutschland am Vormittag des 6. März noch nicht registriert war, ist es heute, gut zwei Monate später, vermutlich auch nicht. Das BSI nimmt verspätete Registrierungen weiterhin an, aber das schützt nicht vor dem Bußgeldtatbestand der versäumten Erstregistrierung.

Diese Zeile ist der bürokratische Aufhänger. Der eigentliche Punkt für IT- und Geschäftsleitungen liegt eine Schicht tiefer: §30 BSIG verlangt seit dem 6. Dezember 2025 „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen”. Was darunter genau fällt, lässt das Gesetz bewusst offen — aber E-Mail-Authentifizierung gehört nach gängiger Auslegung dazu. Und die Geschäftsführung haftet bei Versäumnissen persönlich.

Wer als IT-Verantwortlicher oder Geschäftsführer wissen will, wo SPF, DKIM, DMARC und MTA-STS konkret in die NIS2-Anforderungen einsortiert werden, bekommt in diesem Artikel ein praktisches Mapping.

Wer ist betroffen?

Vor NIS2 waren rund 4.500 Unternehmen in Deutschland durch das BSI reguliert, im Wesentlichen KRITIS-Betreiber. Mit dem Inkrafttreten des NIS2-Umsetzungsgesetzes (NIS2UmsuCG) sind es etwa 29.500. Der Sprung kommt durch zwei Erweiterungen: deutlich mehr Sektoren (18 statt einer Handvoll) und niedrigere Schwellenwerte.

Konkret betroffen ist ein Unternehmen, wenn es

• in einem der 18 NIS2-Sektoren tätig ist (darunter Energie, Verkehr, Banken, Gesundheit, digitale Infrastruktur, IT-Services, öffentliche Verwaltung, Lebensmittelproduktion, Post- und Kurierdienste, Abfallwirtschaft, Chemie, Anbieter digitaler Dienste, Forschung, Hersteller bestimmter Industrieerzeugnisse) und
• entweder mehr als 50 Mitarbeiter beschäftigt oder mehr als 10 Mio. Euro Jahresumsatz erwirtschaftet.

Eine offizielle Selbstprüfung bietet das BSI unter betroffenheitspruefung.bsi.de an. Wichtig: Das BSI prüft nicht automatisch. Jedes Unternehmen muss selbst feststellen, ob es betroffen ist, und sich gegebenenfalls registrieren.

Was steht in §30 BSIG?

§30 ist der Paragraph, mit dem sich IT-Verantwortliche und Geschäftsleitungen am meisten beschäftigen sollten. Er listet zehn Kategorien von Maßnahmen auf, die Einrichtungen ergreifen müssen, unter anderem:

• Konzepte zur Risikoanalyse und Sicherheit für Informationssysteme
• Bewältigung von Sicherheitsvorfällen
• Aufrechterhaltung des Betriebs (Backup, Wiederherstellung, Krisenmanagement)
• Sicherheit der Lieferkette
• Maßnahmen zur Cyberhygiene und Schulungen
• Konzepte für den Einsatz von Kryptografie
• Sicherheit des Personals, Zugriffskontrolle, Asset-Management
• Multi-Faktor-Authentifizierung
• Sichere Kommunikation
• Sicherheit der Netzwerk- und Informationssysteme

Was im Gesetz nicht steht: konkrete Produkte, Standards oder Protokolle. Das ist gewollt — §30 BSIG ist als Rahmen formuliert, der durch eine Rechtsverordnung des Bundesministeriums des Innern weiter konkretisiert werden soll. Bis diese Verordnung vorliegt, gelten der ISO-27001-Standard und der BSI IT-Grundschutz als anerkannte Orientierungen.

Wo E-Mail-Authentifizierung in §30 BSIG hineinfällt

E-Mail-Authentifizierung wird im NIS2-Gesetz nicht namentlich genannt. Sie ist trotzdem Pflicht — aus drei strukturellen Gründen.

Erstens, „Sicherheit der Netzwerk- und Informationssysteme”. Diese Pflicht aus §30 Abs. 2 Nr. 10 schließt Schutzmaßnahmen gegen E-Mail-basierte Angriffsvektoren ein. Phishing und Business E-Mail Compromise stehen laut Bitkom-Wirtschaftsschutzstudie 2025 weiterhin an der Spitze der häufigsten Angriffsmuster gegen deutsche Unternehmen. Wer hier keine Authentifizierung durchsetzt, kann sich vor einem Auditor schwer auf „geeignete Maßnahmen” berufen.

Zweitens, „Sicherheit der Lieferkette”. §30 Abs. 2 Nr. 4 verlangt explizit Sicherheitsmaßnahmen für die Beziehungen zu Lieferanten und Dienstleistern. Das schließt eingehende und ausgehende E-Mail-Kommunikation mit Drittparteien ein. Wenn die eigene Domain spoofbar ist, weil DMARC auf p=none steht, sind Lieferanten gleichermaßen exponiert.

Drittens, „Konzepte für den Einsatz von Kryptografie”. §30 Abs. 2 Nr. 8 fordert kryptografische Maßnahmen. DKIM signiert ausgehende E-Mails, MTA-STS erzwingt TLS-Transport zwischen Mailservern. Beide sind etablierte kryptografische Mechanismen, deren Nicht-Einsatz erklärungsbedürftig wird.

Praktisches Mapping: NIS2-Pflicht zu E-Mail-Authentifizierungs-Konfiguration

Hier die wichtigsten §30-Anforderungen, in denen E-Mail-Authentifizierung eine direkte oder indirekte Rolle spielt:

Risikoanalyse und Sicherheitskonzepte (§30 Abs. 2 Nr. 1)

E-Mail ist ein zentraler Angriffsvektor. Wer eine Risikoanalyse erstellt, ohne SPF, DKIM und DMARC darin zu adressieren, lässt eine offensichtliche Lücke offen. Konkret zu bewerten: Ist die eigene Domain spoofbar? Erkennen wir aktuell Spoofing-Versuche überhaupt? Wie schnell?

Bewältigung von Sicherheitsvorfällen (§30 Abs. 2 Nr. 2)

DMARC-Aggregate-Reports liefern täglich Daten zu Authentifizierungs-Fehlversuchen. Diese Reports systematisch auszuwerten ist die Grundlage für Incident Detection im E-Mail-Bereich. Ohne Auswertung bleibt der Vorfall unentdeckt.

Sicherheit der Lieferkette (§30 Abs. 2 Nr. 4)

Wer eine Lieferantenbeziehung absichern will, prüft auch deren E-Mail-Authentifizierung. Die Frage „Wie ist eure DMARC-Policy?” gehört in Lieferantenfragebögen, in IT-Sicherheits-Audits bei Outsourcing und in Verträge mit IT-Dienstleistern.

Cyberhygiene und Schulungen (§30 Abs. 2 Nr. 7)

Authentifizierung allein ersetzt keine Schulung — aber sie reduziert die Last auf die Mitarbeitenden. Wenn DMARC auf p=reject steht, kommen offensichtliche Spoofing-Mails gar nicht erst durch. Was übrig bleibt, sind die schwierigen Fälle (Look-alike-Domains, kompromittierte Lieferanten-Mailboxes), für die Schulungen tatsächlich nötig sind.

Konzepte für Kryptografie (§30 Abs. 2 Nr. 8)

DKIM ist kryptografische Signierung von E-Mail-Inhalten. MTA-STS erzwingt TLS für SMTP. Beide Mechanismen gehören in jedes Kryptografie-Konzept, das den E-Mail-Verkehr betrifft.

Sichere Kommunikation (§30 Abs. 2 Nr. 9)

Im engeren Sinne deckt diese Anforderung die interne Kommunikation ab (Sprachkommunikation, Video, Notfall-Kanäle). Im weiteren Sinne fällt auch hier die externe Kommunikation per E-Mail darunter, insbesondere zu Behörden und Geschäftspartnern.

Was DMARC in der Praxis bedeutet — und wo der Großteil scheitert

Die wichtigste Erkenntnis aus eigener Auswertung: 87 % der von uns analysierten 503 DACH-Domains haben einen DMARC-Eintrag. Nur 56 % setzen ihn auch durch.

Konkret heißt das: Etwa jede dritte Domain mit DMARC steht auf p=none. In dieser Konfiguration werden zwar Reports gesammelt, der Empfänger-Mailserver wird aber angewiesen, gespoofte Mails trotzdem zuzustellen. Aus Sicht eines Auditors oder im Schadensfall vor einer Cyberversicherung wird die Argumentation „DMARC ist konfiguriert” mit p=none schwer durchzuhalten. Konfiguriert ist nicht durchgesetzt.

Im Healthcare-Sektor sieht es ähnlich aus: 83 % Adoption, 56 % Enforcement. In der Bildung noch ungünstiger: 88 % Adoption, 26 % Enforcement. Wer im NIS2-Kontext „geeignete Maßnahmen” nachweisen muss, kommt mit p=none nicht weit.

Der Übergang von p=none zu p=quarantine und schließlich p=reject ist die operative Umsetzung der NIS2-Anforderung. Die Reihenfolge ist wichtig: Erst die Aggregate-Reports auswerten, eigene legitime Sendequellen identifizieren, SPF und DKIM für alle Sendequellen korrekt konfigurieren — und dann schrittweise die Policy verschärfen.

MTA-STS: der unterschätzte Hebel

MTA-STS ist die zweite große Lücke. In der DACH-Studie hatten 8 % der 503 untersuchten Domains MTA-STS aktiv. Im Healthcare-Sektor 15 %, in der Bildung 6 %.

MTA-STS schützt vor TLS-Downgrade-Angriffen: Ohne MTA-STS kann ein Angreifer mit Netzwerk-Zugriff den TLS-Handshake zwischen sendenden und empfangenden Mailservern unterdrücken und den E-Mail-Verkehr im Klartext mitlesen. Mit MTA-STS in mode=enforce weigert sich der sendende Mailserver, ohne TLS zu kommunizieren.

Im NIS2-Kontext fällt MTA-STS unter „Konzepte für Kryptografie” und „Sicherheit der Netzwerk- und Informationssysteme”. Die Implementation ist mit ein paar DNS-Einträgen und einem statischen Policy-File via HTTPS in unter einer Stunde getan — der Effekt für eine NIS2-konforme Dokumentation ist erheblich.

Was die Geschäftsführung wissen muss

§38 BSIG nimmt die Geschäftsführung explizit in die Pflicht. Sie muss die Risikomanagementmaßnahmen nach §30 billigen und überwachen. Bei Pflichtverletzungen kann sie persönlich haftbar gemacht werden.

Praktisch bedeutet das: Im Schadensfall reicht „das macht doch die IT” nicht aus. Die Geschäftsführung muss nachweisen können, dass sie die Risiken kannte, geeignete Maßnahmen genehmigt hat und deren Wirksamkeit überprüft. Eine dokumentierte DMARC-Strategie, regelmäßige Auswertungen und ein klarer Eskalationspfad bei Vorfällen sind hier Belege, die wenig kosten und im Ernstfall viel wert sind.

Bußgelder sind bei wesentlichen Einrichtungen bis 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes möglich (§65 BSIG), bei wichtigen Einrichtungen bis 7 Millionen Euro oder 1,4 % des Umsatzes. Dazu kommen Reputationsschäden und potenzielle Schadensersatzansprüche von Geschäftspartnern, deren Daten durch unsichere E-Mail-Kommunikation kompromittiert wurden.

Was jetzt zu tun ist

Drei konkrete Schritte für IT-Verantwortliche in NIS2-betroffenen Unternehmen:

1. Statusprüfung. Wer steht aktuell auf welcher DMARC-Policy? Wer hat MTA-STS aktiviert? Wer hat DNSSEC? Die kostenlose Selbstprüfung dieser Werte ist Sache von Minuten, nicht Stunden.

2. Aggregate-Reports einsammeln und auswerten. Wenn DMARC auf p=none steht, kommen schon heute Berichte. Wer sie nicht systematisch auswertet, sammelt sie nur. Ein DMARC-Monitoring-Tool ist hier die pragmatische Lösung — Eigenbau lohnt sich für die meisten Mittelständler nicht.

3. Schrittweise Verschärfung. p=none ist Monitoring-Modus, kein Schutz. p=quarantine schickt verdächtige Mails in den Spam-Ordner. p=reject weist sie auf SMTP-Ebene ab. Ziel sollte p=reject sein — nach gründlicher Vorbereitung, damit keine legitimen Mails verlorengehen.

Diese drei Schritte erfüllen die §30-Anforderungen nicht vollständig — Risikomanagement umfasst mehr als E-Mail-Authentifizierung. Aber sie schließen eine konkrete Lücke, die bei den meisten Unternehmen offen ist und im Schadensfall schwer zu rechtfertigen wäre.

Ausblick

Die DACH-Studie 2026 zeigt: Die meisten Unternehmen haben den ersten Schritt (DMARC-Eintrag setzen) gemacht und sind beim zweiten Schritt (Enforcement) stehengeblieben. Mit NIS2 ist das Stehenbleiben teurer geworden — nicht weil das Gesetz E-Mail-Authentifizierung explizit verlangt, sondern weil „geeignete technische Maßnahmen” gegen Phishing und Spoofing ohne diese Mechanismen nicht ernsthaft argumentierbar sind.

Wer im NIS2-Audit oder im Schadensfall vor einer Versicherung steht, wird die Frage „Warum stand DMARC auf p=none?” nicht mit „Das war ja konfiguriert” beantworten können. Die Korrektur ist nicht aufwändig. Sie ist nur ein bewusster Schritt, der bei vielen Unternehmen seit Jahren ausgeblieben ist.

Für einen 14-tägigen kostenlosen Test der DMARCPulse-Plattform und eine Auswertung der eigenen Domains: dmarcpulse.io.