Die Domain wird gefälscht: Incident Response Schritt für Schritt

Von Thomas · virtueller CISO · 24. August 2026

Ein Vorfall beginnt fast nie mit einem sauberen Alarm. Er beginnt mit einem Bündel von Indizien: ein Kunde leitet eine „merkwürdige" Nachricht weiter, die den Namen des Unternehmens trägt, ein Partner ruft an, um eine Rechnung zu verifizieren, ein Support-Postfach füllt sich mit Meldungen. Währenddessen verschickt irgendwo eine Versandinfrastruktur betrügerische Post mit der Adresse der Domain im Absenderfeld. Die Suche „meine Domain wird gefälscht, was tun" wird dann in Eile getippt — und Eile ist ein schlechter Ratgeber, wenn noch keine Prozedur existiert.

Die gute Nachricht: Eine Domain-Fälschung lässt sich mit einer bekannten Methode behandeln, in geordneten Schritten — erkennen, qualifizieren, vermessen, behandeln, kommunizieren, abschließen. Die weniger gute: Solange die DMARC-Policy der Domain auf p=none steht, hält nichts die betrügerischen Nachrichten bei den Empfängern auf, und jede Stunde zählt. Der Vorfall ist schmerzhaft, aber er hat eine Tugend: Er verwandelt ein seit Monaten aufgeschobenes Projekt in eine offensichtliche, budgetierte und terminierte Priorität.

Dieser Leitfaden geht die Incident Response Schritt für Schritt durch, vom ersten Signal bis zum Ausstieg aus der Krise. Er gehört zum Gesamtansatz, der in E-Mail-Spoofing verhindern beschrieben ist: Hier hat die Prävention versagt oder existierte noch nicht, und es geht darum, die Kontrolle zurückzugewinnen.

Den Vorfall erkennen: drei Signale, die zusammenlaufen

Drei Familien von Signalen verraten eine laufende Fälschungskampagne; ihr Zusammentreffen kommt einer Bestätigung gleich.

Zuerst die Beschwerden von Empfängern. Kunden, Partner, manchmal völlig Unbekannte melden eine verdächtige Nachricht, die die Adresse der Domain als Absender trägt: eine ungewöhnliche Zahlungsaufforderung, ein Link zur „Kontoaktualisierung", ein unerwarteter Anhang. Diese Meldungen landen beim Support, im abuse@-Postfach oder am Telefon, und sie sind immer nur die sichtbare Spitze: Auf einen Empfänger, der sich die Mühe macht zu warnen, kommen Dutzende andere, die dieselbe Nachricht erhalten und geschwiegen haben — und einige haben geklickt.

Dann die aggregierten Berichte (RUA). Das ist das verlässlichste Signal. Eine direkte Fälschungskampagne liest sich in den Berichten als Explosion des DMARC-Fehlvolumens von unbekannten IP-Adressen — oft ganze Bereiche, Hoster ohne jede Verbindung zum legitimen Versand-Ökosystem, ungewöhnliche Geografien. Die Methode, dieses Signal zu lesen, wird in Spoofing in DMARC-Berichten erkennen ausgeführt. Eine Grenze, die bekannt sein muss: Die meisten Anbieter versenden ihre Berichte im 24-Stunden-Takt. Die Berichte bestätigen und vermessen, aber sie warnen nicht auf die Minute.

Schließlich die massenhaften NDR-Rückläufer. Fälscht der Angreifer auch die Envelope-Adresse, kommen die Unzustellbarkeitsmeldungen der abgewiesenen Nachrichten zur gefälschten Domain zurück: Hunderte Bounces für Nachrichten, die nie versendet wurden. Dieser Backscatter verstopft die legitimen Postfächer, hat aber einen Vorzug: Jeder NDR enthält oft ein Exemplar der betrügerischen Nachricht — fertig gesammeltes Beweismaterial.

Qualifizieren: direkte Fälschung oder Cousin-Domain

Vor jeder Behandlung ändert eine Unterscheidung alles: Welcher exakte Name steht im From:-Feld der betrügerischen Nachrichten?

