Zum Hauptinhalt springen

DKIM fail: alle Ursachen und wie du sie behebst

Von CaptainDNS
Veröffentlicht am 19. Februar 2026

Diagnosebaum der Ursachen eines DKIM-Fehlers mit den zugehörigen Lösungen
TL;DR
  • Ein Ergebnis dkim=fail bedeutet, dass die DKIM-Signatur der E-Mail vom Empfangsserver nicht verifiziert werden konnte
  • Die 3 häufigsten Ursachen: Body Hash verändert (Inhalt modifiziert), öffentlicher Schlüssel im DNS nicht gefunden, Signatur abgelaufen (Frist x= überschritten)
  • E-Mail-Weiterleitung bricht fast immer die DKIM-Signatur, das ist ein erwartetes Verhalten, das nur ARC kompensieren kann
  • Verwende den Befehl dig TXT selektor._domainkey.captaindns.com, um zu prüfen, ob dein öffentlicher Schlüssel korrekt veröffentlicht ist
  • Kombiniere DKIM immer mit DMARC und SPF für eine vollständige Authentifizierung

Du öffnest die Header einer E-Mail und stößt auf dkim=fail. Die Nachricht wurde korrekt versendet, deine Konfiguration schien in Ordnung, trotzdem schlägt die DKIM-Überprüfung fehl. Dieses Szenario ist häufig und die Ursachen sind vielfältig.

Dieser Leitfaden geht jede Ursache eines DKIM-Fehlers durch, erklärt, wie du sie diagnostizierst, und gibt die passende Lösung an. Ob das Problem vom DNS, von der Signatur, von der Weiterleitung oder vom DMARC-Alignment kommt: du wirst genau wissen, was zu korrigieren ist.

Wie liest du ein DKIM-Ergebnis in den E-Mail-Headern?

Jede empfangene E-Mail enthält einen Authentication-Results-Header, der vom Empfangsserver hinzugefügt wird. Dort findest du das DKIM-Ergebnis.

Die möglichen Ergebnisse

ErgebnisBedeutung
dkim=passSignatur erfolgreich verifiziert
dkim=failDie Signatur existiert, aber die Überprüfung ist fehlgeschlagen
dkim=noneKeine DKIM-Signatur in der Nachricht gefunden
dkim=neutralSignatur vorhanden, aber der Verifizierer konnte kein Ergebnis ermitteln
dkim=temperrorVorübergehender Fehler (DNS-Timeout, Server nicht erreichbar)
dkim=permerrorDauerhafter Fehler (ungültige DNS-Syntax, fehlerhafter Schlüssel)

Beispiel eines Headers mit Fehler

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.d=captaindns.com header.s=google header.b=abc12345;
  spf=pass smtp.mailfrom=captaindns.com;
  dmarc=fail

Der Text in Klammern (body hash did not verify) gibt den genauen Grund des Fehlers an. Das ist dein Ausgangspunkt für die Diagnose.

Die 7 Ursachen eines DKIM-Fehlers

Diagnosebaum der DKIM-Fehler mit den 7 häufigsten Ursachen

Ursache 1: Body Hash nicht verifiziert

Meldung: body hash did not verify

Das ist der häufigste Fehler. Der Sendeserver berechnet einen Hash des E-Mail-Inhalts und fügt ihn in die Signatur ein (Tag bh=). Der Empfangsserver berechnet diesen Hash neu. Wenn beide nicht übereinstimmen, schlägt die Überprüfung fehl.

Häufige Ursachen:

  • Ein Zwischenrelay hat den Inhalt verändert (Footer hinzugefügt, URL-Umschreibung, Antivirusprogramm)
  • Der Mailingserver fügt ein Tracking-Pixel nach der Signatur hinzu
  • Ein E-Mail-Proxy oder ein DLP (Data Loss Prevention) verändert den Nachrichtentext

Diagnose:

# Prüfen, ob der DKIM-Eintrag korrekt veröffentlicht ist
dig TXT google._domainkey.captaindns.com +short

Lösung: Identifiziere den Dienst, der den Inhalt nach der Signatur verändert. Konfiguriere ihn so, dass er vor der DKIM-Signatur aktiv wird, oder schließe die Änderungen vom signierten Body aus.

Ursache 2: Öffentlicher Schlüssel nicht gefunden

Meldung: key not found oder no key for signature

