DKIM-Fehler: Was die einzelnen Fehler bedeuten und wie man sie behebt

DomainKeys Identified Mail (DKIM) ist eine der tragenden Säulen der E-Mail-Authentifizierung. Durch das Anfügen einer kryptografischen Signatur an ausgehende Nachrichten ermöglicht DKIM den empfangenden Mail-Servern zu überprüfen, ob eine E-Mail tatsächlich vom Domain-Inhaber autorisiert wurde und ob ihr Inhalt während der Übertragung nicht manipuliert wurde.

Wenn ein empfangender Server jedoch eine eingehende E-Mail überprüft und im Header den Status „dkim=fail“ feststellt, schlägt die Authentifizierung fehl. Ein DKIM-Fehler signalisiert empfangenden Gateways wie Google Workspace, Microsoft 365 oder Apple Mail, dass entweder der Nachrichtentext nach dem Verlassen des Absenders verändert wurde, der öffentliche Schlüssel nicht aus dem DNS abgerufen werden konnte oder die kryptografische Signatur selbst ungültig ist.

Je nach der DMARC-Richtlinie Ihrer Domain und den Sicherheitseinstellungen des Empfängers können DKIM-Fehler dazu führen, dass legitime geschäftliche E-Mails im Spam-Ordner landen oder gänzlich abgelehnt werden. Dieser Leitfaden dient als Nachschlagewerk für Fehlermeldungen und soll Ihnen dabei helfen, den genauen Fehlertext in Ihren E-Mail-Headern zu diagnostizieren, die Ursache zu ermitteln und das Problem schnell zu beheben.

Häufige Gründe für DKIM-Fehlschläge

Zwar sind Fehler bei der DKIM-Validierung letztendlich auf eine Hash-Diskrepanz oder einen Fehler beim Abrufen des Schlüssels zurückzuführen, doch lassen sich die tatsächlichen betrieblichen Ursachen in der Regel mehreren vorhersehbaren Kategorien zuordnen. Wenn Sie diese zugrunde liegenden Ursachen mit der konkreten Fehlermeldung in Ihren E-Mail-Headern abgleichen, gelangen Sie direkt zur Lösung.

1. Änderungen an Nachrichten durch E-Mail-Gateways und Sicherheitsgeräte

Die häufigste Ursache für DKIM-Fehler in Unternehmensumgebungen ist ein zwischengeschalteter Dienst, der den Inhalt einer Nachricht verändert, nachdem die DKIM-Signatur bereits angewendet wurde. Sicherheitsgeräte, Outbound-Gateways, Anti-Spam-Filter und Tools zur Verhinderung von Datenverlusten (DLP) verändern ausgehende Nachrichten häufig, indem sie Unternehmens-Fußzeilen anhängen, Tracking-Links einfügen, Zeichensätze neu kodieren oder MIME-Grenzen ändern. 

Wenn die Signierung auf dem primären Mailserver erfolgt, bevor die E-Mail diese Geräte durchläuft, stimmt der vom Empfänger berechnete Body-Hash nicht mit der ursprünglichen Signatur überein, was einen Fehler „dkim=fail“ (Body-Hash konnte nicht überprüft werden) auslöst.

2. Mailinglisten und automatische E-Mail-Weiterleitung

Wenn eine E-Mail an eine Mailingliste gesendet oder über zwischengeschaltete Mail-Transfer-Agenten (MTAs) automatisch weitergeleitet wird, ändert der Weiterleitungsserver häufig die Kopfzeilen der Nachricht (wie z. B. „Betreff“ oder „An“) oder fügt Fußzeilen zur Verwaltung der Mailingliste hinzu (wie z. B. Links zum Abmelden oder Haftungsausschlüsse der Liste). Da die kryptografische Signatur diese Komponenten abdeckt, macht jede Änderung nach der Signierung die Verifizierungsprüfung ungültig. 

Zwar helfen moderne Protokolle wie Authenticated Received Chain (ARC) den Weiterleitern dabei, den Authentifizierungsstatus beizubehalten, doch scheitern einfache DKIM-Prüfungen bei weitergeleiteten Nachrichten häufig.

3. Fehlende, falsch konfigurierte oder unvollständige DNS-TXT-Einträge

