DKIM-Replay: wenn eine gültige Signatur Spam befördert

Von Thomas · virtueller CISO · 25. August 2026

Das Versprechen von DKIM passt in einen Satz: Eine kryptografische Signatur bezeugt, dass eine Nachricht nicht verändert wurde und tatsächlich von der signierenden Domain stammt. Das stimmt, doch die Reichweite ist enger, als es scheint. Die Signatur garantiert, dass der signierte Teil sich nicht geändert hat — sie sagt nichts darüber, wer die Nachricht erneut versendet, wie oft oder an wen. Eine einmal von einer renommierten Domain signierte Nachricht bleibt unbegrenzt überprüfbar, solange nichts Signiertes sich bewegt. Genau diese Eigenschaft, wertvoll, um Transit und legitime Weiterleitungen zu überstehen, wendet der Replay-Angriff gegen ihren Besitzer.

Das Szenario ist einfach zu beschreiben. Ein Angreifer beschafft sich eine echt signierte Nachricht eines großen Versenders — meist, indem ein Testkonto bei einem Mailanbieter oder einer E-Mail-Plattform eröffnet und sich selbst eine Nachricht geschickt wird, deren Body die Nutzlast trägt (ein Phishing-Link, ein Überweisungsbetrug). Der Anbieter signiert diese Nachricht per DKIM: In seinen Augen ist sie vollkommen legitim. Der Angreifer greift dann die signierte Kopie unverändert ab und schleust sie unverändert an Zehntausende weitere Adressen ein, von der eigenen Infrastruktur aus. Die Signatur hält bei jedem Empfänger, und die gute Reputation der signierenden Domain trägt den Spam durch.

Was das Verfahren heimtückisch macht: Keine Prüfung auf DMARC-Ebene erfasst es, weil alles, was der Standard verifiziert, technisch korrekt ist. Replay zu verstehen beginnt damit, das, was DKIM tatsächlich garantiert, von dem zu trennen, was ihm zugeschrieben wird. Es folgen der Mechanismus, der Angriffswinkel nicht signierter Header, die Gegenmaßnahmen — die vor allem beim Signierenden liegen — und die tatsächliche Verteilung des Risikos zwischen Großversendern und KMU-Domains.

Das Prinzip des Replays: eine Signatur, die reist

DKIM signiert zwei Dinge: einen Hash des Nachrichten-Bodys (das bh=-Tag) und einen Hash einer ausgewählten Liste von Headern (das h=-Tag). Solange beide Hashes sich identisch neu berechnen lassen und der öffentliche Schlüssel im DNS veröffentlicht bleibt, ist die Signatur gültig — unabhängig vom zurückgelegten Weg, der Zahl der Kopien oder dem Zeitpunkt. Das ist gewollt: Eine Signatur muss Relays und Weiterleitungen überstehen. Doch nichts in der Spezifikation bindet eine Signatur an einen einzigen Versand, an eine Empfängerliste oder standardmäßig an ein striktes Zeitfenster.

Genau dort setzt Replay an. Ist die signierte Nachricht einmal abgegriffen, muss sie nur noch unverändert weiterverteilt werden. An jedem Ziel berechnet die Prüfung die Hashes neu: Der Body hat sich nicht geändert, die signierten Header ebenso wenig, der Schlüssel der Versanddomain antwortet weiterhin. Urteil: gültige Signatur. Und weil diese Signatur von einer Domain mit hoher Reputation stammt, erbt die Nachricht ein Vertrauen, das sie nie verdient hat. Spam zirkuliert unter geliehener Flagge, und die Kosten der Operation reduzieren sich für den Angreifer auf ein Testkonto und einen Versandserver.

Warum DMARC nichts sieht

DMARC beruht auf der Ausrichtung (Alignment): Die Domain, die eine gültige DKIM-Signatur erzeugt (oder SPF besteht), muss der im From-Header angezeigten Domain entsprechen. Bei einem klassischen Replay wurde die Nachricht von der renommierten Domain signiert, und ihr From zeigt dieselbe Domain — das Alignment ist also perfekt. DKIM besteht, das Alignment besteht, DMARC liefert ein pass. Nichts sticht heraus.

Das ist kein Fehler von DMARC, sondern eine direkte Folge seines Zuständigkeitsbereichs. DMARC beantwortet eine einzige Frage: „Hat die Domain im From diesen Versand autorisiert?" Im Replay-Fall lautet die ehrliche Antwort ja: Die Domain hat diese Nachricht einmal signiert. Was DMARC nicht fragt, ist: „Wurde diese Nachricht von einem Dritten an Empfänger wiederabgespielt, die der Absender nie anvisiert hat?" Kein Tag des Protokolls trägt diese Information — kein Zähler, keine eindeutige Nummer, keine erwartete Empfängerliste. Dafür war der Standard nie ausgelegt.