Die direkte Fälschung zeigt exakt die legitime Domain — rechnung@beispiel.de. Das ist das Szenario, das DMARC blockieren kann: Bei allen Empfängern, die die Policy auswerten — und die großen Anbieter, Gmail, Yahoo, Microsoft, tun es —, lässt eine p=reject-Policy mit ausgerichtetem SPF oder DKIM diese Nachrichten an der Tür abweisen. Ist der Vorfall von diesem Typ, gilt der Rest dieses Leitfadens vollständig, und der Ausstieg aus der Krise führt über die Verschärfung der Policy.

Die Cousin-Domain (Typosquatting) zeigt einen ähnlichen, aber anderen Namen: beispie1.de, beispiel-zahlungen.de, beispiel.co. Der DMARC-Eintrag der echten Domain wird dann nie konsultiert — der Empfänger wertet die Policy der angezeigten Domain aus, also die des Angreifers, der auf seinem eigenen Namen sogar völlig gültiges SPF, DKIM und DMARC vorweisen kann. Die Behandlung ist eine ganz andere: Takedown-Antrag beim Registrar und beim Hoster der betrügerischen Domain, Meldung an Blocklisten und Browser-Schutzprogramme, UDRP-Verfahren bei eingetragener Marke, Strafanzeige. CEO-Betrug bevorzugt dieses Register, gerade weil es DMARC umgeht.

Die Qualifizierung erfolgt anhand von Belegen: Der vollständige Header einer betrügerischen Nachricht zeigt das exakte From:, die Envelope-Adresse (Return-Path) und das vom Empfänger festgehaltene Authentication-Results-Urteil. Beide Szenarien können übrigens in derselben Kampagne nebeneinander bestehen — dann wird die Qualifizierung Nachricht für Nachricht wiederholt.

Die ersten Stunden: Beweise sichern, Ausmaß vermessen

Die Versuchung der ersten Stunden ist, sofort am DNS zu handeln. Die richtige Reihenfolge ist die umgekehrte: zuerst die Beweise einfrieren und Maß nehmen, dann behandeln — einige Stunden Sammelarbeit verschlimmern den Vorfall nicht, aber verlorene Beweise lassen sich nicht wiederherstellen.

Die Beweise. Was zählt, sind vollständige Exemplare der betrügerischen Nachrichten, Header eingeschlossen — keine Screenshots. Der nützliche Reflex: Empfänger, die sich beschweren, um eine Rücksendung der Nachricht als Anhang (.eml-Format) bitten, denn eine einfache Weiterleitung zerstört die Original-Header. Aus jedem Exemplar werden drei Elemente gezogen: die Received-Kette (der reale Weg der Nachricht), das Feld Authentication-Results (die SPF-, DKIM- und DMARC-Urteile des Empfängers) und die URLs oder Anhänge im Inhalt, die später die Takedown- und Abuse-Meldungen speisen. Die aggregierten Berichte des Zeitraums werden ebenfalls aufbewahrt, dazu ein zeitgestempeltes Vorfallsprotokoll: wer was wann gesehen hat und was entschieden wurde.

Das Ausmaß. Beschwerden erzählen Anekdoten; die aggregierten Berichte liefern die einzige Gesamtsicht. Die Berichte beantworten die Fragen, die die Antwort strukturieren: Seit wann läuft die Kampagne? Von welchen IP-Adressen, in welchem Volumen, in Richtung welcher Empfangsanbieter? Zielt sie auf die Hauptdomain oder auf eine Subdomain? Ein Ausschlag von zehn fehlgeschlagenen Nachrichten verlangt nicht dieselbe Antwort wie eine Welle von hunderttausend. Diese Messung kalibriert alles Weitere — die Kommunikation eingeschlossen.

Die Behandlung: der Vorfall ist das Argument für die Durchsetzung

Bei direkter Fälschung passt die inhaltliche Behandlung in einen Satz: die DMARC-Policy der Domain auf Durchsetzung bringen. Eine Domain auf p=none beobachtet und blockiert nichts; die betrügerischen Nachrichten landen weiter in den Postfächern. Lebte die Organisation mit einem Projekt „irgendwann p=reject" ohne Datum, hat der Vorfall soeben das Datum geliefert.