Empfangsserver müssen Ihren öffentlichen Schlüssel aus einem bestimmten DNS-TXT-Eintrag unter selector._domainkey.yourdomain.com abrufen. Fehlt dieser DNS-Eintrag, wird er unter einem falschen Selektor-Namen veröffentlicht oder kommt es zu einer Verzögerung durch die DNS-Propagierung, kann der Empfänger den Schlüssel nicht abrufen, was zu einem Fehler „dkim=fail“ (kein Schlüssel für die Signatur) führt.

Darüber hinaus tritt bei 2048-Bit-RSA-Schlüsseln ein spezifisches und häufig auftretendes Problem auf. Gemäß RFC 1035 ist eine einzelne Zeichenfolge innerhalb eines DNS-TXT-Eintrags auf 255 Byte begrenzt. Ein Base64-kodierter 2048-Bit-RSA-Schlüssel ist etwa 392 Zeichen lang. Wenn Ihr DNS-Anbieter oder -Administrator einen 2048-Bit-Schlüssel als einzelne Zeichenfolge ohne Anführungszeichen einfügt, können ältere DNS-Verwaltungstools die Schlüsseldaten abschneiden, was zu einem unvollständigen öffentlichen Schlüssel im DNS und einem „dkim=fail“-Fehler (Signatur konnte nicht verifiziert werden) führt.

4. Schlüsselinkongruenzen, unangekündigte Schlüsselrotation und Anbieterwechsel

Damit die DKIM-Überprüfung erfolgreich ist, muss der private Schlüssel, den der sendende Mailserver zur Erstellung der Signatur verwendet, mathematisch mit dem in Ihrem DNS veröffentlichten öffentlichen Schlüssel übereinstimmen. Eine kryptografische Nichtübereinstimmung liegt vor, wenn:

• Der Signatur-Mailserver generiert einen neuen privaten Schlüssel, der DNS-Eintrag wird jedoch nicht gleichzeitig aktualisiert.
• Ein E-Mail-Dienstanbieter (ESP) wechselt seine Signaturschlüssel, ohne Ihren veröffentlichten TXT-Eintrag oder Ihr CNAME-Ziel zu aktualisieren.
• Eine Domain wird auf eine neue Hosting-Plattform migriert, während der E-Mail-Server weiterhin mit einem alten Selektor oder einem stillgelegten Schlüsselpaar signiert.

5. Syntaxfehler in DNS-Einträgen und strenge Kanonisierungseinstellungen

Kleine Formatierungsfehler im Datensatz des öffentlichen Schlüssels (wie fehlende Semikolons, überflüssige Leerzeichen innerhalb der Base64-Schlüssel-Nutzlast oder falsche Tag-Namen) führen dazu, dass der öffentliche Schlüssel von den empfangenden MTAs nicht analysiert werden kann. 

Ebenso gilt: Wenn Ihr Signaturserver eine einfache Kanonisierung für Header oder den Haupttext verwendet (c=simple/simple), führen bereits geringfügige Änderungen der Zeilenenden (CRLF vs. LF) oder Anpassungen der nachgestellten Leerzeichen, die durch Zwischenrelais verursacht werden, dazu, dass die Überprüfung fehlschlägt.

Überblick Syntax des DKIM-Eintrags.

6. Sie haben DKIM für Ihre externen E-Mail-Anbieter nicht eingerichtet

Wenn Sie mehrere E-Mail-Anbieter von Drittanbietern nutzen, um E-Mails im Namen Ihrer Organisation zu versenden, müssen Sie sich mit diesen in Verbindung setzen, um Anweisungen zur Aktivierung von DKIM für Ihre ausgehenden E-Mails zu erhalten. Falls Sie eigene, bei diesem Drittanbieter registrierte Domains oder Subdomains verwenden, um E-Mails an Ihre Kunden zu versenden, sollten Sie Ihren Anbieter unbedingt bitten, die DKIM-Einrichtung für Sie zu übernehmen.

Im Idealfall sollte Ihr Drittanbieter, der Sie bei der Auslagerung Ihres E-Mail-Verkehrs unterstützt, Ihre Domain einrichten, indem er einen DKIM-Eintrag in seinem DNS mithilfe eines DKIM-Selektors , der für Sie einzigartig ist, ohne dass Sie dabei eingreifen müssen.

OR, 

