Cyberversicherung: worauf Versicherer beim E-Mail-Schutz achten

Von Thomas · virtueller CISO · 01. September 2026

Die Cyberversicherung ist keine Formalität mehr. Nach Jahren schwerer Schadenbilanzen — medienwirksame Ransomware, vor allem aber Überweisungsbetrug in Serie — haben die Risikoträger ihre Bedingungen verschärft: steigende Prämien, gesenkte Deckungssummen, geschärfte Ausschlüsse und vor allem Zeichnungsfragebögen, die immer mehr wie technische Audits aussehen. In diesen Fragebögen hat eine Rubrik still an Gewicht gewonnen: die E-Mail-Sicherheit, und dort besonders die Authentifizierung der Domain — SPF, DKIM, DMARC.

Diese Entwicklung überrascht nicht. E-Mail bleibt der wichtigste Vektor jener Angriffe, die die Versicherer am meisten kosten, allen voran die Kompromittierung geschäftlicher Kommunikation (BEC, Business Email Compromise) mit ihrer bekanntesten Spielart, dem CEO-Betrug. Ein Teil dieser Angriffe beruht auf einer Zutat, die das DNS neutralisieren kann: der schlichten Fälschung der eigenen Unternehmensdomain. Eine technische Kontrolle, die in eine Zeile passt — p=reject — schließt diesen Kanal, und sie lässt sich von außen überprüfen, ganz ohne eidesstattliche Erklärung.

Dieser Artikel beschreibt, worauf Versicherer beim E-Mail-Schutz achten, warum die DMARC-Policy in der Risikobewertung Gewicht hat, wie manche Akteure die Antworten durch Scans des öffentlichen DNS gegenprüfen und was ein falsch angekreuztes Kästchen im Schadenfall kosten kann. Es ist eine technische Einordnung, keine Rechts- oder Versicherungsberatung: Verträge und Klauseln variieren, und die Lektüre eines Maklers bleibt unersetzlich.

Überweisungsbetrug, der größte Posten der Schadenbilanz

Ransomware macht die Schlagzeilen; Überweisungsbetrug leert die Konten im Stillen. Die öffentlichen Bilanzen konvergieren seit Jahren: BEC rangiert nach Häufigkeit konstant unter den wichtigsten Ursachen von Cyber-Schadenfällen, und die gemeldeten Verluste belaufen sich in den Jahresberichten des FBI (IC3) auf Milliarden Dollar pro Jahr. Das typische Szenario ist technisch völlig unspektakulär: Eine glaubwürdige E-Mail mit einem vertrauten Namen — Geschäftsführung, Lieferant, Steuerkanzlei — verlangt eine geänderte Bankverbindung oder eine dringende Überweisung. Keine Malware, keine Software-Schwachstelle: missbrauchtes Vertrauen, und eine Buchhaltung, die ausführt.

E-Mail ist der nahezu ausschließliche Vektor, und die Identitätsfälschung ist der Treibstoff. Drei Formen kommen vor: der täuschende Anzeigename (die echte Adresse hat mit dem Unternehmen nichts zu tun, nur der angezeigte Name lügt), die Doppelgänger-Domain (beispie1.de statt beispiel.de) und — für die Marke am schädlichsten — die Nutzung der exakten Unternehmensdomain, möglich, solange nichts sie technisch unterbindet. Die vollständige Anatomie des Angriffs, seine Varianten und Gegenmaßnahmen stehen in CEO-Betrug im Detail; hier zählt die versicherungstechnische Konsequenz: Ein Risiko, das so häufig, so teuer und so direkt an identifizierbare Kontrollen gebunden ist, hat am Ende die Zeichnungsfragebögen selbst geformt.

Was die Zeichnungsfragebögen tatsächlich abfragen

Der Cyber-Fragebogen hat sich um einige Säulen standardisiert, die von einem Risikoträger zum nächsten fast universell geworden sind. Zuerst die Multi-Faktor-Authentifizierung, auf Postfächern, Fernzugängen und Administratorkonten — oft die K.-o.-Frage. Dann die Backups: Existenz, Frequenz, Isolierung (Offline- oder unveränderliche Kopien) und Wiederherstellungstests. Weiter die Endpunkt-Erkennung (EDR), das Patch-Management, die Phishing-Sensibilisierung der Teams und das Vorhandensein eines Incident-Response-Plans. Jedes „Nein" hat seinen Preis: Zuschlag, höherer Selbstbehalt, spezielles Sublimit für Betrugsschäden oder gleich die Ablehnung.

In dieser Liste war E-Mail-Sicherheit lange auf „Ist ein Spamfilter im Einsatz?" reduziert. Diese Zeit ist vorbei. Neuere Formulare stellen präzise Fragen: Veröffentlicht die Domain SPF? Werden ausgehende Flüsse mit DKIM signiert? Existiert eine DMARC-Policy, und auf welcher Stufe — p=none, p=quarantine, p=reject? Manche fragen sogar, ob die DMARC-Berichte gesammelt und ausgewertet werden. Die Logik entspricht der von Sicherheitsfragebögen, die große Auftraggeber an Lieferanten versenden: Die E-Mail-Authentifizierung ist von der technischen Fußnote zur erwarteten Kontrolle aufgestiegen, im selben Regal wie MFA oder Backups.