Der Empfangsserver findet den DNS-Eintrag selektor._domainkey.domain nicht. Ohne öffentlichen Schlüssel ist eine Überprüfung der Signatur unmöglich.

Häufige Ursachen:

  • Der in der Signatur deklarierte Selektor (s=) entspricht keinem DNS-Eintrag
  • Der Eintrag wurde versehentlich gelöscht
  • Der CNAME zum Anbieter (Google, Microsoft) ist nicht konfiguriert
  • Die DNS-Propagation ist noch nicht abgeschlossen

Diagnose:

# Ersetze "selektor" durch den Wert des s=-Felds der Signatur
dig TXT selektor._domainkey.captaindns.com +short

Wenn der Befehl nichts zurückgibt, fehlt der Eintrag.

Lösung: Veröffentliche (oder erneut veröffentliche) den DNS-Eintrag (TXT oder CNAME) passend zum Selektor. Warte die DNS-Propagation ab (bis zu 48 Stunden je nach TTL).

Ursache 3: Signatur abgelaufen

Meldung: signature expired

Das Tag x= der DKIM-Signatur legt einen Ablaufzeitstempel fest. Wenn der Empfangsserver die Signatur nach diesem Zeitpunkt überprüft, schlägt sie fehl.

Häufige Ursachen:

  • Die E-Mail blieb zu lange in der Warteschlange (Greylisting, langsamer Empfangsserver)
  • Der Wert x= ist zu kurz (z.B. 1 Stunde statt 7 Tage)
  • Zeitabweichung zwischen den Servern

Lösung: Erhöhe die Gültigkeitsdauer der Signatur. Die meisten Anbieter verwenden 7 Tage. Wenn du den Sendeserver kontrollierst, prüfe, ob x= eine ausreichende Frist lässt (mindestens 72 Stunden empfohlen).

Ursache 4: Kanonisierungsfehler

Meldung: bad signature oder signature verification failed

Die Kanonisierung legt fest, wie der Server die Nachricht vor der Signaturüberprüfung normalisiert. Es gibt zwei Modi: simple und relaxed. Wenn der DKIM-Header c=simple/simple deklariert, aber ein Relay Leerzeichen oder die Groß-/Kleinschreibung der Header ändert, schlägt die Überprüfung fehl.

Diagnose: Suche in der DKIM-Signatur nach dem Tag c=. Wenn dort simple/simple steht, ist das wahrscheinlich die Ursache.

Lösung: Wechsle zu c=relaxed/relaxed. Dieser Modus toleriert kleinere Änderungen (Leerzeichen, Groß-/Kleinschreibung), die E-Mail-Relays üblicherweise vornehmen.

Ursache 5: Schlüssel zu kurz

Meldung: key too short oder insecure key

Seit 2024 lehnen Google und Yahoo RSA-Schlüssel mit 512 und 768 Bit ab. Die minimal akzeptierte Größe ist 1024 Bit, empfohlen werden 2048 Bit.

Diagnose:

# Schlüssel abrufen und Größe prüfen
dig TXT google._domainkey.captaindns.com +short
# Den Wert p= kopieren und in Base64 dekodieren, um die Bitlänge zu ermitteln

Lösung: Generiere ein neues RSA-2048-Bit-Schlüsselpaar (oder Ed25519) und veröffentliche den neuen öffentlichen Schlüssel im DNS. Aktualisiere die Konfiguration deines Sendeservers mit dem neuen privaten Schlüssel.

Ursache 6: E-Mail-Weiterleitung (Forwarding)

E-Mail-Weiterleitung ist die am schwierigsten zu lösende Ursache. Wenn ein Zwischenserver eine Nachricht weiterleitet, kann er den Inhalt verändern (Header hinzufügen, Absenderadresse umschreiben). Die ursprüngliche DKIM-Signatur wird dadurch ungültig.

Typische Fälle:

  • Automatische Weiterleitung von Gmail/Outlook an ein anderes Postfach
  • Mailinglisten, die einen Footer hinzufügen
  • E-Mail-Aliase, die an eine andere Domain weiterleiten

Lösung: Es gibt keine universelle Lösung. Das ARC-Protokoll (Authenticated Received Chain, RFC 8617) wurde für diesen Fall entwickelt: Jeder Zwischenserver fügt seine eigene ARC-Signatur hinzu und bildet so eine Vertrauenskette. Gmail und Microsoft unterstützen ARC. Auf Absenderseite kannst du den Signaturbruch bei der Weiterleitung nicht verhindern.

