Defaults.Exposed › Behebungen › Guides

DKIM „Body Hash Did Not Verify“ — was Ihre Nachricht verändert hat und wie Sie es beheben (2026)

Veröffentlicht 2026-07-08

Zahlen mit Stand 2026-06-29 · Methodik v7. Aggregierte Zensusdaten über 261 Millionen bewertete Domains. Siehe wie wir bewerten.

„Body hash did not verify“ bedeutet: Ihre DKIM-Signatur war gültig, als die Nachricht Sie verließ — und etwas hat den Nachrichtentext danach umgeschrieben. Die Signatur ist nicht kaputt; die Nachricht wurde unterwegs verändert. Nur 3,87% der Domains — 10.092.481 — vervollständigen die volle SPF-DKIM-DMARC-Trias, laut dem Defaults.Exposed-Zensus über 261.086.232 Domains (2026-06-29).

Der Fix ist eine Jagd, dann eine Entscheidung. Finden Sie den Hop, der Ihre Mail verändert — ein Gateway, das einen Disclaimer anhängt, eine Appliance, die Links umschreibt, eine Mailingliste, die eine Fußzeile hinzufügt. Dann signieren Sie nach diesem Hop, stoppen die Veränderung oder machen die Signatur tolerant dagegen — in dieser Reihenfolge.

Was bedeutet „body hash did not verify“ eigentlich?

Eine DKIM-Signatur (RFC 6376) trägt zwei Hashes: bh=, einen Hash des Nachrichten-Bodys zum Zeitpunkt der Signierung, und b=, das die Header plus diesen Body-Hash signiert. Der Verifizierer berechnet den Body-Hash aus der empfangenen Nachricht neu; passt er nicht zu bh=, stoppt die Verifikation mit dem String, den alle in eine Suchmaske einfügen — einem Empfänger-Header wie:

Authentication-Results: …; dkim=fail (body hash did not verify)

Das ist Microsofts dokumentierter Begründungs-String; Gmail gibt dieselbe Diagnose oft als dkim=neutral (body hash did not verify) aus. So oder so grenzt das Urteil das Problem enorm ein. Ihr DNS-Schlüssel, Selektor und die Signierkonfiguration sind alle in Ordnung. Die Kryptografie hat ihre Arbeit getan: Der Body hat sich zwischen Signierung und Verifikation verändert — eine angehängte Zeile, eine umgeschriebene URL, ein neu kodiertes Zeichen genügt. (Eine andere Meldung — signature did not verify, no key for signature — bedeutet einen anderen Fehler; beginnen Sie mit „DKIM signature not valid“.) Und es ist dringend, weil eine fehlgeschlagene Signatur DMARC kein Bestehen mit Alignment liefern kann: Sofern nicht SPF auf derselben Nachricht mit Alignment besteht, scheitert die Mail glatt an DMARC.

Was hat Ihre Nachricht verändert? Die üblichen Verdächtigen

Etwas im Zustellpfad hat den Body bearbeitet, nachdem Ihr Signierer ihn versiegelt hatte. In der Praxis ist es eines von vier Dingen:

Prüfen Sie zuerst die fett gedruckte Zeile — der Mailserver signiert, das Edge-Gerät bearbeitet, und jede Nachricht verlässt das Haus mit einer Signatur, die dreißig Millisekunden lang wahr war.

Wie finde ich den Hop, der meine Mail verändert?

Differenzialdiagnose — vergleichen Sie einen funktionierenden Pfad mit dem fehlschlagenden:

1. Senden Sie eine direkte Testnachricht an ein Postfach unter Ihrer Kontrolle bei einem großen Empfänger (Gmail eignet sich gut) und umgehen Sie dabei so viel Ihrer Ausgangs-Kette wie möglich.
2. Senden Sie eine zweite Nachricht über den fehlschlagenden Pfad — durch das Gateway, über die Liste, an die Domain des betroffenen Empfängers.
3. Vergleichen Sie die Authentication-Results-Zeilen in beiden vollständigen Headern. Direktversand dkim=pass, fehlschlagender Pfad dkim=fail (oder dkim=neutral) mit body hash did not verify: Der Veränderer sitzt zwischen diesen beiden Routen.
4. Sehen Sie sich den empfangenen Body an: ein Disclaimer, Banner oder eine Fußzeile, die Sie nicht getippt haben? Links auf eine Scan-Domain umgeschrieben? Das ist Ihr Hop, beim Namen genannt — und die Received:-Kette zeigt, welches Relay nur im fehlschlagenden Pfad auftaucht.

