Spoofing in DMARC-Berichten erkennen: die Methode

Von Thomas · virtueller CISO · 26. August 2026

Eine Domain-Fälschung kündigt sich bei ihrem Ziel nicht an. Der Betrüger, der Phishing im Namen von beispiel.de versendet, schreibt nicht an die Organisation, der die Domain gehört: Die Nachrichten gehen an deren Kunden, Lieferanten und Beschäftigte. Lange Zeit war die erste Warnung die Beschwerde eines Opfers — eine abgeflossene Überweisung, ein auf einer gefälschten Seite eingetipptes Passwort. DMARC hat diese Grenze verschoben: Jeder große Postfachanbieter, der eine Nachricht mit Absenderangabe der Domain empfängt, hält sein Urteil in einem aggregierten Bericht (RUA) fest, der an den Domain-Inhaber geht. Die Fälschung hinterlässt damit eine Spur genau dort, wo sie zielt. Bleibt die Frage, wie sich diese Spur lesen lässt.

Denn ein RUA-Bericht ruft nie „Angriff". Er reiht IP-Adressen, Zähler und SPF/DKIM-Urteile aneinander, ohne jemanden zu beschuldigen. Hinter derselben fehlgeschlagenen Zeile kann ein falsch konfigurierter Versanddienstleister stecken, eine völlig harmlose automatische Weiterleitung oder ein Botnetz mitten in einer Kampagne. Die ganze Kunst der Erkennung liegt in dieser Sortierung, und die Sortierung ist eine erlernbare Methode: die drei Populationen trennen, die in den Berichten nebeneinander existieren, die Signatur einer echten Kampagne erkennen, die bekannten Fehlalarme aussieben und schließlich den Moment bestimmen, in dem die Routinelektüre in Incident-Response umschlagen muss. Genau diesem Ablauf folgt dieser Artikel.

Was ein Bericht zeigt, wenn die Domain gefälscht wird

Der vollständige Aufbau eines aggregierten Berichts ist in dem Leitfaden zu aggregierten DMARC-Berichten beschrieben; für die Erkennung tragen drei Spalten fast das gesamte Signal: die Quell-IP, das Volumen und das Paar der SPF/DKIM-Urteile, wie der Empfänger sie bewertet hat. Ein typischer Fälschungsversuch erzeugt eine sofort wiedererkennbare Zeile:

<record>
  <row>
    <source_ip>203.0.113.47</source_ip>
    <count>612</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>beispiel.de</header_from>
  </identifiers>
</record>

Drei Signale wirken zusammen. Zuerst der doppelte Fehlschlag: Weder SPF noch DKIM bestehen im Alignment mit beispiel.de. Ein legitimer Server der Organisation scheitert selten an beiden Fronten gleichzeitig; ein Fälscher fast immer — er besitzt weder die DKIM-Schlüssel der Domain noch eine Adresse, die deren SPF-Eintrag autorisiert. Der Block auth_results macht es endgültig deutlich: Es ist nicht einmal eine DKIM-Signatur der Domain vorhanden, und SPF wurde gegen eine Envelope-Domain geprüft, die mit der Marke nichts zu tun hat.

Dann das Volumen und sein Profil. Legitime Flüsse atmen in erkennbaren Mustern: Der Newsletter geht dienstags raus, die Rechnungsstellung fällt aufs Monatsende, der transaktionale Versand folgt dem Geschäft. Eine unbekannte IP, die an einem einzigen Tag mit 600 Nachrichten auftaucht, während die Domain an guten Tagen 200 versendet, ähnelt keinem bestehenden Fluss — und dieser Kontrast zählt mehr als die absolute Zahl.

Schließlich die Geografie. Die Anreicherung der Quell-IP erzählt eine Herkunft: Netzbetreiber, Land, Netzwerktyp. Eine Domain, deren gesamte Versandinfrastruktur zwischen zwei europäischen Hostern und Microsoft 365 Platz findet, hat keinen Grund, plötzlich aus privaten Adressbereichen auf drei Kontinenten zu senden. Keines dieser Signale reicht für sich allein; ihr Zusammentreffen schon.

Drei Populationen, drei Behandlungen

Jeder Bericht mischt drei Familien von Quellen, und der erste Schritt der Triage besteht darin, sie Zeile für Zeile zu trennen.

