DMARC-Nachweise für ISO 27001, NIS2, DORA und GDPR

Es beginnt damit, dass ein Finanzdirektor um 07:42 Uhr eine E-Mail an den CISO weiterleitet.

„Haben wir das versendet?“

Die Nachricht wirkt perfekt. Gleiches Logo, gleiche Fußzeile, gleicher Ton wie das Abrechnungsteam. Sie behauptet, die Bankverbindung habe sich geändert. Der Anzeigename des Absenders ist korrekt. Die Domain ist kein Tippfehler und keine Lookalike-Domain. Der Angreifer fälscht die echte Domain.

Um 08:15 Uhr bestätigt das Sicherheitsteam die unbequeme Wahrheit: SPF ist vorhanden, aber zu weit gefasst, DKIM ist nur für die zentrale E-Mail-Plattform aktiviert, mehrere Marketing-Tools versenden unsignierte E-Mails, DMARC befindet sich noch im Überwachungsmodus, und niemand findet die letzte Überprüfung der MTA-STS-Richtlinie der Domain. Die Organisation führt „E-Mail-Sicherheit“ in einer Präsentation auf, aber die Nachweise liegen verstreut in DNS-Screenshots, Lieferantenportalen, alten Jira-Tickets und einer Tabelle, für die jemand verantwortlich war, der das Unternehmen im Vorjahr verlassen hat.

Um 10:30 Uhr fragt die Rechtsabteilung, ob Kundendaten betroffen sein könnten. Die Compliance-Funktion fragt, ob dies für eine Meldung nach NIS2 relevant ist. Ein Kunde aus dem Finanzdienstleistungssektor fragt, ob das Unternehmen an DORA ausgerichtete IKT-Risikokontrollen nachweisen kann. Die Interne Revision fragt, wie dies auf ISO/IEC 27001:2022 abgebildet wird. Das Leitungsorgan stellt eine einfachere Frage: „Warum konnte sich jemand als wir ausgeben?“

Diese Frage ist der Grund, warum E-Mail-Authentifizierung im Jahr 2026 kein DNS-Nischenthema mehr ist. DMARC, SPF, DKIM, MTA-STS und TLS-RPT sind nachweiserzeugende Kontrollen. Sie reduzieren das Risiko von Phishing und Domain-Spoofing, erzeugen aber auch die Artefakte, die Auditoren erwarten: Richtlinienentscheidungen, Verantwortlichkeiten, technische Baselines, Rechenschaftspflicht von Lieferanten, Protokolle, Überwachungsaufzeichnungen, Ausnahmen, Änderungsgenehmigungen und Auslöser für die Sicherheitsvorfallreaktion.

Die Compliance-Frage lautet nicht: „Haben wir DMARC?“ Sie lautet: „Können wir nachweisen, dass E-Mail-Authentifizierung gesteuert, überwacht, überprüft und mit Risiken verknüpft ist?“

Die Nachweislücke, die Auditoren immer wieder feststellen

Ein zweites Szenario ist ebenso häufig. Das externe Audit läuft bei einem schnell wachsenden Fintech-Unternehmen. Der Auditor wechselt vom Thema Aufrechterhaltung des Geschäftsbetriebs zum Vorfallmanagement und fragt den CISO nach Business Email Compromise.

Der CISO erklärt, dass das Unternehmen Anti-Phishing-Filter und vierteljährliche Security-Awareness-Schulungen einsetzt.

Der Auditor nickt und fragt dann gezielter: „Zeigen Sie mir die Governance rund um DMARC, SPF und DKIM. Ich muss Verantwortlichkeiten, Änderungsaufzeichnungen, Risikobeurteilung, Überwachungsnachweise und die Verbindung zu NIS2-Cyberhygiene sowie zum DORA-Rahmenwerk für das Management von IKT-Risiken sehen.“

Der Raum wird still.