Ursache 7: Fehlendes DMARC-Alignment

Meldung: dmarc=fail (obwohl dkim=pass)

Dieser Fall ist besonders. Die DKIM-Signatur ist technisch gültig (dkim=pass), aber DMARC schlägt fehl, weil die Domain d= der Signatur nicht mit der Domain des From: übereinstimmt. Es ist ein Alignment-Problem, kein Signaturproblem.

Schema des DKIM-Alignments im DMARC-Kontext

Beispiel:

  • From: contact@captaindns.com
  • DKIM-Signatur: d=sendgrid.net (der Anbieter signiert mit seiner eigenen Domain)

DKIM besteht, aber das Alignment schlägt fehl, weil sendgrid.netcaptaindns.com.

Lösung: Konfiguriere deinen Versandanbieter so, dass er mit deiner Domain signiert (d=captaindns.com). Bei den meisten Anbietern (SendGrid, Mailchimp, Brevo) geschieht das über die Erstellung eines CNAME selektor._domainkey.captaindns.com, der auf deren Infrastruktur verweist.

Schnelldiagnose: Übersichtstabelle

SymptomWahrscheinliche UrsacheÜberprüfungLösung
body hash did not verifyInhalt nach Signatur verändertDas verändernde Relay identifizierenNach den Änderungen signieren
key not foundDNS-Eintrag fehltdig TXT s._domainkey.domainEintrag veröffentlichen
signature expiredFrist x= überschrittenx= mit dem Überprüfungszeitpunkt vergleichenGültigkeitsdauer erhöhen
bad signatureKanonisierung zu strengc= in der Signatur prüfenAuf relaxed/relaxed wechseln
key too shortRSA-Schlüssel <1024 BitÖffentlichen Schlüssel dekodierenNeuen 2048-Bit-Schlüssel generieren
dkim=pass + dmarc=failDomain-Alignmentd= und From: vergleichenMit eigener Domain signieren

Unterschied zwischen dkim=fail, dkim=none und dkim=temperror

Diese drei Ergebnisse weisen auf sehr unterschiedliche Situationen hin.

dkim=fail: Eine DKIM-Signatur ist in der Nachricht vorhanden, aber ihre Überprüfung ist fehlgeschlagen. Das ist ein aktives Problem, das behoben werden muss.

dkim=none: Keine DKIM-Signatur ist in der Nachricht vorhanden. Der Sendeserver signiert die E-Mails nicht. Konfiguriere DKIM auf deinem Server oder bei deinem Anbieter.

dkim=temperror: Der Empfangsserver konnte die Signatur wegen eines vorübergehenden Fehlers nicht überprüfen (DNS-Timeout, überlasteter Server). Die Überprüfung wird erneut versucht. Wenn das Problem bestehen bleibt, prüfe, ob deine DNS-Server schnell antworten (niedriger TTL, kein SERVFAIL).

Empfohlener Aktionsplan

  1. Identifiziere das genaue Ergebnis: Öffne die E-Mail-Header und notiere den Text in Klammern nach dkim=fail
  2. Überprüfe deinen DNS-Eintrag: Starte eine Analyse mit dem DKIM-Prüftool, um zu bestätigen, dass der öffentliche Schlüssel korrekt veröffentlicht und syntaktisch gültig ist
  3. Identifiziere deine aktiven Selektoren: Verwende den DKIM Selector Finder, um die bekannten Selektoren deiner Domain zu scannen
  4. Behebe die identifizierte Ursache: Wende die passende Lösung für deinen Fall an (siehe Tabelle oben)
  5. Überwache die Ergebnisse: Sende nach der Korrektur Test-E-Mails und prüfe, ob dkim=pass in den Headern erscheint

FAQ

Was bedeutet dkim=fail in den E-Mail-Headern?

Das Ergebnis dkim=fail zeigt an, dass die Nachricht eine DKIM-Signatur enthält, der Empfangsserver sie aber nicht verifizieren konnte. Der Text in Klammern (z.B. body hash did not verify) gibt den genauen Grund des Fehlers an. Das bedeutet nicht zwingend, dass die E-Mail betrügerisch ist: Auch eine legitime Änderung des Inhalts während der Übertragung kann diesen Fehler auslösen.