Diese wachsende Präzision ist keine Laune der Aktuare. Unter allen gelisteten Kontrollen besitzt die Domain-Authentifizierung eine seltene Eigenschaft: Sie ist binär, öffentlich und in Sekunden überprüfbar. Ein „ausgerolltes" EDR kann halb ausgerollt sein; eine p=reject-Policy ist veröffentlicht oder eben nicht.

p=reject: das versicherte Risiko schrumpft mechanisch

Ein Versicherungsvertrag deckt einen Erwartungsschaden. Jede Kontrolle, die Wahrscheinlichkeit oder Schwere eines Vorfalls senkt, senkt das auf den Versicherer übertragene Risiko — das ist der Rohstoff der Tarifierung. Und DMARC in strikter Durchsetzung wirkt genau dort. Veröffentlicht eine Domain

_dmarc.beispiel.de.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de"

dann weisen empfangende Server, die die Policy anwenden, jede Nachricht ab, die sich ohne ausgerichtete Authentifizierung auf beispiel.de beruft. Die Fälschung der exakten Domain — die falsche Chef-Mail, „von" der echten Adresse verschickt, an die eigene Buchhaltung oder an die Kunden des Unternehmens — hört auf, eine Option für den Angreifer zu sein. Ein ganzer Teil des CEO-Betrugs wird per Konstruktion blockierbar, vor jedem menschlichen Urteil, vor jedem heuristischen Filter.

Ehrlichkeit verlangt, den genauen Umfang zu benennen: DMARC stoppt weder Doppelgänger-Domains noch täuschende Anzeigenamen noch kompromittierte legitime Konten — drei Vektoren, die andere Gegenmaßnahmen erfordern (defensive Registrierungen, Filterung, MFA, Rückruf-Verfahren vor jeder Änderung einer Bankverbindung). Die Versicherer wissen das, und genau deshalb tritt die DMARC-Frage neben die anderen, statt sie zu ersetzen. In der Landschaft der Betrugskontrollen bietet diese eine aber ein kaum zu schlagendes Kosten-Wirkungs-Verhältnis: eine Zeile DNS, gegenüber der ganzen Welt durchsetzbar.

Das öffentliche DNS spricht: die Zeichnung wird gescannt

Eine unter Versicherten wenig bekannte Tatsache: Ein Teil des Fragebogens lässt sich prüfen, ohne irgendjemanden zu fragen. Der DMARC-Eintrag ist ein öffentlicher DNS-Eintrag — eine Abfrage dig TXT _dmarc.beispiel.de genügt, um ihn zu lesen, und dasselbe gilt für SPF. Makler und Risikoträger stützen sich inzwischen auf externe Bewertungswerkzeuge, die die exponierte Oberfläche der Antragsteller automatisch scannen: offene Ports, Zertifikate, veraltete Dienste … und die DMARC-Policy. Das Ergebnis liegt auf dem Tisch des Zeichners, bevor der ausgefüllte Fragebogen eintrifft.

Die Folgen sind sehr konkret. Eine Antwort, die „E-Mail-Authentifizierung vorhanden" erklärt, während das DNS p=none zeigt — oder gar keinen Eintrag —, erzeugt einen sichtbaren Widerspruch zwischen Erklärtem und Beobachtetem, mit denkbar schlechter Wirkung auf die Einschätzung der Verlässlichkeit des gesamten Dossiers. Umgekehrt spricht eine Domain auf p=reject, kohärent und sauber konfiguriert, für den Antragsteller, ohne dass ein Wort fällt: Die Kontrolle wird beobachtet statt behauptet. Manche Akteure beziehen diese externen Signale ausdrücklich in die Risikobewertung ein, und die Lücke zwischen Erklärung und beobachtbarer Realität wird zum eigenen Kriterium.

Ein falsch angekreuztes Kästchen kann im Schadenfall teuer werden

Versicherung beruht auf einem deklaratorischen Prinzip: Der Vertrag wird auf Grundlage der bei der Zeichnung gegebenen Antworten tarifiert und gewährt. Ein falsch angekreuztes Kästchen — „DMARC in Durchsetzung", während die Domain auf p=none verharrte, „MFA flächendeckend", während ein Zugang ausgenommen blieb — ist kein Verwaltungsdetail. Je nach nationalem Recht und Klauselwerk kann eine unrichtige Erklärung eine anteilige Kürzung der Entschädigung begründen oder sogar die Deckung entfallen lassen, genau in dem Moment, in dem das Unternehmen sie am dringendsten bräuchte. Öffentliche Streitfälle um Cyber-Schäden drehten sich bereits exakt um dieses Terrain: ob die Zeichnungsantworten der Realität entsprachen.