Das technische Team hat DMARC vor Monaten umgesetzt, aber im ISMS gibt es keinen Richtlinienverweis, kein zentrales Nachweispaket, keine Verknüpfung zum Risikoregister und keinen genehmigten Fahrplan zur Durchsetzung. Die Kontrolle mag technisch vorhanden sein, ist aber für die Governance unsichtbar.

Das ist die Nachweislücke.

Ein ausgereiftes Programm zur E-Mail-Authentifizierung beantwortet sechs Auditfragen:

1. Welche Domains und Subdomains liegen im Geltungsbereich?
2. Wer ist für jede Domain, DNS-Zone, jeden E-Mail-Fluss und jeden Versanddienst verantwortlich?
3. Welche Systeme dürfen im Namen der Organisation E-Mails versenden?
4. Welche Authentifizierungsmechanismen werden durchgesetzt, überwacht und überprüft?
5. Wie werden Ausnahmen genehmigt, Risiken akzeptiert und Ausnahmen zurückgeführt?
6. Welche Nachweise belegen, dass die Kontrolle über einen Zeitraum wirksam betrieben wurde?

ISO/IEC 27001:2022 macht daraus ein Thema des Managementsystems. Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation ihren Kontext, Anforderungen interessierter Parteien, Grenzen des Geltungsbereichs, Schnittstellen und Abhängigkeiten versteht. E-Mail-Authentifizierung berührt all diese Aspekte. Ihr Domain-Registrar kann ein Lieferant sein. DNS kann in Cloud-Infrastruktur gehostet sein. CRM, Entgeltabrechnungsplattform, Rechnungstool, Anbieter für Marketingautomatisierung und Kundensupportsystem können alle E-Mails unter Ihrer Marke versenden.

Die Klauseln 5.1 bis 5.3 machen dies zu einer Führungsaufgabe. Die oberste Leitung muss Verantwortlichkeiten zuweisen und Informationssicherheit in Geschäftsprozesse integrieren. Eine DMARC-Entscheidung von p=none zu p=quarantine oder p=reject kann Kundenkommunikation, Finanzbenachrichtigungen, HR-Onboarding, Vertriebskampagnen und ausgelagerte Anbieter beeinflussen.

Die Klauseln 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung, Auswahl von Kontrollen und eine Anwendbarkeitserklärung. Domain-Spoofing sollte als Risikoszenario behandelt werden, wobei SPF, DKIM, DMARC, MTA-STS und TLS-RPT — soweit angemessen — als Teil der Behandlung ausgewählt werden. Klausel 8.1 verlangt anschließend operative Planung und Steuerung, einschließlich der Steuerung extern bereitgestellter Prozesse, Produkte und Dienstleistungen, die für das ISMS relevant sind.

Was jede Kontrolle zur E-Mail-Authentifizierung nachweist

SPF, DKIM, DMARC, MTA-STS und TLS-RPT wirken zusammen, weisen aber unterschiedliche Sachverhalte nach.

SPF und DKIM sind Signale für Identität und Integrität. DMARC ist die Richtlinienebene, die diese Signale in Empfängeraktionen überführt. MTA-STS und TLS-RPT unterstützen den sicheren E-Mail-Transport, indem sie helfen, Downgrade- und Fehlkonfigurationsrisiken zu vermeiden.

Für Auditoren liegt der tiefere Wert in wiederholbaren Nachweisen. DMARC-Aggregatberichte zeigen, wer unter Ihrer Domain sendet. TLS-Berichte zeigen, ob verschlüsselte Zustellung fehlschlägt. Änderungstickets zeigen, ob Governance vorhanden ist. Lieferantenaufzeichnungen zeigen, ob Abhängigkeiten in der Lieferkette bekannt sind.

Domains zuerst in das Asset-Register aufnehmen

E-Mail-Authentifizierung kann nicht gesteuert werden, wenn Domains nicht als Assets behandelt werden.

Die KMU-Richtlinie zum Asset-Management Richtlinie zum Asset-Management - KMU nimmt Domains und E-Mail-bezogene Identitäten ausdrücklich in den Geltungsbereich auf:

„Digitale Zugangsdaten und Dienste: Domainnamen, digitale Zertifikate, API-Schlüssel, E-Mail-Konten, Cloud-Anmeldungen“

Aus dem Abschnitt „Geltungsbereich“, Richtlinienklausel 2.2.4.

Für größere Organisationen wendet die Enterprise-Richtlinie zum Asset-Management Richtlinie zum Asset-Management dieselbe Logik an:

„Logische Assets: Domainnamen, Lizenzen, Benutzerkonten, Baseline-Konfigurationen“

Aus dem Abschnitt „Geltungsbereich“, Richtlinienklausel 2.2.5.

Wenn Domains Assets sind, können sie Verantwortliche, Kritikalitätsbewertungen, Überprüfungszyklen, Lieferantenabhängigkeiten, Änderungskontrollen und Ablageorte für Nachweise haben. Wenn sie nur DNS-Einträge sind, bleiben sie in der Regel unverwaltet, bis etwas ausfällt.

Ein prüfungsbereites Domain- und E-Mail-Versandregister sollte Folgendes enthalten:

Dieses Register unterstützt ISO/IEC 27001:2022 Annex A Maßnahme A.5.9 Inventar von Informationen und anderen zugehörigen Assets, A.8.9 Konfigurationsmanagement, A.5.19 Informationssicherheit in Lieferantenbeziehungen und A.5.23 Informationssicherheit für die Nutzung von Cloud-Services. Es unterstützt außerdem die Inventarergebnisse des NIST CSF 2.0 für Assets, Services, Lieferanten und Kritikalität.

Änderungsmanagement für DNS- und E-Mail-Fluss-Entscheidungen nutzen

E-Mail-Authentifizierung bricht, wenn das Änderungsmanagement schwach ist. Ein Vertriebsteam fügt eine Outreach-Plattform hinzu. HR führt ein Bewerbermanagement-Tool ein. Finance wechselt die Rechnungssoftware. Marketing zieht zu einem neuen E-Mail-Service-Provider um. Jede Geschäftsentscheidung erzeugt einen neuen Absender.

Die Enterprise-Änderungsmanagement-Richtlinie Änderungsmanagement-Richtlinie formuliert die Nachweisanforderung ausdrücklich:

„Alle Änderungsanträge, Überprüfungen, Genehmigungen und unterstützenden Nachweise müssen im zentralen Änderungsmanagementsystem aufgezeichnet werden.“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.

Ein belastbares Änderungsticket zur E-Mail-Authentifizierung sollte enthalten:

• Geschäftliche Begründung für den neuen Absender.
• Betroffene Domain oder Subdomain.
• Auswirkungen auf SPF-Include oder sendende IP-Adresse.
• DKIM-Selektor und Schlüsselverantwortung.
• Testergebnis des DMARC-Alignments.
• Auswirkungen auf MTA-STS oder MX, falls vorhanden.
• Datenklassifizierung der versendeten Nachrichten.
• Verweis auf die Prüfung der Lieferantensicherheit.
• Rollback-Plan.
• Genehmigung durch Domain-Verantwortlichen und Sicherheit.
• Testnachweis nach der Implementierung.
• Überprüfungsdatum oder Ablaufdatum für temporäre Einstellungen.

Das ist der Unterschied zwischen „ein DNS-Administrator hat einen Eintrag geändert“ und „das ISMS hat eine risikorelevante Änderung gesteuert“.

Ein praktischer 30-Tage-Plan für Nachweise zu DMARC, SPF, DKIM und MTA-STS

Ein CISO benötigt kein sechsmonatiges Transformationsprojekt, um die Nachweisreife zu verbessern. Ein fokussierter 30-Tage-Sprint kann eine belastbare Baseline schaffen.

Woche 1: Domains, Absender und Verantwortlichkeiten ermitteln