Die legitimen, ausgerichteten Quellen. Die eigenen Server der Organisation und die korrekt konfigurierten Dienstleister: SPF oder DKIM besteht, im Alignment mit der Domain. Das ist das Rückgrat des Verkehrs — in der Regel die erdrückende Mehrheit des Volumens. Die einzige Aufgabe: Woche für Woche prüfen, dass es stabil bleibt.

Die legitimen, aber falsch konfigurierten Quellen. Eine sehr reale E-Mail-Plattform — Brevo, Mailchimp, SendGrid, ein CRM —, die gewollte Post versendet, aber ohne Alignment: SPF besteht auf der eigenen Envelope-Domain des Dienstleisters, DKIM signiert mit dessen Domain statt mit der der Marke. Das DMARC-Urteil ist ein Fehlschlag, doch alles andere atmet Legitimität: regelmäßiges Volumen, Bürozeiten, identifizierbare Infrastruktur, kontinuierliche Präsenz Woche für Woche. Das sind Konfigurationsbaustellen, keine Bedrohungen.

Die Fälscher. Unbekannte IPs, doppelter Fehlschlag, keinerlei DKIM-Signatur, erratisches Volumenprofil. Der Unterschied in der Behandlung ist grundlegend: Eine falsch konfigurierte Quelle lässt sich reparieren, ein Fälscher lässt sich nicht „reparieren". Keine Maßnahme wird ihn aus den Berichten verschwinden lassen — die einzige Antwort ist eine Policy, die seine Sendungen beim Empfänger scheitern lässt.

Die Verwechslung der Populationen zwei und drei ist der teuerste Lesefehler überhaupt: Wer einen vergessenen Dienstleister für einen Angreifer hält, verschärft zu schnell und zerstört einen legitimen Fluss; wer einen Angreifer für einen Dienstleister hält, „wartet erst mal ab", während das Phishing zirkuliert.

Die Signaturen einer Fälschungskampagne

Jenseits der einzelnen Zeile zeichnen echte Kampagnen wiederkehrende Muster in die Berichte.

Die kurze Welle. Eine Phishing-Kampagne wird vorbereitet, abgefeuert und erlischt: Das Volumen springt binnen 24 bis 72 Stunden von null auf Hunderte oder Tausende Nachrichten und fällt danach auf null zurück. Legitime Flüsse dagegen bleiben. Eine Quelle, die am Montag auftaucht und am Donnerstag verschwindet, kommt nicht zurück, um sich zu erklären.

Private IPs und Botnetze. Statt einer großen Sendeadresse Dutzende oder Hunderte IPs, von denen jede nur eine Handvoll Nachrichten verschickt, oft aus Adressbereichen von Endkunden-Providern, geografisch verstreut. Diese Zersplitterung ist für sich genommen eine Signatur: Keine legitime Versandinfrastruktur sieht aus wie ein Schwarm.

Empfänger, konzentriert bei einem einzigen Anbieter. RUA-Berichte stammen von den Postfachanbietern der Empfänger. Taucht eine Kampagne nur in den Berichten eines einzigen Melders auf — etwa ausschließlich Google —, spiegelt das eine gekaufte oder gestohlene Adressliste wider, die sich bei diesem Anbieter konzentriert. Legitimer Verkehr verteilt sich dagegen über alle üblichen Melder.

Unplausible Ziele. Sendungen im Namen von Subdomains, die es gar nicht gibt — ein nie angelegtes rechnung.beispiel.de —, verraten einen Angreifer, der den Perimeter abtastet. DMARCbis hat genau dafür das Tag np= eingeführt, um nicht existierende Subdomains härter zu behandeln, ohne den Rest der Policy anzufassen.

Die Fehlalarme, die wie ein Angriff aussehen

Drei völlig legitime Mechanismen erzeugen DMARC-Fehlschläge, und sie mit einer Fälschung zu verwechseln kostet Zeit — oder löst einen Fehlalarm aus.

Weiterleitungen. Ein Empfänger, der seine Post an ein anderes Postfach weiterleitet, versendet die Nachricht erneut von einer neuen IP: SPF scheitert mechanisch. Wurde die Nachricht unterwegs aber nicht verändert, überlebt DKIM den Sprung. Eine ausgerichtete Zeile spf=fail, dkim=pass ist also keine Fälschung, sondern die klassische Signatur einer Weiterleitung.