Nichts davon ist Rechtsberatung — jeder Vertrag verdient die eigene Lektüre —, aber die vorsichtige Regel ist einfach und technisch: den realen Zustand erklären, datiert, und ihn aktuell halten. „DMARC auf p=none veröffentlicht, Wechsel auf p=reject für das nächste Quartal geplant" ist eine ehrliche und oft gut aufgenommene Antwort, weil sie ein gesteuertes Programm belegt. Die optimistische Version desselben Kästchens wendet sich gegen den Erklärenden an dem Tag, an dem der Schadenregulierer den Fragebogen mit dem historischen DNS vergleicht — denn das DNS wird archiviert, und die Scanner erinnern sich an vergangene Zustände.

Das Dossier vorbereiten: Zustand, Trajektorie, Nachweise

Vor einem Fragebogen oder einer Verlängerung wird das E-Mail-Kapitel des Dossiers wie ein Audit-Dossier vorbereitet, mit drei Belegstücken.

Zuerst der Zustand: ein exaktes Inventar der Domains der Organisation — aktive, aber auch defensive und ruhende, die die Scanner genauso sehen — mit dem im DNS tatsächlich beobachteten SPF-, DKIM- und DMARC-Zustand für jede einzelne. Eine ruhende Domain ohne Policy ist eine offene Tür mit dem Namen des Unternehmens; sie zu neutralisieren (SPF v=spf1 -all, DMARC p=reject) dauert Minuten und verbessert das Gesamtprofil.

Dann die Trajektorie: für Domains, die noch unterwegs sind, der dokumentierte Fortschritt von p=none zu p=reject, mit dem Datum jedes Schritts. Der Zwischenschritt über p=quarantine oder der von DMARCbis eingeführte Testmodus t=y zeigt einen kontrollierten Hochlauf statt eines verlängerten Status quo.

Schließlich die Nachweise: die tatsächliche Sammlung der aggregierten Berichte, Alarme bei unbekannten Quellen, eine Spur laufenden Betriebs — periodische Reviews, Tickets, ein Audit-Journal. Es ist exakt die Nachweislogik eines Managementsystems für Informationssicherheit, entwickelt in DMARC im ISO-27001-Programm: Eine Kontrolle ohne Funktionsnachweis ist kaum mehr wert als eine fehlende Kontrolle — in den Augen eines Auditors wie eines Zeichners.

Jenseits der Prämie: das reale Risiko senken

Es wäre schade, die E-Mail-Authentifizierung auf eine versicherungstechnische Compliance-Übung zu reduzieren. Das Kästchen im Fragebogen spiegelt nur eine interessantere Realität: p=reject beruhigt nicht bloß einen Zeichner, es beseitigt tatsächlich einen Angriffsvektor — den demütigendsten von allen, jenen, der den exakten Namen des Unternehmens gegen die eigenen Teams, die Kunden und die Lieferanten wendet. Eine womöglich mildere Prämie ist ein Bonus; der Betrug, der nie stattfindet, ist der Hauptgewinn.

Die Ökonomie bleibt im Übrigen weit über die Versicherung hinaus günstig. Die Kosten eines vollständigen DMARC-Programms — die detaillierte Aufschlüsselung steht in was ein DMARC-Dienst wirklich kostet — stehen in keinem Verhältnis zu einem einzigen erfolgreichen Überweisungsbetrug oder auch nur zur Selbstbehalt-Erhöhung nach einem Schadenfall. Dazu kommen die Nebeneffekte: bessere Zustellbarkeit, seit Gmail und Microsoft die Authentifizierung von Massenversendern verlangen, eine geschützte Marke und ein Seriositätssignal, lesbar für jeden Partner, der sich die Mühe macht, das DNS abzufragen.

Fazit

Überweisungsbetrug dominiert die Cyber-Schadenbilanz, E-Mail ist sein Vektor, und die Zeichnungsfragebögen haben die Konsequenz gezogen: Neben MFA, Backups und EDR ist die Domain-Authentifizierung — SPF, DKIM und vor allem die DMARC-Policy — zur Standardfrage geworden. p=reject verkleinert mechanisch einen Teil des versicherten Risikos, indem es die Fälschung der exakten Domain blockierbar macht; das öffentliche DNS erlaubt den Versicherern, Antworten ungefragt zu überprüfen; und das deklaratorische Prinzip macht jedes optimistisch angekreuzte Kästchen gefährlich. Ein gutes Dossier besteht aus drei Belegstücken — einem exakten Zustand, einer datierten Trajektorie, Betriebsnachweisen — und die Kontrolle schützt, einmal etabliert, weit über die Prämie hinaus.

Vor dem nächsten Fragebogen kostet der nützliche Reflex nichts: eine kostenlose DMARC-Analyse der Domain zeigt in Sekunden, was der Zeichner von der anderen Seite sehen wird — veröffentlichte Policy, SPF- und DKIM-Ausrichtung, verbleibende Schwachstellen. Und um diese Momentaufnahme in eine dokumentierte Trajektorie Richtung p=reject zu verwandeln, Berichte inklusive, erlaubt ein Konto, jeden Schritt zu datieren — bis zu dem Kästchen, das niemand mehr zögern wird anzukreuzen.