Defaults.Exposed › Behebungen › Guides

„DKIM Signature Not Valid“ — die Ursachen, in der Reihenfolge, in der Sie sie prüfen sollten (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.

„DKIM signature not valid“ hat fünf häufige Ursachen, die am besten der Reihe nach geprüft werden: unterwegs veränderter Inhalt, ein abgeschnittener Schlüsseleintrag, ein veröffentlichter Schlüssel, der nicht zum Signierer passt, der falsche Selektor und fragile Kanonisierung. Nur 10.092.481 von 261.086.232 bewerteten Domains (3,87%) verfügen über die vollständige Trias aus SPF + DKIM + durchsetzendem DMARC, laut dem Defaults.Exposed-Zensus (2026-06-29).

Die Reihenfolge der Fixes ist wichtig, weil die häufigste Ursache gar nicht in Ihrem DNS liegt. Prüfen Sie zuerst, was die Nachricht unterwegs verändert hat, und arbeiten Sie sich dann nach innen vor: die Integrität des Schlüsseleintrags, ob er zu dem passt, womit Ihr Mailserver tatsächlich signiert, der Selektor und schließlich die Signatureinstellungen. Die meisten ungültigen Signaturen sind bei Schritt eins oder zwei behoben.

Was bedeutet „DKIM signature not valid“ eigentlich?

Jede DKIM-signierte Nachricht trägt einen DKIM-Signature-Header, der eine Domain (d=), einen Selektor (s=), einen Hash des Nachrichtentexts (bh=) und eine kryptografische Signatur über den Body-Hash plus ausgewählte Header (b=) benennt. Der Empfänger holt Ihren öffentlichen Schlüssel per DNS unter <selector>._domainkey.<domain>, berechnet beide Hashes neu und prüft die Signatur (RFC 6376). „Signature not valid“ ist die Sprache der Checker und Header für: Diese Verifikation lief und schlug fehl — der Schlüssel wurde gefunden, aber die Rechnung ging nicht auf.

Dieser letzte Halbsatz ist diagnostisches Gold. Ein Verifizierer, der Ihren Schlüssel nicht finden kann, sagt etwas anderes — typischerweise einen Header wie dkim=fail (no key for signature) —, und das ist ein Selektorproblem, behandelt in DKIM „no key for signature“ — Selektor- und Rotations-Fixes. Und ein Verifizierer, der einen anderen Body-Hash errechnet, sagt das meist ausdrücklich: body hash did not verify — Microsoft meldet es als dkim=fail (body hash did not verify), während Gmail dieselbe Diagnose oft als dkim=neutral (body hash did not verify) ausgibt. So oder so deutet das auf Inhaltsveränderung, behandelt in „body hash did not verify“ — was Ihre Nachricht verändert hat. Lesen Sie den exakten Wortlaut im Authentication-Results-Header, bevor Sie irgendetwas anfassen: Er sagt Ihnen, welche der fünf Ursachen Sie vor sich haben.

Das richtig hinzubekommen ist selten: Nur 51,84% der bewerteten Domains veröffentlichen laut dem Defaults.Exposed-Zensus überhaupt einen auffindbaren DKIM-Schlüssel im DNS, und nur 3,87% von 261 Millionen bewerteten Domains kombinieren SPF, DKIM und eine durchsetzende DMARC-Richtlinie — die Konfiguration, die die Bulk-Sender-Regeln inzwischen voraussetzen. Das Bild Stufe für Stufe steht im SPF-Adoptions-Reifegradmodell.

Was sind die fünf Ursachen, der Reihe nach?

Ursache 1 ist fett gedruckt, weil sie Signaturen auf Nachrichten bricht, die perfekt signiert wurden. Ein Sicherheits-Gateway hängt einen Disclaimer an, eine Compliance-Fußzeile wird nach dem Signieren aufgestempelt, eine Mailingliste fügt [listname] zum Betreff hinzu — der Body oder die signierten Header ändern sich, die Hashes passen nicht mehr, und die Signatur ist ungültig, ohne dass Ihr DNS etwas dafür kann. Wenn die Fehler mit Mail korrelieren, die durch ein Gateway, eine Liste oder einen Archivierungs-Hop lief, fangen Sie dort an.

Wie behebe ich „DKIM signature not valid“?

1. Führen Sie den kostenlosen Scan bei defaults.exposed durch, bevor Sie das DNS anfassen. Er zeigt, ob Ihr veröffentlichter Schlüsseleintrag vorhanden, wohlgeformt und vollständig ist — und trennt so „Ihr DNS ist kaputt“ (Ursachen 2–4) von „Ihr DNS ist in Ordnung, die Nachricht wird verändert“ (Ursache 1) in einem Schritt.
2. Lesen Sie den Authentication-Results-Header einer fehlschlagenden Nachricht. body hash did not verify → Ursache 1, weiter zum Body-Hash-Leitfaden — die üblichen Verdächtigen sind Gateway-Fußzeilen und Disclaimer, und der Fix ist, nach der Veränderung zu signieren. no key for signature → Ursache 4, weiter zum Selektor-Leitfaden. Ein schlichter Signaturfehler → weiterlesen.
3. Prüfen Sie den veröffentlichten Schlüssel auf Abschneidung. Schlagen Sie <selector>._domainkey.<yourdomain> als TXT nach (dig TXT selector._domainkey.example.com). Ein öffentlicher 2048-Bit-RSA-Schlüssel ist länger als das 255-Zeichen-Limit eines einzelnen TXT-Strings, muss also als mehrere in Anführungszeichen gesetzte Strings veröffentlicht werden, die Empfänger zusammenfügen — und die Web-Oberflächen von DNS-Providern sind berüchtigt dafür, den eingefügten Text stillschweigend abzuschneiden, die Aufteilung zu verstümmeln oder Leerzeichen und Anführungszeichen in den p=-Wert einzuschleusen. Vergleichen Sie Zeichen für Zeichen mit dem Schlüssel, den Ihr Signierer erzeugt hat; unsere DKIM-Einrichtungsanleitungen behandeln die Eigenheiten der einzelnen Provider.
4. Bestätigen Sie, dass der veröffentlichte Schlüssel zum Signierer passt. Nach einer Schlüsselrotation, Provider-Migration oder ESP-Neuverbindung kommt es häufig vor, dass der Signierer einen neuen privaten Schlüssel hält, während das DNS noch den alten öffentlichen Schlüssel ausliefert — jede Signatur wird gegen den falschen Schlüssel geprüft und schlägt fehl. Kopieren Sie den aktuellen Eintrag erneut aus der Admin-Konsole Ihres Providers. Besser: Wo der Provider CNAME-Delegation anbietet, nutzen Sie sie — der Provider rotiert die Schlüssel auf seiner Seite, und diese ganze Fehlerklasse verschwindet. Und löschen Sie nie einen alten Selektor, bevor der damit signierte Verkehr ausgelaufen ist.
5. Korrigieren Sie die Signatureinstellungen, nicht nur den Eintrag. Stellen Sie die Kanonisierung auf c=relaxed/relaxed, was das Neuumbrechen von Leerraum und das Neufalten von Headern toleriert, das Zwischenserver legitimerweise vornehmen; simple-Kanonisierung scheitert an Änderungen, die ein Mensch nicht einmal sehen kann. Und verwenden Sie nicht das l=-Body-Längen-Tag: Es sollte Fußzeilen durchlassen, erlaubt aber jedem, Inhalt an Ihre signierte Nachricht anzuhängen, ohne die Signatur zu brechen — ein realer Angriffsvektor —, und übersteht die meisten Gateway-Veränderungen trotzdem nicht. Kein l= ist die sicherere und zugleich zuverlässigere Wahl.
6. Erneut scannen, dann Alignment prüfen. Eine gültige Signatur hilft DMARC nur, wenn die d=-Domain mit Ihrer From-Domain übereinstimmt — eine Signatur, die als d=yourcompany.gappssmtp.com validiert, besteht DKIM und scheitert trotzdem an DMARC. Wenn das auf Sie zutrifft, siehe die Standardsignatur-Falle, und arbeiten Sie dann alles Weitere ab, was der Scan auf der Seite DKIM reparieren markiert.

Häufig gestellte Fragen

Ist „DKIM signature not valid“ dasselbe wie „body hash did not verify“? Die Body-Hash-Meldung ist ein spezifischer Unterfall: Der Body wurde nach dem Signieren verändert (Fußzeilen, Disclaimer, Listen-Umschreibungen). „Signature not valid“ ist das Sammelurteil für jede fehlgeschlagene Verifikation, einschließlich fehlerhafter Schlüssel und Header-Änderungen — deshalb ist Schritt 2 oben das Lesen des Headers, und deshalb hat der Body-Hash-Fall einen eigenen Leitfaden.

Bedeutet eine ungültige DKIM-Signatur, dass meine Mail abgewiesen wird? Für sich genommen nicht — Empfänger behandeln eine kaputte Signatur wie eine fehlende. Der Schaden kommt über DMARC: Wenn auch SPF nicht mit Alignment besteht, scheitert die Nachricht an DMARC, und Ihre veröffentlichte Richtlinie greift. Zum Zensus vom 2026-06-29 halten nur 3,87% der 261.086.232 bewerteten Domains SPF, DKIM und eine durchsetzende DMARC-Richtlinie zusammen — aber Gmail und Microsoft erwarten von Absendern inzwischen genau das, sodass ein kaputtes DKIM-Standbein schon vor jeder Abweisung Zustellbarkeit kostet.

Sollte ich einen 1024-Bit- oder einen 2048-Bit-DKIM-Schlüssel verwenden? 2048 Bit — 1024-Bit-Schlüssel liegen unter den aktuellen kryptografischen Empfehlungen, und manche Empfänger werten sie ab. Der Haken ist rein operativ: Ein 2048-Bit-Schlüssel passt nicht in einen einzelnen 255-Zeichen-TXT-String, muss also korrekt aufgeteilt werden (Ursache 2 oben). CNAME-Delegation an Ihren Provider umgeht das Aufteilungsproblem vollständig.

Mein DKIM besteht bei einem Checker, aber DMARC scheitert trotzdem — wie das? Mit ziemlicher Sicherheit Alignment: Die Signatur validiert, aber ihre d=-Domain (etwa yourcompany.gappssmtp.com oder yourtenant.onmicrosoft.com) stimmt nicht mit Ihrer From-Domain überein, also kann DMARC sie nicht nutzen. Aktivieren Sie das Custom-Domain-Signing Ihres Providers — die vollständige Anleitung steht im Leitfaden zur Standardsignatur-Falle.

Kann ich DKIM nicht einfach abschalten, wenn es ständig fehlschlägt? Nein — seit den Bulk-Sender-Vorgaben von 2024 verlangen Gmail und Yahoo DKIM für Volumenversender, und eine durchsetzende DMARC-Richtlinie braucht realistisch DKIM, weil SPF allein bei Weiterleitungen bricht. Reparieren Sie die Signatur; die Ursachen oben sind alle an einem Nachmittag behebbar.

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. Führen Sie nach Ihren Änderungen den kostenlosen Scan erneut durch und leiten Sie den bewerteten Bericht an den Geschäftsinhaber weiter: datiert, in klarer Sprache, DKIM auf Grün. Das ist das Dokument, das er für die Cyberversicherungs-Verlängerung und den nächsten Lieferanten-Sicherheitsfragebogen braucht — der Unterschied zwischen „Ich habe da was am DNS repariert“ und einem dokumentierten Vorher-Nachher, das belegt, dass die Domain ihre Mail authentifiziert.

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