Mailinglisten. Diese verändern die Nachricht — ein Etikett im Betreff, eine angehängte Fußzeile — und brechen damit zusätzlich zu SPF auch DKIM. Das Ergebnis ist ein doppelter Fehlschlag, der einem Angriff zum Verwechseln ähnlich sieht. Die rettenden Indizien: geringes, stabiles Volumen, eine konstante IP eines identifizierbaren Listenbetreibers, Wiederkehr Woche für Woche — das genaue Gegenteil einer Welle. Manche Empfänger gleichen über ARC aus und stellen trotzdem zu; das Feld reason des Berichts hält diese Entscheidung dann fest.

Sicherheits-Gateways und Scanner. Bei manchen empfangenden Organisationen zünden Analysegeräte die Anhänge und speisen die Nachricht intern neu ein: Diese verlässt dann eine Gateway-IP, SPF scheitert, manchmal auch DKIM, wenn der Inhalt neu verarbeitet wurde. Solche Quellen verraten sich durch ihre Regelmäßigkeit und ein Volumen, das dem tatsächlich an diese Organisation gesendeten Verkehr entspricht.

Das Mehrdeutige entscheiden. Für die Restfälle wäre die nächsthöhere Detailstufe der forensische Bericht, Nachricht für Nachricht — doch die großen Anbieter versenden ihn kaum noch; der Unterschied zwischen aggregierten und forensischen Berichten erklärt, warum die Erkennung in der Praxis auf dem RUA allein ruht.

Die wöchentliche Triage-Methode

Erkennung verlangt keinen Krisenstab; sie verlangt eine Routine. Dreißig Minuten pro Woche genügen für eine etablierte Domain, in fünf immer gleichen Durchgängen.

Zuerst die Alignment-Quote. Der Anteil des ausgerichteten Volumens am Gesamtvolumen, verglichen mit der Vorwoche. Stabil oder steigend: nichts Dringendes. Fallend: Etwas hat sich geändert, und der Rest der Triage sagt, was.
Dann die neuen Quellen. Jede seit der letzten Lektüre aufgetauchte IP wird einer der drei Populationen zugeordnet. Ein bekannter Dienstleister, ein Unternehmensbereich, ein völliger Unbekannter: drei verschiedene Schicksale.
Die doppelten Fehlschläge im Detail. Für jede fail/fail-Zeile: Volumen, Zeitprofil, Netzwerkherkunft, Liste der Melder. Welle plus verstreute IPs plus ein einziger Melder: Das Indizienbündel einer Kampagne ist beisammen.
Die Etikettierung. Jede Quelle erhält einen Status — legitim, zu korrigieren, feindlich, unbestimmt —, der von Woche zu Woche fortgeschrieben wird. Dieses Gedächtnis macht die Routine schnell: Nur das Neue verlangt eine Analyse, der Rest ist bereits beurteilt.
Die Entscheidung. Eine zu korrigierende Quelle wandert in den Konfigurations-Backlog; eine unter p=none beobachtete feindliche Kampagne wird zum datierten, bezifferten Argument, die Verschärfung zu beschleunigen.

Von Hand, auf komprimierten XML-Dateien, wird diese Routine schon in der zweiten Woche zur Qual. Werkzeuge zum Lesen der Berichte automatisieren das Wesentliche — IP-Anreicherung, dauerhafte Etikettierung, Alarm bei neuen Quellen — und reduzieren den Wochentermin auf die Prüfung der reinen Anomalien.

Was die Policy an der Lektüre ändert

Dieselbe Berichtszeile erzählt nicht unter jeder veröffentlichten Policy dieselbe Geschichte.

Unter p=none bleibt die Disposition none: Jede im Bericht gezählte gefälschte Nachricht wurde zugestellt, vorbehaltlich der gewöhnlichen Spam-Filterung des Empfängers. Die Lektüre ist Beobachtung im strengen Sinn: Feindliche Zeilen beschreiben Phishing, das im Postfach angekommen ist. Das ist die unbequemste Phase — die, in der die Berichte die Exposition dokumentieren, ohne sie zu verringern —, und jede erkannte Kampagne ist ein datierter Grund, aus dieser Phase auszusteigen.