Beschleunigung entbindet nicht von der Methode. Vor der Verschärfung müssen die aggregierten Berichte bestätigen, dass die legitimen Quellen — Marketingplattform, Rechnungssystem, Unternehmenspost — SPF oder DKIM mit Ausrichtung bestehen: Blind zu verschärfen würde mitten in der Krise legitime Post blockieren, zum denkbar schlechtesten Zeitpunkt. Unter Vorfallsbedingungen komprimiert sich aber der Kalender: rasch auf p=quarantine wechseln, damit der betrügerische Fluss in den Spam wandert, dann auf p=reject, sobald die Berichte bestätigen, dass die echten Quellen halten. Der aktuelle Standard (DMARCbis) liefert die Werkzeuge dieser Progression: den Testmodus t=y, um eine Policy im Einfahrbetrieb zu kennzeichnen, das Tag sp= zur Abdeckung der Subdomains und np=, um nicht existierende Subdomains von vornherein zu schließen — ein häufiges Ziel von Angreifern. Die vollständige Methode, außerhalb des Notfalls, wird in p=reject erreichen, ohne E-Mails zu verlieren durchgespielt.

Eine Ehrlichkeit ist geboten: DMARC blockiert nur die direkte Fälschung, und nur bei Empfängern, die es auswerten — fast alle großen Endkundenanbieter, nur ein Teil der Unternehmens-Mailserver. Und stand die Domain zum Zeitpunkt der Kampagne bereits auf p=reject, ändert sich die Diagnose: Entweder läuft die Kampagne über eine Cousin-Domain (zurück zur Qualifizierung), oder eine betrügerische Nachricht, die DKIM besteht, offenbart eine Schlüsselkompromittierung — das Thema der Geheimnishygiene weiter unten.

Kommunizieren: intern, an Kunden, an die Bank, an die Behörden

Eine Fälschungskampagne greift das Vertrauen mehr an als die Infrastruktur; die Kommunikation gehört deshalb zur Behandlung, abgestuft nach Schweregrad.

Zuerst intern. Support und Empfang brauchen ein Briefing, bevor die Anrufe eintreffen: eine sachliche Standardantwort, die die laufende Kampagne anerkennt und erklärt, woran sich authentische Nachrichten erkennen lassen. Die Geschäftsführung wird früh informiert — besonders, wenn Zahlungen im Spiel sind.

Dann Kunden und Partner, falls die Kampagne auf sie zielt. Die Warnung geht nach Möglichkeit über einen anderen Kanal als den gefälschten hinaus, ohne klickbare Links (eine mit Links gespickte Warnung sieht selbst wie Phishing aus), und trägt zwei einfache Botschaften: Das Unternehmen fordert diese Art von Handlung nie per E-Mail an, und jede zweifelhafte Nachricht lässt sich über einen bekannten Kanal verifizieren.

Die Bank, ohne Verzug, wenn die Kampagne Überweisungen oder Rechnungen betrifft — das klassische Szenario des CEO-Betrugs und der gefälschten Bankverbindung. Hat eine getäuschte Gegenseite bereits eine betrügerische Zahlung angestoßen, zählt jede Stunde für einen Rückrufversuch.

Behörden und Justiz, je nach Schweregrad. Eine generische Phishing-Welle wird gemeldet (in Deutschland etwa über die Online-Wachen der Polizei; für Unternehmen ist auch das BSI ein Anlaufpunkt); ein finanzieller Schaden oder ein massiver Angriff auf die Marke rechtfertigt eine Strafanzeige, die das oben zusammengestellte Beweisdossier belastbar macht. Ein oft missverstandener DSGVO-Punkt: Die Fälschung der Domain ist für sich genommen keine Verletzung des Schutzes personenbezogener Daten der gefälschten Organisation — die 72-Stunden-Meldung an die Datenschutzbehörde greift nur, wenn der Vorfall eine interne Kompromittierung offenbart (gekapertes Postfach, exfiltrierte Kontaktdatenbank).

Geheimnishygiene nach dem Vorfall

Eine technische Frage entscheidet über diesen Schritt: Bestanden die betrügerischen Nachrichten DKIM mit einem legitimen Selektor der Domain? Wenn ja, geht die Sache über Spoofing hinaus — ein privater Schlüssel ist geleakt, oder ein zum Signieren berechtigtes System ist kompromittiert. Die Notfallrotation ist zwingend: neuer Schlüssel unter neuem Selektor, Umstellung der Signatur, dann Widerruf des alten Selektors durch Veröffentlichung eines leeren p=-Eintrags, der jede Signatur ungültig macht, die sich noch auf ihn beruft.