Ihre DMARC-Aggregatberichte erzählen dieselbe Geschichte im Großen: Eine Quelle, die konsistent DKIM-Fail bei SPF-Pass meldet, ist meist Veränderung unterwegs auf Ihrer eigenen Route, kein Angreifer.

Wie behebe ich es?

1. Führen Sie den kostenlosen Scan bei defaults.exposed durch, bevor Sie irgendetwas anfassen. Er bestätigt, dass Ihre veröffentlichten DKIM-Schlüssel und Ihre DMARC-Richtlinie in Ordnung sind — so debuggen Sie das eine echte Problem, die Veränderung, statt Geistern im DNS nachzujagen. Die Seite DKIM reparieren behandelt die Prüfungen auf Eintragsseite.
2. Signieren Sie nach dem verändernden Hop. Der architektonisch korrekte Fix: Verlagern Sie die DKIM-Signierung auf das äußerste Gerät, das die Nachricht anfasst. Umgebungen mit Exchange plus Gateway sollten am Gateway signieren (Mimecast, Proofpoint und Co. unterstützen das alle) und die Signierung weiter oben deaktivieren. Wenn Google Workspace oder Microsoft 365 Ihr letzter Hop ist, signieren Sie dort und lassen Sie danach nichts mehr an der Mail arbeiten — siehe DKIM auf Google Workspace einrichten oder Microsoft 365.
3. Oder stoppen Sie die Veränderung. Nehmen Sie die Bearbeitung aus dem Transportpfad: Disclaimer in die Client-Signatur oder Vorlage statt in eine Transportregel; das „EXTERNAL:“-Banner nur auf eingehende Mail beschränkt (die eigene ausgehende Mail als extern zu markieren ist gleich doppelt eine Fehlkonfiguration); authentifizierte ausgehende Mail vom Link-Umschreiben ausgenommen.
4. Nutzen Sie relaxed/relaxed-Kanonisierung (c=relaxed/relaxed). simple-Body-Kanonisierung scheitert an einer einzigen neu umbrochenen Zeile; relaxed toleriert Änderungen an Leerraum und Zeilenenden. Seien Sie ehrlich zur Grenze: relaxed verzeiht Formatierung, nie Inhalt — eine angehängte Fußzeile schlägt weiterhin fehl, und das soll sie auch.
5. Testen Sie beide Pfade erneut, dann scannen Sie noch einmal. Beide Routen sollten jetzt dkim=pass mit Ihrer Domain in d= zeigen, und der Scan-Bericht sollte sauber sein.

Sollte ich das l=-Tag nutzen, damit DKIM angehängten Inhalt ignoriert?

Nein — und misstrauen Sie jedem Leitfaden, der es vorschlägt. Das l=-Tag hasht nur die ersten N Bytes des Bodys, sodass eine angehängte Fußzeile die Signatur nicht mehr bricht. Es „funktioniert“, indem es das Ende Ihrer Nachricht unsigniert lässt: Jeder, der eine legitime signierte Nachricht besitzt, kann beliebigen Inhalt anhängen, und Ihre gültige Signatur validiert weiterhin über das Ergebnis. Das ist ein Spoofing-Loch im Gewand eines Fixes — praktischer Missbrauch wurde demonstriert, und manche Empfänger bestrafen oder ignorieren l= aus genau diesem Grund. Lösen Sie die Veränderung; entsignieren Sie nicht einen Teil Ihrer Mail.

Und Mailinglisten — kann ich die reparieren?

Meistens nein — und das zu wissen spart Ihnen Wochen. Eine Liste, die ein Betreff-Tag oder eine Fußzeile hinzufügt, bricht Ihren Body-Hash konstruktionsbedingt, und Sie kontrollieren die Liste nicht. Zwei Dinge helfen:

• Genau dieser Rest ist der Grund, warum der DMARC-Rollout gestuft abläuft. Der Weg von p=none über p=quarantine mit einer pct=-Rampe, während Sie Aggregatberichte lesen, sorgt dafür, dass listen-verstümmelte Nachrichten in Quarantäne landen statt vernichtet zu werden, während Sie die Auswirkungen bewerten — das Thema von von p=none zu p=reject, ohne legitime E-Mail zu verlieren.
• ARC ist der Mechanismus des Empfängers, nicht Ihrer. Authenticated Received Chain lässt die Liste bezeugen, wie die Authentifizierung bei Ankunft aussah, und den Empfänger entscheiden, ob er dem vertraut. Für Sie als Absender gibt es nichts zu konfigurieren. Gut geführte Listen entschärfen das, indem sie den From-Header umschreiben; schlecht geführte brechen einfach Ihre Mail.