Unter p=quarantine und dann p=reject ändern dieselben Zeilen ihre Natur: disposition=quarantine oder reject bedeutet, dass die Nachrichten aussortiert oder abgewiesen wurden. Fehlschläge werden zu Blockaden; der Bericht wird zur Erfolgsbilanz. Das abgewiesene feindliche Volumen liest sich als Schutzmetrik: Jede Welle ist eine abgebrochene Kampagne, ohne Opfer auf Empfängerseite. Eine Nuance: Eine Zeile disposition=none kann auch unter p=reject fortbestehen, wenn der Empfänger die Policy lokal übersteuert hat — eine über ARC rehabilitierte Mailingliste, eine interne Regel —, und das Feld reason dokumentiert diese Wahl.

Eine Versionsnotiz: Der schrittweise Rollout läuft nicht mehr über das alte Tag pct, das aus DMARCbis verschwunden ist; der Testmodus wird jetzt mit dem Tag t= ausgedrückt, und die Bestimmung der Organisationsdomain beruht auf dem DNS Tree Walk. Bestehende v=DMARC1-Einträge bleiben unverändert gültig.

Wann in die Incident-Response eskaliert wird

Die wöchentliche Routine genügt, solange die Fälschung Hintergrundrauschen bleibt — ein paar opportunistische Versuche pro Monat gehören zum normalen Leben jeder sichtbaren Domain. Drei Schwellen rechtfertigen den Ausstieg aus der Routine.

Das Volumen. Eine Kampagne, die den legitimen Verkehr der Domain übersteigt oder sich über mehrere Tage hält, statt abzuebben, ist kein Rauschen mehr: Es ist eine Investition des Angreifers, also gezieltes Vorgehen.

Das Targeting. Berichte, die sich ausgerechnet bei dem Anbieter konzentrieren, der die eigenen Kunden oder Partner der Organisation beherbergt, oder eine Korrelation mit eingehenden Signalen — Antworten von Opfern, Anrufe beim Support, interne Warnungen — zeigen, dass die Kampagne das reale Ökosystem trifft, nicht zufällige Adressen.

Der Kontext. Eine Welle, die mit einem Ereignis der Organisation zusammenfällt — ein Rechnungslauf, eine Einstellungskampagne, eine öffentliche Ankündigung —, verrät Vorbereitung, und Vorbereitung kündigt eine Fortsetzung an.

In diesen drei Fällen reicht das Lesen nicht mehr: Der Verschärfungsfahrplan muss beschleunigt, die Berichte müssen als Beweismittel gesichert und die exponierten Beteiligten informiert werden. Das vollständige Vorgehen — Qualifizierung, Kommunikation, Notfall-Durchsetzung — behandelt die Incident-Response nach einer Domain-Fälschung. Und der beste Zeitpunkt für die Frage bleibt die Zeit vor der Kampagne: der Test, ob eine Domain fälschbar ist, sagt in wenigen Minuten, was die Berichte erst über Wochen beweisen würden.

Fazit

Ein RUA-Bericht macht die Fälschung sichtbar, sofern sortiert wird. Legitime ausgerichtete Quellen werden überwacht; legitime falsch konfigurierte werden repariert; Fälscher — unbekannte IPs im doppelten SPF- und DKIM-Fehlschlag, ohne jede Signatur der Domain — lassen sich nur durch die Policy neutralisieren. Eine echte Kampagne verrät sich durch ihre kurze Welle, ihre verstreuten oder privaten IPs und ihre bei einem einzigen Anbieter konzentrierten Berichte; Weiterleitungen, Mailinglisten und Sicherheits-Gateways erzeugen vergleichbare Fehlschläge, ohne Angriffe zu sein. Die wöchentliche Routine — Alignment, neue Quellen, doppelte Fehlschläge, Etikettierung, Entscheidung — macht aus dieser Lektüre einen Reflex, und die veröffentlichte Policy entscheidet über die Bedeutung der Zeilen: Beobachtung unter p=none, Blockade unter p=reject. Jenseits eines bestimmten Volumens, eines belegten Targetings oder einer verdächtigen Synchronisierung weicht die Erkennung der Incident-Response.

Die erste Triage kann heute beginnen: Ein Durchlauf der Domain durch die kostenlose DMARC-Analyse zeigt sofort, wer unter ihrem Namen versendet und auf welcher Authentifizierungsgrundlage. Um die Routine auf Dauer zu verankern — Sammlung der Berichte, Anreicherung der Quellen, Alarm bei Wellen —, stellt die Erstellung eines Kontos die hier beschriebene Methode auf Dauerbetrieb, bis zu dem Tag, an dem sich jede feindliche Zeile als Blockade liest und nicht mehr als Bedrohung.