Sie können ein DKIM-Schlüsselpaar generieren und den privaten Schlüssel an Ihren E-Mail-Anbieter weitergeben, während Sie den öffentlichen Schlüssel in Ihrem eigenen DNS veröffentlichen. 

Fehlerhafte Konfigurationen können zu DKIM-Fehlern führen. Sie müssen daher mit Ihrem Dienstanbieter offen über Ihre DKIM-Einrichtung. 

Hinweis: Einige E-Mail-Server von Drittanbietern fügen formatierte Fußzeilen in den Nachrichtentext ein. Wenn diese Server als Zwischenserver bei der Weiterleitung von E-Mails fungieren, kann die zusammengefügte Fußzeile dazu beitragen, dass die DKIM-Prüfung fehlschlägt. 

7. Probleme bei der Serverkommunikation

In bestimmten Situationen kann es vorkommen, dass die E-Mail von einem Server versendet wird, auf dem DKIM deaktiviert ist. In solchen Fällen schlägt die DKIM-Prüfung für diese E-Mail fehl, selbst wenn andere Server in Ihrer Infrastruktur korrekt konfiguriert sind. Es ist wichtig, sicherzustellen, dass alle Kommunikationspartner DKIM ordnungsgemäß aktiviert haben. 

8. DNS-Ausfall / DNS-Ausfallzeit

Dies ist ein häufiger Grund für DKIM-Fehler. DNS-Ausfälle können aus einer Vielzahl von Gründen auftreten, einschließlich Denial-of-Service-Angriffen. Auch routinemäßige Wartungsarbeiten an Ihrem Namensserver können der Grund für eine DNS-Ausfallzeit sein. Während dieser (in der Regel kurzen) Zeitspanne können die Empfängerserver keine DNS-Abfragen durchführen. 

Da wir wissen, dass DKIM in Ihrem DNS als TXT/CNAME-Eintrag vorhanden ist, führt der Client-Server während der Authentifizierung einen Lookup durch, um den öffentlichen Schlüssel im DNS des Absenders zu ermitteln. Bei einem Ausfall wird dies als nicht möglich erachtet und kann daher DKIM zerstören. 

9. Verwendung von OpenDKIM

OpenDKIM ist eine Open-Source-DKIM-Implementierung, die auf Ihrem eigenen Mailserver eingesetzt werden kann, um ausgehende E-Mails zu signieren und zu verifizieren. Bei einer selbst gehosteten OpenDKIM-Konfiguration kommuniziert der Dienst in der Regel über Port 8891 mit dem Mailserver.

Um sicherzustellen, dass OpenDKIM ordnungsgemäß funktioniert, können Sie mithilfe eines Online-Port-Checkers überprüfen, ob Port 8891 auf Ihrem Server offen und erreichbar ist. Sie sollten außerdem überprüfen, ob die erforderlichen Berechtigungen korrekt konfiguriert sind. Falsche Berechtigungen können dazu führen, dass OpenDKIM nicht auf seinen Socket zugreifen oder sich nicht ordnungsgemäß daran binden kann.

Überprüfen Sie Ihre Serverkonfiguration und das Verzeichnis, in dem sich der OpenDKIM-Socket befindet, um sicherzustellen, dass das Verzeichnis vorhanden ist und über die entsprechenden Eigentumsrechte und Berechtigungen verfügt.

10. DKIM-Prüfung auf Fehlanpassung

Wenn Sie DMARC zusätzlich zu DKIM für Ihre Domain eingerichtet haben, wird während der DKIM-Prüfungmuss der Domainwert im Feld „d=“ der DKIM-Signatur im E-Mail-Header mit der Domain in der Absenderadresse übereinstimmen. Dabei kann es sich entweder um eine strenge Übereinstimmung handeln, bei der die beiden Domains exakt übereinstimmen müssen, oder um eine lockere Übereinstimmung, bei der eine organisatorische Übereinstimmung ausreicht, um die Überprüfung zu bestehen. 

Ein DKIM-Fehler kann auftreten, wenn die Domain im DKIM-Signatur-Header nicht mit der Domain im „From“-Header übereinstimmt, was ein typischer Fall von Domain-Spoofing oder eines Identitätsbetrugsangriffs sein. 

DKIM-Fehler erklärt (nach Fehlermeldung)

Suchen Sie unten nach genau dem bei Ihnen aufgetretenen Fehler, um zu erfahren, welches Problem beim empfangenden Server aufgetreten ist und wie Sie es beheben können.