Exportieren Sie alle Domains aus dem Registrar und dem DNS-Anbieter. Ziehen Sie Daten zu E-Mail-Flüssen aus E-Mail-Gateway, CRM, Helpdesk, Marketingplattform, Abrechnungssystem und Cloud-Benachrichtigungsdiensten. Erstellen Sie das Domain- und Versandregister.

Nehmen Sie auch geparkte Domains und defensive Registrierungen auf. Geparkte Domains werden häufig ignoriert, können aber weiterhin missbraucht werden, wenn DMARC fehlt oder schwach ist.

Woche 2: SPF- und DKIM-Alignment korrigieren

Überprüfen Sie SPF auf zu weitreichende Mechanismen, veraltete Includes, doppelte Anbieter und Risiken durch Lookup-Grenzen. Identifizieren Sie für DKIM jeden Absender, der E-Mails nicht signiert oder mit einer Domain signiert, die nicht mit DMARC aligned ist.

Genehmigen Sie einen SaaS-Absender nicht nur, weil E-Mail funktioniert. Genehmigen Sie ihn, weil:

• der Lieferant im Versandregister aufgeführt ist,
• SPF- und DKIM-Konfiguration dokumentiert sind,
• DKIM-Selektoren inventarisiert sind,
• Schlüsselverantwortung und Erwartungen an die Überprüfung klar sind,
• die Sicherheitsdokumentation des Lieferanten eine sichere E-Mail-Verarbeitung stützt,
• der Geschäftsverantwortliche jede temporäre Ausnahme akzeptiert.

An dieser Stelle werden NIS2 und DORA praktisch. NIS2 Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sicherer Beschaffung und Wartung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Zugriffskontrolle und sicherer Kommunikation. DORA Article 28 verlangt von Finanzunternehmen, IKT-Drittparteienrisiken als Teil des Rahmenwerks für das Management von IKT-Risiken zu steuern, einschließlich gebotener Sorgfalt, vertraglicher Erwartungen, Überwachung und Exit-Planung.

Wenn ein Marketinganbieter nicht authentifizierte E-Mails über Ihre Domain versendet, ist das nicht nur ein Marketingthema. Es ist Lieferantenrisiko, Risiko der Markenimitation und potenzieller Schaden für Kunden.

Woche 3: DMARC in Richtung Durchsetzung bewegen

Der Überwachungsmodus ist nützlich, aber dauerhaftes p=none ohne genehmigten Fahrplan ist ein schwacher Nachweis.

Ein belastbarer DMARC-Durchsetzungsplan sollte enthalten:

• Prüfung der Baseline-Aggregatberichte.
• Identifizierung legitimer und illegitimer Quellen.
• Mängelbehebung bei legitimen, fehlschlagenden Quellen.
• Fachliche Validierung kritischer E-Mail-Flüsse.
• Schrittweise Erhöhung der Richtlinie auf pct=25, pct=50, pct=100.
• Übergang von p=none zu p=quarantine.
• Übergang zu p=reject, wenn Risiko und betriebliche Bereitschaft dies zulassen.
• Gesonderte Behandlung von Subdomains mit sp=.
• Ausnahmenregister mit Ablaufdaten.
• Genehmigung des Restrisikos durch das Management.

Dies unterstützt ISO/IEC 27001:2022 Klausel 6.1.3 Risikobehandlung und Klausel 8.1 operative Planung und Steuerung. Es gibt der Internen Revision außerdem einen klaren Prüfpfad: Entscheidung, Implementierung, Überwachung, Ausnahme, Genehmigung und Überprüfung.

Woche 4: MTA-STS, TLS-RPT und Überwachung validieren

MTA-STS wird häufig übersehen, weil es ausgehendes Marken-Spoofing nicht in gleicher Weise stoppt wie DMARC. Es ist jedoch hoch relevant für sichere Kommunikation und den Schutz von Informationen während der Übertragung. Es teilt kompatiblen sendenden Servern mit, dass E-Mails an Ihre Domain über TLS zugestellt werden sollen, und validiert die MX-Identität.