Auch ohne Beweis eines Lecks rechtfertigt ein ernster Vorfall eine Revision der Geheimnisse, die die Versandidentität regieren: private DKIM-Schlüssel, die Zugangsdaten des DNS-Kontos (mit denen sich SPF, DKIM und DMARC veröffentlichen oder sabotieren lassen), die API-Token der Versandplattformen, SMTP-Passwörter. Ein kompromittierter DNS-Zugang ist das gravierendste Szenario — der Angreifer veröffentlicht dort eigene Einträge und signiert „legitim". Besteht der Verdacht einer internen Kompromittierung, rotieren alle diese Geheimnisse, beginnend mit denen, deren Nutzung die Berichte nahelegen.

DMARC.com wird von Hucency herausgegeben, einem Spezialisten für Cybersicherheit; um diese Art von Geheimnissen — private DKIM-Schlüssel, DNS-Zugangsdaten, API-Token — zu zentralisieren und ihre Rotation nach einem Vorfall zu orchestrieren, gibt es Hucency Vault. Eine Incident Response ohne Tresor endet zu oft mit neu erzeugten Schlüsseln… abgelegt an genau dem Ort, aus dem die alten geleakt sind.

Der Abschluss des Vorfalls: Überwachung, Post-mortem, Trajektorie

Ein Vorfall endet nicht, wenn die Beschwerden aufhören; er endet, wenn drei Dinge stehen.

Die verstärkte Überwachung. Kampagnen kommen wieder — gleiche Infrastruktur, neuer Vorwand. Über mehrere Wochen werden die aggregierten Berichte in engerem Takt gelesen, mit einem Alarm auf jede neue unbekannte Quelle. Der Rückgang des DMARC-Fehlvolumens nach dem Wechsel zur Durchsetzung ist zugleich die Erfolgsmetrik: Er dokumentiert mit Zahlen, dass die Behandlung gewirkt hat.

Das Post-mortem. Eine Seite genügt: Chronologie, Vektor, gemessenes Ausmaß, was funktioniert hat, was gefehlt hat. In den meisten Fällen passt das Fazit in eine Zeile — die Domain stand jahrelang auf p=none, und der Vorfall hat nur eine bekannte, offen gelassene Tür ausgenutzt. Diese Feststellung, datiert und geteilt, verhindert die Rückkehr zum Status quo, sobald die Aufregung abklingt.

Die Trajektorie. Die in der Krise verschärfte Policy wird zum Dauerzustand: p=reject auf der Domain, Subdomains abgedeckt, ruhende Domains verriegelt. Bleibt, regelmäßig zu prüfen, dass der Schutz hält — der in testen, ob eine Domain fälschbar ist beschriebene Ansatz macht aus dieser Kontrolle eine Routine, ebenso wie die periodische Durchsicht neu registrierter Cousin-Domains rund um die Marke.

Fazit

Eine Domain-Fälschung erkennt sich am Zusammentreffen dreier Signale — Beschwerden von Empfängern, explodierende DMARC-Fehlschläge in den aggregierten Berichten, massenhafte NDR-Rückläufer. Die Qualifizierung entscheidet alles: Die direkte Fälschung wird mit DMARC behandelt, die Cousin-Domain mit Takedown und Anzeige. Die ersten Stunden dienen dazu, die Beweise einzufrieren (vollständige .eml-Nachrichten, Header, Berichte) und das Ausmaß zu vermessen; die inhaltliche Behandlung besteht darin, die Durchsetzung zu beschleunigen — p=quarantine, dann p=reject —, gestützt auf die Berichte, damit nichts Legitimes bricht. Die Kommunikation staffelt sich vom internen Briefing bis zur Strafanzeige, die Rotation der DKIM-Schlüssel und DNS-Zugangsdaten ist beim geringsten Kompromittierungsverdacht Pflicht, und der Abschluss verbindet verstärkte Überwachung, ein schriftliches Post-mortem und eine dauerhaft verschärfte Policy.

Der erste Reflex, noch vor der ersten Beschwerde, dauert wenige Minuten: eine kostenlose DMARC-Analyse zeigt, ob die Domain die direkte Fälschung wirklich blockiert oder nur so aussieht. Und um die aggregierten Berichte zu verfolgen, die nächste Kampagne früh zu erkennen und die Trajektorie zu p=reject zu steuern, richtet ein Konto genau die Überwachung ein, die im Moment des Vorfalls gefehlt hat.