dkim=fail (Hash des Textkörpers konnte nicht überprüft werden)

Der Fehler „dkim=fail“ (Body-Hash konnte nicht überprüft werden) weist darauf hin, dass der öffentliche Schlüssel erfolgreich aus dem DNS abgerufen wurde und der gesamte Signatur-Header korrekt formatiert war, der vom Empfänger berechnete kryptografische Hash des Nachrichtentextes jedoch nicht mit dem im „bh=“-Tag der Signatur gespeicherten Hash-Wert übereinstimmt.

Einfach ausgedrückt: Der Textkörper der E-Mail wurde geändert, nachdem der Absenderserver ihn signiert hatte.

Hauptursachen:

• Outbound-Sicherheitsgateways, Disclaimer-Tools oder CRM-Plugins fügten nach dem Anmeldevorgang rechtliche Hinweise, Werbe-Fußzeilen oder Tracking-Pixel hinzu.
• Zwischenrelais veränderten Zeilenumbrüche, Zeichensätze oder Leerzeichen während der Übertragung.
• Die Software zur E-Mail-Weiterleitung oder für Mailinglisten hat den Inhalt der Nachricht verändert.

So beheben Sie das Problem:

1. Ordnen Sie Ihren ausgehenden E-Mail-Fluss so um, dass die DKIM-Signierung als allerletzter Schritt erfolgt, bevor die Nachricht Ihre Netzwerkinfrastruktur verlässt, um sicherzustellen, dass alle Fußzeilen und Tracking-Links vor der Signierung eingefügt werden.
2. Stellen Sie sicher, dass Ihr Mailserver die „Relaxed Body Canonicalization“ (c=relaxed/relaxed oder c=relaxed/simple) verwendet, die geringfügige Abweichungen bei Leerzeichen und Zeilenenden während der Übertragung toleriert.
3. Falls Sie in Ihren DKIM-Headern ein „l=“-Tag (Länge) verwenden, entfernen Sie dieses bitte. Das „l=“-Tag schränkt den Umfang des signierten Textkörpers ein, führt zu Sicherheitslücken und löst Probleme im Zusammenhang mit Änderungen am Textkörper nicht.

dkim=fail (kein Schlüssel für die Signatur)

Der Fehler „dkim=fail“ (kein Schlüssel für die Signatur) tritt auf, wenn der empfangende Server die Domäne (d=) und den Selektor (s=) aus dem DKIM-Signature-Header der E-Mail extrahiert und versucht, eine DNS-Abfrage unter s=._domainkey.d= durchzuführen, dabei jedoch keinen gültigen öffentlichen Schlüssel-Eintrag abrufen kann.

Dieser Fehler lässt sich konkret auf Probleme mit der DNS-Konfiguration oder auf Fehlkonfigurationen des Selektors eingrenzen.

Hauptursachen:

• Der von Ihrer sendenden Anwendung angegebene Selektorname stimmt nicht mit dem im DNS veröffentlichten Selektorpräfix überein.
• Der TXT- oder CNAME-Eintrag wurde nie auf dem autoritativen DNS-Server veröffentlicht.
• Der DKIM-Eintrag wurde erst kürzlich veröffentlicht und hat sich noch nicht vollständig in den DNS-Resolvern weltweit verbreitet.
• Der Eintrag für den öffentlichen Schlüssel wurde versehentlich während einer Domain-Migration oder einer Schlüsselbereinigung gelöscht.

So beheben Sie das Problem:

1. Überprüfen Sie den Rohtext des E-Mail-Headers, um die genaue Selektorzeichenfolge im s=-Tag zu ermitteln.
2. Vergewissern Sie sich, dass unter selector._domainkey.yourdomain.com ein DNS-TXT- oder CNAME-Eintrag vorhanden ist (Anweisungen zum Auffinden von Selektor-Zeichenfolgen finden Sie in unserer ausführlichen Anleitung zum Thema So finden Sie Ihren DKIM-Selektor).
3. Stellen Sie sicher, dass der DNS-Eintrag neben der Nutzlast „p=“ für den öffentlichen Schlüssel auch die obligatorischen Tags „v=DKIM1;“ und „k=rsa;“ (oder „k=ed25519;“) enthält.

dkim=fail (Signatur konnte nicht überprüft werden)