Die Enterprise-Richtlinie zu kryptografischen Kontrollen Richtlinie zu kryptografischen Kontrollen legt eine klare Baseline für Transportsicherheit fest:

„Transportsicherheit: TLS 1.2 oder höher (vorzugsweise TLS 1.3)“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.5.

Für KMU schließt die Richtlinie zu kryptografischen Kontrollen Richtlinie zu kryptografischen Kontrollen - KMU die E-Mail-Übertragung ausdrücklich ein:

„Daten, die per E-Mail, über Unternehmens-VPNs und Webportale übertragen werden“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.4.

Tests sollten MX-TLS-Validierung, Verfügbarkeit der MTA-STS-Richtliniendatei, Zustand des HTTPS-Zertifikats, Prüfung von TLS-RPT-Berichten und Triage-Aufzeichnungen zu Fehlern umfassen.

E-Mail-Authentifizierung auf ISO/IEC 27001:2022 Annex A abbilden

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls hilft, technische Nachweise mit Audit-Erwartungen über verschiedene Rahmenwerke hinweg zu verbinden. Es ist kein eigenständiger Kontrollsatz, sondern ein Zuordnungs- und Auditleitfaden für Maßnahmen nach ISO/IEC 27001:2022 und verwandte Standards.

Für ISO/IEC 27001:2022 Annex A Maßnahme A.5.14 Informationsübertragung erläutert Zenith Controls die Beziehung zur Kryptografie:

„Sichere Informationsübertragung stützt sich auf kryptografische Kontrollen, wie in 8.24 beschrieben.“

Das ist die Beziehung zwischen geschäftlicher E-Mail, DKIM, MTA-STS und TLS. E-Mail ist ein Kanal zur Informationsübertragung. DKIM unterstützt Authentizität und Integrität von Nachrichten. MTA-STS und TLS unterstützen den Schutz der Übertragung.

Für Annex A Maßnahme A.8.24 Einsatz von Kryptografie verknüpft Zenith Controls Kryptografie mit Informationsübertragung, Datenschutz, Schutz personenbezogener Daten, Klassifizierung und Schwachstellenmanagement. Für Annex-A-Maßnahmen A.8.15 Protokollierung und A.8.16 Überwachungstätigkeiten verbindet der Leitfaden Protokolle und Überwachung mit Ereignismanagement, Sammlung von Nachweisen, Überprüfung, Analyse und Auditierbarkeit.

Die KMU-Richtlinie zur Protokollierung und Überwachung Richtlinie zur Protokollierung und Überwachung - KMU legt fest:

„Protokollierung muss, soweit verfügbar, aktiviert und konfiguriert werden“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.5.1.1.

Die Enterprise-Richtlinie zur Protokollierung und Überwachung Richtlinie zur Protokollierung und Überwachung umfasst:

„Externe Kommunikation und Auslöser durch Firewall-Regeln“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.6.

Für E-Mail-Authentifizierung sollte externe Kommunikation Mail-Gateway-Ereignisse, Verarbeitung von DMARC-Aggregatberichten, Trends bei DKIM-Fehlschlägen, verdächtige Quellinfrastruktur, TLS-RPT-Fehler und Spoofing-Versuche umfassen, die eine Sicherheitsvorfall-Triage auslösen.

Der Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint überführt dies in praktische Kontrollvalidierung. In der Phase „Controls in Action“, Schritt 20, weist er Teams an, die Sicherheit von Netzwerkdiensten zu validieren:

„Listen Sie alle internen und externen Netzwerkdienste auf (DNS, VPN, SMTP, DHCP, API-Gateways usw.).

✓ Bestätigen Sie für jeden Dienst, dass sichere Protokolle verwendet werden (z. B. DNSSEC, TLS 1.2+, SSH statt Telnet).
✓ Prüfen Sie, wie der Zugriff auf jeden Dienst kontrolliert wird (z. B. IP-Positivlisten, Authentifizierung, Zertifikate).
✓ Wenn Dienste von Dritten verwaltet werden (z. B. DNS, SD-WAN, gehostetes VPN), prüfen Sie die Sicherheitsklauseln im SLA oder Lieferantenvertrag. Aktualisieren Sie Ihr Service-Register und halten Sie fest, wo Sicherheitsverantwortlichkeiten liegen, intern oder extern.“