Warum schlägt mein DKIM fehl, obwohl der DNS-Eintrag korrekt ist?

Wenn dein DNS-Eintrag gültig ist, DKIM aber trotzdem fehlschlägt, liegt das Problem wahrscheinlich am Nachrichteninhalt. Ein Zwischenrelay (Antivirusprogramm, DLP, Proxy) könnte den Body nach der Signatur verändert haben. Prüfe außerdem, ob der Selektor in der Signatur (s=) mit dem im DNS veröffentlichten übereinstimmt.

Was ist die Ursache der Meldung 'body hash did not verify'?

Diese Meldung bedeutet, dass der vom Empfangsserver berechnete Hash des Inhalts nicht mit dem in der Signatur deklarierten Hash (Tag bh=) übereinstimmt. Der Nachrichtentext wurde zwischen Signatur und Überprüfung verändert. Die häufigsten Ursachen sind Relays, die einen Footer hinzufügen, Antivirussysteme und URL-Umschreibungstools.

Kann eine E-Mail trotz DKIM-Fehler zugestellt werden?

Ja. DKIM allein bestimmt nicht die Zustellung. Die DMARC-Richtlinie der Domain entscheidet: Mit p=none wird die E-Mail auch bei DKIM-Fehler zugestellt. Mit p=reject wird die E-Mail nur abgelehnt, wenn auch SPF fehlschlägt (DMARC erfordert, dass mindestens eines der beiden besteht). Viele Anbieter stellen die Nachricht in den Spam-Ordner, anstatt sie abzulehnen.

Was ist der Unterschied zwischen dkim=fail und dkim=none?

dkim=fail bedeutet, dass eine Signatur vorhanden ist, deren Überprüfung aber fehlgeschlagen ist. dkim=none bedeutet, dass keine DKIM-Signatur in der Nachricht vorhanden ist. Ersteres ist ein Konfigurationsproblem, Letzteres bedeutet, dass DKIM auf dem Sendeserver überhaupt nicht aktiviert ist.

Bricht E-Mail-Weiterleitung immer die DKIM-Signatur?

In den meisten Fällen ja. Die Weiterleitung verändert oft den Inhalt (Header hinzufügen, Adressen umschreiben), was die ursprüngliche DKIM-Signatur ungültig macht. Das ARC-Protokoll (RFC 8617) wurde entwickelt, um dieses Problem zu lösen, indem es eine Vertrauenskette zwischen den Zwischenservern erstellt. Gmail und Microsoft unterstützen ARC.

Wie überprüfe ich, ob meine DKIM-Korrektur funktioniert hat?

Sende nach der Korrektur eine Test-E-Mail an eine Gmail- oder Outlook-Adresse. Öffne die Header der empfangenen Nachricht und suche nach Authentication-Results. Wenn du dkim=pass siehst, war die Korrektur erfolgreich. Du kannst auch ein Online-Testtool verwenden, das detaillierte Authentifizierungsergebnisse anzeigt.

📖 Glossar

  • DKIM (DomainKeys Identified Mail): E-Mail-Authentifizierungsprotokoll mittels kryptografischer Signatur, das die Integrität ausgehender Nachrichten überprüft.
  • Body Hash: SHA-256-Fingerabdruck des E-Mail-Body, der in der DKIM-Signatur enthalten ist (Tag bh=).
  • Selektor: Textkennung, die die DNS-Adresse des öffentlichen DKIM-Schlüssels bildet (selektor._domainkey.domain).
  • Kanonisierung: Normalisierung der Nachricht (Leerzeichen, Groß-/Kleinschreibung) vor der Signaturberechnung. Modi: simple oder relaxed.
  • ARC (Authenticated Received Chain): Protokoll nach RFC 8617, das Authentifizierungsergebnisse bei der E-Mail-Weiterleitung bewahrt.
  • DKIM-Alignment: Überprüfung durch DMARC, ob die Domain d= der Signatur mit der Domain des From: übereinstimmt.

Generiere deine DKIM-Schlüssel in wenigen Sekunden: Verwende den DKIM-Generator, um ein RSA-2048- oder Ed25519-Schlüsselpaar mit dem sofort veröffentlichungsfertigen DNS-Eintrag zu erstellen.


📚 Verwandte DKIM-Anleitungen

Quellen

Ähnliche Artikel