Eine Spur bleibt, doch nicht dort, wo sie erwartet würde. Die wiederabgespielte Nachricht zeigt die renommierte Domain, nicht die eines beliebigen kleinen Unternehmens: Es sind also die aggregierten Berichte der signierenden Domain, die das Signal tragen, in Form eines plötzlichen Volumens von Nachrichten, die DKIM bestehen und zugleich SPF scheitern lassen, ausgesandt von unbekannten Adressbereichen. Für die Domain, deren Identität als Vehikel dient, ist die Anomalie lesbar; für den Endempfänger ist sie es nicht.

Nicht signierte Header als Angriffsfläche

Das Basis-Replay versendet die Nachricht identisch weiter. Eine feinere Variante nutzt aus, was die Signatur nicht abdeckt. Das h=-Tag listet genau die signierten Header auf; jeder aus dieser Liste fehlende Header entgeht dem Schutz und lässt sich daher hinzufügen oder verändern, ohne die Signatur zu entwerten.

Die Folgen sind konkret. Fehlt Subject im h=, lässt sich die Betreffzeile beliebig umschreiben, um zu jeder Kampagne zu passen, ohne den Hash zu berühren. Ist To nicht signiert, lässt sich der angezeigte Empfänger fälschen. Noch hinterhältiger: das Einschleusen eines doppelten Headers. Viele Mailprogramme zeigen die erste — oder die letzte — Vorkommnis eines Headers an; hat der Signierende nur eine signiert, rutscht das Hinzufügen eines zweiten Subject oder eines zweiten From an der Prüfung vorbei und ändert zugleich, was der Mensch auf dem Bildschirm sieht. Die wiederabgespielte Nachricht personalisiert sich so für jedes Opfer, während die ursprüngliche Signatur technisch intakt bleibt: Sie erfasste stets nur das, was der Signierende einzuschließen bereit war.

Die Gegenmaßnahmen, vor allem aufseiten des Signierenden

Die Schwierigkeit liegt in einem Ungleichgewicht: Der Empfänger sieht nur eine gültige Signatur und verfügt über fast keinen Hebel. Die echten Gegenmaßnahmen liegen bei demjenigen, der signiert — einem Großversender, einem ESP, einem Mailanbieter.

Breit signieren. Die erste Verteidigung besteht darin, in h= jeden Header aufzunehmen, der Bedeutung trägt: From, To, Cc, Subject, Date, Message-ID, Reply-To, Content-Type und weitere. Je breiter die Abdeckung, desto weniger nicht signierte Fläche bleibt zur Manipulation. Ein auf das Nötigste reduziertes h=from lässt alles Übrige zur Verfälschung offen.
Der überdeklarierte Header (Oversigning). Die Technik besteht darin, einen Header öfter zu signieren, als er tatsächlich in der Nachricht vorkommt — etwa durch die Angabe h=from:from:to:to:subject:subject:…. Das Hinzufügen eines zusätzlichen Vorkommens eines dieser Header bricht dann die erwartete Zählung, und die Prüfung scheitert. Es ist der direkte Konter gegen das Einschleusen doppelter Header: Ein zweites Subject oder ein zweites From lässt sich nicht mehr hinzufügen, ohne die Signatur zu brechen.
Kurzlebige Schlüssel und regelmäßige Rotation. Eine wiederabgespielte Nachricht bleibt nur überprüfbar, solange der zugehörige öffentliche Schlüssel veröffentlicht ist. Schlüssel zu rotieren und alte Selektoren zurückzuziehen verkürzt das Fenster, in dem eine abgegriffene Signatur gültig bleibt — einer der Vorteile der Rotation der DKIM-Schlüssel. Die Grenze ist klar: Rotation stoppt kein sofortiges Replay, denn der Großteil des Schadens entsteht in den Stunden direkt nach dem Abgriff, lange vor jeder vernünftigen Rotation.
Das x=-Tag, mit seinen Grenzen. DKIM erlaubt es, das Ablaufdatum einer Signatur über das x=-Tag (einen Zeitstempel) festzulegen. Nach diesem Zeitpunkt darf ein Verifizierer die Signatur ablehnen. Theoretisch verkleinert ein kurzes Fenster die für Replay nutzbare Zeit. In der Praxis gelten drei Vorbehalte: Nicht jeder Verifizierer erzwingt x=; ein zu enges Fenster lässt legitime verzögerte Post scheitern (Warteschlangen, Weiterleitungen, Greylisting-Verzögerungen); und wenige Minuten genügen oft, um einen Massenversand zu starten. Das Tag verringert das Risiko, es beseitigt es nicht.
Auf anomale Spitzen achten. Aufseiten des Signierenden hinterlässt Replay die oben beschriebene Spur: einen Schwall von „Nur-DKIM"-Nachrichten aus Adressen, die dem üblichen Versandbestand fremd sind. Eine legitime Domain versendet aus einem stabilen Satz von IPs; eine Spitze, die davon abweicht, signalisiert ein laufendes Replay, und das regelmäßige Lesen der Berichte ist das einzige Mittel, es früh zu erkennen.