Auf E-Mail angewendet wird daraus ein Arbeitsplan für DNS, SMTP, TLS, gehostete Mail-Gateways, Lieferantenabsender und Verantwortungsgrenzen.

Cross-Compliance-Zuordnung: ein Nachweispaket, viele Verpflichtungen

Dasselbe Nachweispaket kann ISO/IEC 27001:2022, NIS2, DORA, GDPR und NIST CSF 2.0 unterstützen, wenn es richtig strukturiert ist.

NIS2 ist besonders relevant für wesentliche und wichtige Einrichtungen sowie für bestimmte Kategorien digitaler Infrastruktur und digitaler Anbieter. Article 20 macht Cybersicherheits-Governance zu einer Verantwortung des Leitungsorgans, während Article 21 die Grundlage für das Risikomanagement festlegt. Nachweise zur E-Mail-Authentifizierung helfen zu zeigen, dass sichere Kommunikation, Lieferantenbeziehungen, Umgang mit Informationssicherheitsvorfällen, Wirksamkeitsbewertung und Cyberhygiene operativ verankert und nicht nur theoretisch beschrieben sind.

Für Finanzunternehmen gilt DORA seit dem 17. Januar 2025. Articles 5 und 6 verlangen Rechenschaftspflicht des Leitungsorgans und ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken. Article 17 verlangt Prozesse zur Erkennung, Steuerung, Aufzeichnung, Klassifizierung, Eskalation und Mängelbehebung bei IKT-bezogenen Vorfällen. Article 28 macht das Management von IKT-Drittparteienrisiken zu einer formalen Verantwortung. E-Mail-Anbieter, Marketingplattformen, Systeme für Zahlungsbenachrichtigungen und Kundenkommunikationstools können alle Teil dieser IKT-Abhängigkeitskette werden.

Für GDPR ist die Kernfrage, ob E-Mail zur Verarbeitung personenbezogener Daten genutzt wird. Article 5 umfasst Integrität, Vertraulichkeit und Rechenschaftspflicht. Article 32 verlangt geeignete technische und organisatorische Maßnahmen. Wenn Rechnungen, HR-Nachrichten, Konto-Mitteilungen, Support-Tickets oder Onboarding-E-Mails personenbezogene Daten enthalten, werden E-Mail-Authentifizierung und Transportsicherheit Teil der Nachweise zur Sicherheit der Verarbeitung.

Sicherheitsvorfallreaktion: wenn Berichte zur Frühwarnung werden

DMARC-Aggregatberichte sind nicht nur Compliance-Nachweise. Sie sind Frühwarndaten. Ein sprunghafter Anstieg fehlgeschlagener Authentifizierung aus unbekannter Infrastruktur kann auf aktives Spoofing, Shadow IT, Fehlkonfiguration eines Lieferanten oder einen kompromittierten Absender hindeuten.

Nach NIS2 Article 23 müssen wesentliche und wichtige Einrichtungen erhebliche Sicherheitsvorfälle unverzüglich melden, unter Verwendung gestufter Berichterstattung mit Frühwarnung, Vorfallmeldung und Abschlussbericht. Nicht jeder Spoofing-Versuch ist meldepflichtig, aber die Organisation muss Schweregrad, Betriebsunterbrechung, finanziellen Verlust, grenzüberschreitende Auswirkungen und Schaden für Empfänger bewerten können.

Nach DORA Article 17 müssen Finanzunternehmen einen Managementprozess für IKT-bezogene Vorfälle definieren und umsetzen, Vorfälle und erhebliche Cyberbedrohungen aufzeichnen, Ursachen identifizieren, Frühwarnindikatoren nutzen, nach Schweregrad und Servicekritikalität klassifizieren, Rollen zuweisen, Kommunikation festlegen und schwerwiegende Vorfälle eskalieren. DORA Article 19 behandelt anschließend die Meldung schwerwiegender IKT-bezogener Vorfälle.