Im Gegensatz zu einem „Body-Hash“-Fehler bedeutet der Fehler „dkim=fail“ (Signatur konnte nicht verifiziert werden), dass die kryptografische Auswertung der Hauptsignaturzeichenfolge (das „b=“-Tag) fehlgeschlagen ist. Der Empfänger hat zwar einen öffentlichen Schlüssel aus dem DNS abgerufen, doch mit diesem Schlüssel konnte die Nutzlast der Header-Signatur nicht entschlüsselt und verifiziert werden.

Dieser Fehler deutet direkt auf ein ungültiges Schlüsselpaar oder geänderte Header-Felder hin.

Hauptursachen:

• Nicht übereinstimmendes Schlüsselpaar: Der private Schlüssel, den der sendende Server zum Signieren der Nachricht verwendet, stimmt nicht mit dem öffentlichen Schlüssel überein, der im DNS unter diesem Selektor veröffentlicht ist.
• Gekürzter DNS-Schlüssel: Ein 2048-Bit-Schlüssel wurde fälschlicherweise als einzelne Zeichenkette mit einer Länge von über 255 Byte veröffentlicht, was dazu führte, dass der DNS-Server die Daten des öffentlichen Schlüssels verkürzte.
• Änderung der Kopfzeilen: Ein zwischengeschalteter Mailserver oder ein Gateway hat die im h=Tag der Signatur explizit enthaltenen Kopfzeilen (wie „From“, „To“, „Subject“ oder „Date“) nach der Erstellung der Signatur verändert.

So beheben Sie das Problem:

1. Überprüfen Sie, ob Ihr 2048-Bit-Schlüsseldatensatz im DNS ordnungsgemäß in mehrere, jeweils unter 255 Byte lange, in Anführungszeichen gesetzte Zeichenfolgen aufgeteilt wurde.
2. Vergewissern Sie sich, dass Ihr privater Schlüssel auf dem Mailserver mit dem veröffentlichten öffentlichen Schlüssel übereinstimmt. Im Zweifelsfall generieren Sie ein neues Schlüsselpaar, aktualisieren Sie die DNS-Einträge und überprüfen Sie die Übereinstimmung.
3. Stellen Sie sicher, dass zwischengeschaltete Sicherheitsgeräte signierte Header-Felder während der Übertragung nicht verändern.

DKIM-Soft-Fail

Bei der E-Mail-Authentifizierung ist ist „Soft Fail“ kein nativer DKIM-Protokollstatus. Während SPF explizit ein „SoftFail“-Ergebnis (~all) definiert, definiert RFC 6376 DKIM-Ergebnisse streng als „pass“, „fail“, „policy“, „neutral“, „temperror“ oder „permerror“.

Wenn Administratoren oder E-Mail-Sicherheitstools einen „DKIM-Soft-Fail“ melden, beziehen sie sich in der Regel auf eines von zwei Szenarien:

1. DMARC-Bewertung unter p=none: Eine Nachricht durchläuft die DKIM-Authentifizierung nicht erfolgreich, doch da die DMARC-Richtlinie des Domaininhabers auf den Überwachungsmodus (p=none) eingestellt ist, stellt der empfangende E-Mail-Anbieter die E-Mail im Posteingang zu und kennzeichnet den internen Bewertungsstatus dabei als „Soft Failure“.
2. Gateway-spezifische Klassifizierung: E-Mail-Sicherheitsgateways (wie Cisco Secure Email oder Mimecast) geben manchmal interne Diagnosebezeichnungen wie „Soft Fail“ aus, wenn eine E-Mail die DKIM-Prüfung nicht besteht, die SPF-Prüfung jedoch bei korrekter DMARC-Ausrichtung bestanden wird, was bedeutet, dass die Zustellung der Nachricht insgesamt zulässig ist.

Wenn Sie in den Protokollen die Kennzeichnung „Soft Fail“ finden, behandeln Sie diese wie einen normalen DKIM-Fehler und überprüfen Sie Ihre Header auf die zugrunde liegende RFC-Fehlermeldung (Body-Hash konnte nicht verifiziert werden oder es fehlt ein Schlüssel für die Signatur).

Weitere DKIM-Fehler, die möglicherweise auftreten können

Empfangsserver können in ihren „Authentication-Results“-Headern außerdem die folgenden standardisierten DKIM-Diagnosecodes ausgeben:

DKIM schlägt fehl, SPF wird jedoch bestanden (und andere gemischte Ergebnisse)

Bei der Überprüfung von Berichten zur E-Mail-Zustellbarkeit werden Sie häufig auf Fälle stoßen, in denen die Protokollergebnisse widersprüchlich sind. Für die Fehlerbehebung ist es unerlässlich zu verstehen, wie empfangende Gateways diese Kombinationen bewerten.

Gemäß den DMARC-Spezifikationen (RFC 7489) besteht eine E-Mail die DMARC-Validierung insgesamt, solange mindestens ein der zugrunde liegenden Protokolle (SPF oder DKIM) den Status „PASS“ liefert und korrekt auf die im sichtbaren „From:“-Header angegebene Domain abgestimmt ist.

So werden gängige Protokollkombinationen bei der Übertragung aufgelöst:

Warum wird meine Nachricht aufgrund von DKIM blockiert?

Wenn die SPF-Prüfung erfolgreich ist, Ihre Nachricht aber aufgrund eines DKIM-Fehlers dennoch blockiert oder als Spam markiert wird, liegt einer der beiden folgenden Fälle vor:

1. SPF ist nicht abgeglichen: Die SPF-Prüfung wurde für eine Serverdomäne eines Drittanbieters (z. B. mail.mcsv.net) bestanden, stimmte jedoch nicht mit Ihrer tatsächlichen „From:“-Header-Domäne überein. Da die SPF-Übereinstimmung fehlgeschlagen ist und DKIM vollständig fehlgeschlagen ist, ist DMARC fehlgeschlagen.
2. Strenge Durchsetzung durch die Anbieter: Große Empfänger wie Google und Microsoft wenden strenge Sicherheitsrichtlinien für Massenversender an. Wenn eine E-Mail neben starken Anzeichen für Spam-Beschwerden auch strukturelle Authentifizierungsfehler aufweist, können die Algorithmen der Empfänger die Nachricht ungeachtet teilweiser Konformität blockieren.

Um zu verstehen, wie sich die Durchsetzung von Richtlinien auf nicht konforme E-Mails auswirkt, lesen Sie unseren Leitfaden zur DMARC-Richtlinie ist und testen Sie Ihre Domain mit unserem kostenlosen DMARC-Eintrag-Prüfprogramm.

So interpretieren Sie DKIM-Ergebnisse in Ihren E-Mail-Headern

Um Ihre spezifische Fehlermeldung zu identifizieren, müssen Sie die Rohdaten der Internet-Header einer zugestellten Test-E-Mail einsehen.

Schritt 1: Auf die Raw-Header in Ihrem E-Mail-Programm zugreifen

• Gmail: Öffnen Sie die Nachricht, klicken Sie auf die drei vertikalen Punkte neben der Schaltfläche „Antworten“ und wählen Sie „Original anzeigen“ aus.
• Microsoft Outlook (Web): Öffnen Sie die Nachricht, klicken Sie in der Aktionsleiste auf die drei Punkte, wählen Sie „Anzeigen“ aus und klicken Sie auf „Nachrichtendetails anzeigen“.
• Apple Mail: Öffnen Sie die E-Mail, klicken Sie in der oberen Menüleiste auf „Ansicht“, bewegen Sie den Mauszeiger über „Nachricht“ und wählen Sie „Rohdaten“.

Schritt 2: Suchen Sie den Header „Authentication-Results“

Blättern Sie durch den Rohtext der Kopfzeile, um den Block „Authentication-Results“ zu finden. Suchen Sie nach dem Eintrag „dkim=“.

Ein typischer Header-Eintrag, der einen Fehler anzeigt, sieht wie folgt aus:

Authentifizierungsergebnisse: mx.google.com;
dkim=fail (Body-Hash konnte nicht verifiziert werden) [email protected] header.s=s1 header.b=W8xKz2L;
spf=bestanden (google.com: Die Domain [email protected] gibt 192.0.2.1 als zulässigen Absender an) [email protected];
dmarc=bestanden (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Wichtige Header-Tags, die überprüft werden sollten:

• dkim=: Zeigt den aktuellen Verifizierungsstatus (erfolgreich, fehlgeschlagen, permanenter Fehler usw.) an, gefolgt von der expliziten Fehlermeldung in Klammern.
• header.i=: Zeigt die Identität/Domäne an, die die E-Mail signiert hat.
• header.s=: Gibt den genauen Selektor an, der zum Abrufen des öffentlichen Schlüssels aus dem DNS verwendet wird.
• header.d=: Gibt die Organisationsdomäne an, die die Verantwortung für die Signatur übernimmt.

Das manuelle Überprüfen von E-Mail-Rohheadern kann komplex, zeitaufwendig und insgesamt umständlich sein. Mit unseren kostenlosen E-Mail-Header-Analysator nutzen, um sofort verständliche Einblicke in Ihre SPF-, DKIM- und DMARC-Authentifizierungsergebnisse zu erhalten. 

So beheben Sie DKIM-Fehler und verhindern, dass sie erneut auftreten

Befolgen Sie diesen systematischen Abhilfeprozess, um DKIM-Probleme in Ihrer gesamten Versandinfrastruktur zu beheben:

1. Den öffentlichen Schlüssel im DNS überprüfen

Verwenden Sie ein Online-Nachschlagewerk wie unser DKIM-Record-Lookup , um den unter selector._domainkey.yourdomain.com veröffentlichten öffentlichen Schlüssel zu überprüfen.

• Stellen Sie sicher, dass keine Syntaxfehler, Tippfehler oder doppelte Semikolons vorhanden sind.
• Überprüfen Sie, ob die Schlüssel korrekt in Segmente unterteilt sind: Wenn Sie einen 2048-Bit-Schlüssel verwenden, stellen Sie sicher, dass Ihr DNS-Editor die Nutzdaten in durch Anführungszeichen getrennte Zeichenfolgensegmente mit jeweils weniger als 255 Zeichen aufgeteilt hat (z. B. „v=DKIM1; k=rsa; p=part1…“ „part2…“). Erstellen Sie niemals separate TXT-Einträge für denselben Selektor.

2. DKIM-Signierung auf den letzten ausgehenden Hop verlagern

Falls Ihr Unternehmen E-Mails über sekundäre Sicherheitsgateways, Disclaimer-Tools oder CRM-Lösungen weiterleitet, stellen Sie sicher, dass die DKIM-Signierung erst erfolgt, nachdem diese Tools ihre Ergänzungen vorgenommen haben. Falls ein Gerät Inhalte ändern muss, konfigurieren Sie dieses Gerät so, dass es den abschließenden DKIM-Signierungsschritt im Namen Ihrer Domain durchführt.

3. Einstellungen zur Kanonisierung aktualisieren

Ändern Sie die Kanonisierungseinstellungen Ihres Mail-Servers auf „relaxed/relaxed“ (oder „c=relaxed/relaxed“ im DKIM-Header). Dadurch werden empfangende Mail-Server angewiesen, Leerzeichen, nachgestellte Leerzeichen und die Formatierung der Header-Felder zu normalisieren, bevor der Hash neu berechnet wird. So werden falsche Verifizierungsfehler verhindert, die durch geringfügige Änderungen während der Übertragung verursacht werden.

4. Sicherstellung der Übereinstimmung der Schlüsselpaare bei Rotationen

Wenn Sie DKIM-Schlüssel rotieren, veröffentlichen Sie den neuen öffentlichen Schlüssel stets zuerst unter einem neuen Selektor-Namen im DNS. Warten Sie 24 bis 48 Stunden, bis die DNS-Änderungen übernommen sind, bevor Sie Ihren Mailserver so konfigurieren, dass Nachrichten mit dem neuen privaten Schlüssel signiert werden. Lassen Sie nach Abschluss der Migration den alten Eintrag für den öffentlichen Schlüssel noch einige Tage im DNS stehen, damit Nachrichten, die sich bereits in der Übertragung befinden oder in der Warteschlange stehen und mit dem alten Selektor signiert wurden, weiterhin überprüft werden können.

Bitte beachten Sie, dass wir einige häufige DKIM-Fehlermeldungen und deren wahrscheinliche Ursachen behandelt und jeweils eine mögliche Lösung dafür aufgezeigt haben. Es können jedoch Fehler auftreten, die auf verschiedene, für Ihre Domain und Ihre Server spezifische Ursachen zurückzuführen sind, die in diesem Artikel nicht behandelt wurden. 

Sie müssen sich ausreichend Wissen über Authentifizierungsprotokolle aneignen, bevor Sie diese in Ihrem Unternehmen implementieren oder Ihre Richtlinien durchsetzen. Fehler bei der DKIM-, SPF- oder DMARC-Validierung können die Zustellbarkeit Ihrer E-Mails beeinträchtigen. 

Häufig gestellte Fragen

Was bedeutet „Body-Hash konnte nicht überprüft werden“?

„Body-Hash nicht verifiziert“ bedeutet, dass der öffentliche Schlüssel im DNS gefunden wurde und das Header-Format gültig war, der Inhalt der Nachricht sich jedoch nach der Signierung geändert hat. Da der Nachrichtentext während der Übertragung verändert wurde (durch Haftungsausschlüsse, Sicherheitsgateways, Neukodierung oder Weiterleitung), stimmte der vom Empfänger berechnete Hash nicht mit dem ursprünglichen Hash überein, der im „bh=“-Tag der Signatur gespeichert war.

Wie behebe ich einen DKIM-Fehler?

Um einen DKIM-Fehler zu beheben, suchen Sie die genaue Fehlermeldung im „Authentication-Results“-Header Ihrer E-Mail. Handelt es sich bei dem Fehler um einen fehlenden Schlüssel (kein Schlüssel für die Signatur), veröffentlichen Sie den TXT-Eintrag für den öffentlichen Schlüssel im DNS unter dem richtigen Selektor oder korrigieren Sie ihn. Wenn der Fehler in einer Nichtübereinstimmung des Body-Hashs besteht (der Body-Hash konnte nicht verifiziert werden), passen Sie Ihren E-Mail-Workflow so an, dass die DKIM-Signierung als letzter Schritt erfolgt, nachdem alle Fußzeilen und Links hinzugefügt wurden, und stellen Sie die Kanonisierung auf „relaxed/relaxed“ ein.

Was bedeutet ein DKIM-Verstoß?

Ein „DKIM-Verstoß“ ist ein Begriff, der von bestimmten E-Mail-Sicherheitsgateways verwendet wird, um darauf hinzuweisen, dass eine eingehende E-Mail die DKIM-Validierungsprüfungen nicht bestanden hat. Dies bedeutet in der Regel, dass entweder die kryptografische Signatur ungültig war, die Nachricht während der Übertragung manipuliert wurde oder der Absender versucht hat, die E-Mail mit einer Domain zu signieren, die nicht mit der angezeigten Absenderadresse übereinstimmt.

Bedeutet ein DKIM-Fehler, dass meine E-Mail nicht zugestellt wird?

Nicht unbedingt. Wenn Ihre Domain über einen gültigen SPF-Eintrag verfügt, der bei korrekter DMARC-Ausrichtung die Prüfung besteht, wird die E-Mail in den meisten Fällen dennoch die allgemeine DMARC-Prüfung bestehen und den Posteingang erreichen. Wenn Sie sich jedoch ausschließlich auf SPF verlassen, ist Ihre Zustellbarkeit gefährdet, sobald E-Mails weitergeleitet werden. Wenn DMARC zudem bei beiden Protokollen fehlschlägt und Ihre Domain-Richtlinie auf „p=quarantine“ oder „p=reject“ eingestellt ist, wird die fehlerhafte E-Mail in den Spam-Ordner verschoben oder gänzlich abgelehnt.

• Über
• Neueste Beiträge

Maitham Al Lawati

Experte für Cybersicherheit, Geschäftsführer bei PowerDMARC

Maitham ist ein Tech-Unternehmer, Cybersecurity-Experte, CEO und Gründer von PowerDMARC mit mehr als 15 Jahren Branchenerfahrung. Maitham hat einen Global MBA von der University of Manchester und verschiedene berufliche Zertifizierungen, darunter CISSP, CISM, CRISC und ISC2 CCSP.

Neueste Beiträge von Maitham Al Lawati (alle anzeigen)

• DKIM-Fehler: Was die einzelnen Fehler bedeuten und wie man sie behebt – 13. September 2026
• Methoden zur E-Mail-Authentifizierung: Wie SPF, DKIM und DMARC Ihre Domain schützen – 9. August 2026
• Was ist eine DMARC-Richtlinie? „Keine“, „Quarantäne“ und „Ablehnen“ – 27. Juli 2026