Weiterleitung ist der Nachbarfall — sie bricht SPF zuverlässig, DKIM aber nur manchmal, weshalb DKIM mit Alignment Ihr weiterleitungsfestes Standbein ist, wenn der Body überlebt: siehe weitergeleitete E-Mail scheitert an SPF — warum Sie das nicht beheben können.

Warum bricht DKIM so oft, wenn so wenige Domains überhaupt den vollen Stack haben?

Weil DKIM das fragile mittlere Kind der Trias ist: SPF ist ein statischer DNS-Eintrag, DMARC eine Richtlinienerklärung, aber DKIM muss die Reise überstehen. Nur 51,84% der bewerteten Domains veröffentlichen laut dem Defaults.Exposed-Zensus überhaupt einen auffindbaren DKIM-Schlüssel im DNS, und nur 10.092.481 Domains — 3,87% von 261.086.232 bewerteten — halten SPF, DKIM und eine durchsetzende DMARC-Richtlinie zusammen (das SPF-Adoptions-Reifegradmodell schlüsselt die Leiter auf). Diesen Fix richtig hinzubekommen ist der schwerste Teil des Beitritts zu diesen 3,87%.

Häufig gestellte Fragen

Ist „body hash did not verify“ ein Zeichen, dass jemand meine Domain spooft? Meistens nicht — ein Spoofer kann Ihre DKIM-Signatur in der Regel gar nicht erst erzeugen, sodass seine Mail keine Signatur oder no key zeigt. Ein fehlgeschlagener Body-Hash bedeutet, dass eine von Ihrer Infrastruktur echt signierte Nachricht danach bearbeitet wurde. Prüfen Sie Ihr eigenes Gateway, bevor Sie einen Angreifer vermuten.

SPF besteht bei diesen Nachrichten — bin ich dann noch in Ordnung? Vorerst vielleicht: DMARC braucht nur ein Bestehen mit Alignment. Aber das SPF-Bestehen verdampft in dem Moment, in dem jemand die Nachricht weiterleitet, und wenn es nicht mit Ihrer From-Domain ausgerichtet ist, hat es für DMARC ohnehin nie gezählt. Bei nur 3,87% der Domains mit der vollen Trias (Zensus vom 2026-06-29 über 261.086.232 Domains) ist „ein humpelndes Standbein“ der Normalzustand — und der behebbare.

Behebt der Wechsel zu relaxed/relaxed-Kanonisierung mein Disclaimer-Problem? Nein. Relaxed toleriert nur Änderungen an Leerraum und Zeilenumbrüchen. Ein angehängter Disclaimer ist eine Inhaltsänderung, und der Hash muss daran scheitern — das ist DKIM, wie es korrekt arbeitet. Verlegen Sie den Signierpunkt oder verlegen Sie den Disclaimer.

Der Fehler tritt nur bei der Domain eines einzigen Kunden auf. Warum? Dessen Seite verändert mit ziemlicher Sicherheit eingehende Mail — eine Security-Appliance, die Links umschreibt oder Banner aufstempelt, bevor der Verifizierer läuft, oder eine interne Weiterleitung, die den Body neu kodiert. Schicken Sie ihm den Diagnose-Abschnitt dieser Seite; der Fix liegt auf seinem Gateway, nicht in Ihrem DNS.

Senden Sie dem Inhaber den Bericht

Wenn Sie das für einen Kunden oder Ihren Arbeitgeber beheben, schließen Sie den Kreis mit einem Beleg. Sobald der verändernde Hop repariert ist, führen Sie den kostenlosen Scan erneut durch und leiten Sie den bewerteten Bericht an den Geschäftsinhaber weiter: datiert, in klarer Sprache, der Stand von DKIM und DMARC auf einer Seite. Das ist das Dokument, das er für die Cyberversicherungs-Verlängerung und den nächsten Lieferantenfragebogen braucht — der Nachweis, dass die Mail, die das Unternehmen verlässt, jetzt auch die Mail ist, die ankommt.

Prüfen Sie Ihre Domain → · Leitfaden „DKIM signature not valid“ → · DKIM reparieren → · Wie wir bewerten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.