Für GDPR lautet die Frage, ob das Ereignis zu unbeabsichtigter oder unrechtmäßiger Vernichtung, Verlust, Veränderung, unbefugter Offenlegung von oder unbefugtem Zugriff auf personenbezogene Daten geführt hat. Eine gefälschte E-Mail, die Kunden dazu verleitet, personenbezogene Daten an einen Angreifer zu übermitteln, kann eine Bewertung als Datenschutzverletzung auslösen, selbst wenn interne Systeme nicht kompromittiert wurden.

Die Enterprise-Richtlinie zur Audit- und Compliance-Überwachung Richtlinie zur Audit- und Compliance-Überwachung erläutert, warum disziplinierte Nachweisführung wichtig ist:

„Um belastbare Nachweise und einen Prüfpfad zur Unterstützung von Anfragen von Aufsichtsbehörden, Gerichtsverfahren oder Kundenanfragen zur Vertrauensbildung zu erzeugen.“

Aus dem Abschnitt „Ziele“, Richtlinienklausel 3.4.

Die KMU-Richtlinie zur Audit- und Compliance-Überwachung Richtlinie zur Audit- und Compliance-Überwachung - KMU ergänzt eine Anforderung an die Nachweisqualität:

„Metadaten (z. B. wer sie wann und aus welchem System erhoben hat) müssen dokumentiert werden.“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.3.

Eine DMARC-Untersuchungsakte sollte daher Berichtsquelle, Erhebungszeitpunkt, Analyst, betroffene Domains, vermutete Absender-IPs, Authentifizierungsergebnisse, Bewertung der geschäftlichen Auswirkungen, getroffene Entscheidungen und Abschlussgenehmigung dokumentieren.

Was Auditoren anfordern werden

Unterschiedliche Auditoren verwenden unterschiedliche Begriffe, aber die Nachweise überschneiden sich.

Rechnen Sie mit praktischen Fragen:

• Zeigen Sie die DMARC-Berichte des letzten Quartals.
• Zeigen Sie, wie diese geprüft wurden.
• Zeigen Sie die Ausnahme für diesen fehlschlagenden Absender.
• Zeigen Sie, wer diese SPF-Änderung genehmigt hat.
• Zeigen Sie, ob DKIM-Selektoren inventarisiert und überprüft werden.
• Zeigen Sie, wie MTA-STS nach Änderungen am Mail-Gateway getestet wird.
• Zeigen Sie, wie Spoofing-Ereignisse in die Sicherheitsvorfall-Triage eingehen.
• Zeigen Sie, wie Lieferantenabsender bei Vertragsbeendigung entfernt werden.

Eine kompakte interne Audit-Checkliste für 2026

Nutzen Sie diese Checkliste als Ausgangspunkt für interne Audits, Kontrolltests oder eine Überprüfung der Nachweise zur E-Mail-Authentifizierung.

• Alle Domains und Subdomains sind im Asset-Register aufgeführt.
• Geparkte und defensive Domains sind durch DMARC abgedeckt.
• Jeder autorisierte Absender hat einen Geschäftsverantwortlichen und einen technischen Verantwortlichen.
• SPF-Einträge werden auf veraltete Includes und übermäßigen Geltungsbereich geprüft.
• DKIM ist für legitime Absender aktiviert, sofern unterstützt.
• DKIM-Selektoren sind inventarisiert und werden überprüft.
• DMARC ist für Root-Domains und relevante Subdomains ausgerollt.
• DMARC hat einen Fahrplan zur Durchsetzung, keine unbefristete Überwachung.
• DMARC-Aggregatberichte werden in einem definierten Rhythmus geprüft.
• MTA-STS ist für eingehende E-Mail-Domains konfiguriert, soweit anwendbar.
• TLS-RPT-Berichte werden gesammelt und triagiert.
• Änderungen an der E-Mail-Authentifizierung folgen dem Änderungsmanagement.
• Lieferanten-Onboarding umfasst Anforderungen an den E-Mail-Versand.
• Lieferanten-Offboarding entfernt SPF-Includes, DKIM-Selektoren und Versandberechtigungen.
• Ausnahmen haben Risikoverantwortliche, Ablaufdaten und kompensierende Kontrollen.
• Spoofing-Spitzen und Authentifizierungsfehler fließen in die Sicherheitsvorfallreaktion ein.
• Nachweise enthalten Metadaten, Quelle, Datum, Erheber und System.
• Das Management erhält regelmäßige Kennzahlen und Risikoberichte.