Ein Punkt verdient eine klare Aussage, weil er zu Verwechslungen einlädt: Den Schlüssel von 1024 auf 2048 Bit zu verlängern schützt gegen das Fälschen einer Signatur, nicht gegen Replay. Hier wird der Schlüssel nie gebrochen — eine echte Signatur wird schlicht wiederverwendet. Beide Bedrohungen zu verwechseln führt dazu, das falsche Schloss zu verstärken.

Was DMARCbis ändert (und was nicht)

DMARCbis, der aktuelle, in den RFC 9989, 9990 und 9991 beschriebene Standard, modernisiert mehrere Mechanismen: Die Public Suffix List weicht dem DNS Tree Walk, das pct-Tag verschwindet zugunsten eines von t= getragenen Testmodus, und neue Tags wie np oder psd verfeinern die Behandlung von Subdomains. Keine dieser Änderungen berührt Replay.

Der Grund ist strukturell: DMARCbis argumentiert weiterhin auf Alignment-Ebene und liefert weiterhin ein pass bei einer gültigen, ausgerichteten DKIM-Signatur. Replay operiert eine Schicht tiefer, in DKIM selbst, wo DMARCbis weder einen Zähler noch irgendeinen Begriff eines eindeutigen Empfängers hinzufügt. Der Umstieg auf den aktuellen Standard bleibt aus anderen Gründen lohnend, doch diese Tür schließt er nicht. Die IETF-Gemeinschaft arbeitet ihrerseits an Erweiterungen, die DKIM replay-resistent machen sollen — eine Signatur an einen Versand, ein Volumen oder eine Flugbahn zu binden —, doch diese Arbeit ist 2026 noch kein breit ausgerollter Standard. So wie es steht, bleibt die Verteidigung organisatorisch, nicht protokollarisch.

Wer wirklich betroffen ist

Replay zielt vor allem auf die Identitäten, die zu leihen sich lohnt. Großversender, E-Mail-Plattformen und Mailanbieter, die kostenlose oder Testkonten anbieten, bündeln das Problem: Ihre gute Reputation ist der begehrte Vermögenswert, und das Testkonto ist der Abgriffsvektor. Für sie ist der Einsatz operativ und dauerhaft — ihr Name dient als Vehikel für Spam, und ihre Zustellbarkeit leidet. Dort rechnen sich breites Signieren, Oversigning, die Erkennung von Testkonto-Missbrauch und die Ratenbegrenzung.

Die Domain eines KMU steht in einer anderen Lage. Ihre Reputation hat meist zu wenig Wert, um sie zu einem Replay-Ziel zu machen: Ein Angreifer gewinnt nichts, indem er unter dem Namen einer kleinen, unbekannten Domain versendet. Die kleine Domain ist also selten die Quelle eines Replays. Sie kann jedoch Empfänger sein — und dort filtert keine DMARC-Einstellung eine Nachricht, die legitim jede Prüfung besteht; nur die klassische Spam-Filterung bleibt im Spiel. Die nützliche Lehre für eine kleine Domain ist umfassender: sauber zu signieren und Schlüssel-Header überzudeklarieren bleibt eine kostengünstige Hygiene, und vor allem authentifiziert eine gültige Signatur eine Domain, nie eine Absicht. Es ist dasselbe Fundament, das dazu dient, Spoofing vorzubeugen: Authentifizierung beweist Herkunft, nicht Wohlwollen. Um konkret zu sehen, was eine Signatur abdeckt und was sie offenlässt, ist das Lesen einer DKIM-Signatur in einer empfangenen Nachricht die Grundübung.

Fazit

DKIM-Replay nutzt eine gewollte Eigenschaft des Protokolls aus: Eine gültige Signatur bleibt gültig, solange Body und signierte Header sich nicht ändern, ohne Bezug zum ursprünglichen Versand oder zur Empfängerliste. Eine einmal von einer renommierten Domain signierte Nachricht — oft über ein Testkonto — wird massenhaft weiterverteilt und passiert die Filter dank einer geliehenen Reputation. DMARC sieht nichts, weil alles technisch korrekt ist; nicht signierte Header liefern einen Winkel zur Tarnung. Die Gegenmaßnahmen liegen aufseiten des Signierenden: ein breites h=, Oversigning, Schlüsselrotation, das nur teilweise wirksame x=-Tag und die Überwachung von Spitzen. DMARCbis schließt diese Tür nicht, und das Risiko lastet vor allem auf Großversendern, weit mehr als auf der Domain eines KMU.

Eine erste Diagnose kostet nichts: die kostenlose DMARC-Analyse zeigt den Zustand der Signaturen einer Domain, die Stabilität ihrer Versandquellen und die vorhandenen Alignments. Um die Abdeckung der signierten Header über die Zeit zu verfolgen und die anomalen Spitzen in den Berichten zu erkennen — das leise Signal eines Replays —, öffnet ein Konto die fortlaufende Überwachung, die diese von Natur aus stille Bedrohung nötig macht.