Der Zenith Blueprint, Phase Risikomanagement, Schritt 14, empfiehlt die Erstellung regulatorischer Zuordnungstabellen für anwendbare Verpflichtungen:

„Für jede Regulierung können Sie, sofern anwendbar, eine einfache Zuordnungstabelle erstellen (zum Beispiel als Anhang in einem Bericht), die die wichtigsten Sicherheitsanforderungen der Regulierung und die entsprechenden Kontrollen/Richtlinien in Ihrem ISMS aufführt. Dies ist in ISO 27001 nicht verpflichtend, aber eine sinnvolle interne Übung, um sicherzustellen, dass nichts übersehen wurde. Es beeindruckt außerdem Auditoren/Bewerter, wenn Sie Sicherheit nicht im luftleeren Raum verwalten, sondern den rechtlichen Kontext kennen.“

Für E-Mail-Authentifizierung wird diese Tabelle zur Brücke zwischen technischer DNS-Realität und Zusicherung auf Ebene des Leitungsorgans.

E-Mail-Authentifizierung in prüfungsbereite Nachweise überführen

Ihre Kunden werden möglicherweise nie fragen, ob Ihr SPF-Eintrag syntaktisch perfekt ist. Sie werden fragen, ob Sie Ihre Marke schützen, Phishing-Risiken reduzieren, Kommunikation absichern, Lieferanten steuern und nachweisen können, dass Ihre Kontrollen funktionieren.

Clarysec hilft Organisationen, E-Mail-Authentifizierung von fragilen technischen Einstellungen in ein prüfungsbereites Kontrollsystem zu überführen. Der praktische nächste Schritt ist eine fokussierte Überprüfung der Nachweise zur E-Mail-Authentifizierung:

1. Domain- und Versandregister erstellen.
2. Status von SPF, DKIM, DMARC, MTA-STS und TLS-RPT abbilden.
3. Lieferanten, Schattenabsender und Ausnahmen identifizieren.
4. DMARC-Durchsetzungsfahrplan erstellen.
5. Nachweise zu Änderungsmanagement, Protokollierung und Sicherheitsvorfallreaktion validieren.
6. Nachweise mit ISO/IEC 27001:2022, NIS2, DORA, GDPR und NIST CSF 2.0 verknüpfen.
7. Ein auditorengerechtes Nachweispaket mit Zenith Blueprint, Zenith Controls und den relevanten Clarysec-Richtlinien vorbereiten.

Wenn Ihre Organisation sich auf eine Zertifizierung nach ISO/IEC 27001:2022, NIS2-Readiness, DORA-Assurance, Überprüfungen der Rechenschaftspflicht nach GDPR oder Sicherheitsfragebögen von Kunden vorbereitet, beginnen Sie mit den Kontrollen, die Angreifer am sichtbarsten missbrauchen: Ihre Domains, Ihre Absender und Ihre E-Mail-Vertrauenskette.

Laden Sie den Zenith Blueprint herunter, nutzen Sie Zenith Controls für die Cross-Compliance-Zuordnung und führen Sie eine 30-tägige Überprüfung der Nachweise zur E-Mail-Authentifizierung durch, bevor der nächste Spoofing-Vorfall oder die nächste Auditanfrage das Gespräch erzwingt.