DKIM fail beheben: Schlüssel, DNS und Versandweg

DKIM fail bedeutet, dass eine Signaturprüfung fehlgeschlagen ist. Das ist kein abschließendes Urteil über Vertrauenswürdigkeit oder Zustellung, kann aber die Annahme und Spam-Einstufung beeinflussen. Für die übrige Konfiguration hilft unser Leitfaden zu geschäftlichen E-Mail-Adressen, damit SPF, DKIM, DMARC, Routing und Postfächer zusammenpassen.

Auf Ihrer Seite sieht die Nachricht normal aus. Beim Empfänger bei Gmail, Microsoft oder Yahoo erscheint jedoch dkim=fail. Je nach weiteren Prüfergebnissen und Empfängerrichtlinie können Spam-Einstufungen, vorübergehende Einschränkungen oder Ablehnungen folgen. Zunächst ist oft unklar, ob DNS, das Versandsystem oder ein veränderndes Sicherheitsgateway die Ursache ist.

Gehen Sie wie bei einer technischen Störung vor: Authentifizierungsergebnis lesen, Fehlerklasse bestimmen, Selektor und Schlüssel prüfen und alle Verarbeitungsschritte nach der Signierung untersuchen. Ändern Sie anschließend gezielt die fehlerhafte Stelle.

Was bedeutet dkim fail genau?

DKIM fail bedeutet, dass der Empfänger die kryptografische Signatur nicht erfolgreich prüfen konnte. Mögliche Ursachen sind ein veränderter Nachrichtentext, ein unpassender Schlüssel oder Änderungen an signierten Headern. Fehlende Schlüssel und DNS-Probleme können dagegen dauerhafte oder vorübergehende Fehler ergeben; diese Ergebnisse sollten getrennt betrachtet werden.

RFC 6376 definiert unter anderem den Body-Hash in bh= und die Headersignatur in b=. Fehler in diesen Prüfungen bedeuten nicht automatisch Spoofing. Häufig passen Schlüssel und Selektor nicht zusammen, oder ein weiterer Verarbeitungsschritt verändert die Nachricht nach der Signierung.

DKIM ähnelt einem Siegel auf einer Sendung. Passt das Siegel nicht zur angekommenen Sendung, schlägt die Prüfung fehl. Die Ursache muss anschließend untersucht werden; daraus folgt noch kein umfassendes Vertrauensurteil.

Beginnen Sie mit dem Header Authentication-Results der betroffenen Nachricht. Er nennt das Prüfergebnis und enthält häufig Hinweise zur Fehlerklasse. Das folgende Beispiel illustriert Diagnosefelder, ist aber kein stimmiges Normalmodell: Erfolgreiches SPF für dieselbe ausgerichtete Domain würde üblicherweise DMARC bestehen lassen.

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
  spf=pass smtp.mailfrom=example.com;
  dmarc=fail header.from=example.com

Wenn Sie zunächst die Domain-Einträge kontrollieren möchten, vergleichen Sie sie mit TrekMails erforderlichen DNS-Einträgen.

Vier typische Klassen von DKIM-Problemen

Zur ersten Eingrenzung sind vier Bereiche hilfreich: abweichender Body-Hash, Selektor oder Schlüssel, fehlerhafter DNS-Schlüssel und Änderungen durch Weiterleitungen oder Relays. Eine richtige Einordnung verhindert unnötige Schlüsselwechsel.

Authentifizierungsergebnis	Mögliche Bedeutung	Zuerst prüfen
`dkim=fail (body hash did not verify)`	Signierter Nachrichtentext stimmt nach Kanonisierung nicht überein	Relays, Fußtexte, Linkumschreibung, Kanonisierung
`dkim=fail (signature did not verify)`	Schlüssel passt nicht oder signierte Header wurden verändert	Selektor, Schlüsselwechsel, Sender, Headerverarbeitung
`dkim=permerror (no key for signature)`	Kein nutzbarer öffentlicher Schlüssel gefunden	Selektor-Hostname, DNS-Verfügbarkeit, Eintragsformat
`dkim=temperror`	Vorübergehendes Problem bei der DNS-Abfrage	Autoritatives DNS, TTL, Nameserver-Erreichbarkeit

Die Tabelle dient der Eingrenzung. Bestätigen Sie die konkrete Ursache durch weitere Prüfungen.

Fehlerklasse 1: abweichender Body-Hash

Ein abweichender Body-Hash bedeutet, dass der empfangene signierte Teil des Nachrichtentextes nach Kanonisierung nicht dem Hash entspricht. Ein byteweiser Vergleich ist dafür nicht maßgeblich. Daraus lässt sich auch nicht ableiten, dass der DNS-Eintrag korrekt ist.

RFC 6376 beschreibt eine fehlgeschlagene Prüfung, wenn der neu berechnete Body-Hash nicht dem Wert bh= entspricht. Das deutet häufig auf Änderungen nach der Signierung oder Probleme bei der Verarbeitung hin.

Typische Ursachen:

Microsoft 365, Exchange oder Sicherheitsgateways hängen nach der Signierung rechtliche Hinweise an.
Mimecast, Barracuda, Proofpoint und ähnliche Filter schreiben Links um.
Ein Relay verändert Leerraum oder Zeilenenden außerhalb der tolerierten Kanonisierungsregeln.
Eine Anwendung signiert, bevor ein Gateway MIME-Grenzen verändert oder Hinweise wie [External] ergänzt.

Prüfen Sie den Wert c=. Bei c=simple/simple gelten strengere Regeln als bei entspannter Kanonisierung. Die entspannte Body-Kanonisierung nach RFC 6376 ignoriert abschließenden Leerraum und fasst Leerraum innerhalb von Zeilen zusammen. Sie kann harmlose Formatänderungen tolerieren, aber keine inhaltlichen Änderungen reparieren.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=tm1; h=from:to:subject:date:mime-version;
 bh=...; b=...

Prüfen Sie außerdem die Architektur: Signieren Sie möglichst nach allen verändernden Verarbeitungsschritten am letzten von Ihnen kontrollierten Versandpunkt. Das schützt nicht vor späteren Änderungen durch externe Systeme, reduziert aber vermeidbare interne Fehler.

Bei Weiterleitungen helfen E-Mail-Weiterleitung und Domain-E-Mails an Gmail weiterleiten. Ein Test ohne Weiterleitung kann erfolgreich sein, obwohl der tatsächliche Weiterleitungsweg die Authentifizierung beeinträchtigt.

Fehlerklasse 2: Selektor oder Schlüssel passt nicht

Die Signatur nennt Selektor X, aber unter diesem Namen fehlt ein nutzbarer Schlüssel oder der veröffentlichte Schlüssel passt nicht zum privaten Signaturschlüssel. Fehlende Schlüssel können als dauerhafter Fehler erscheinen; ein unpassender Schlüssel kann die Signaturprüfung scheitern lassen.

Lesen Sie Selektor und Domain im Signaturheader:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...

Fragen Sie genau diesen Selektor ab:

dig txt k1._domainkey.example.com +short

Eine leere Antwort kann auf einen fehlenden Eintrag, einen falschen Namen, Cache-Effekte oder Abfrageprobleme hinweisen. Prüfen Sie bei einer Antwort den vollständigen Schlüssel gegen die aktuelle Senderkonfiguration. Besonders bei Migrationen und mehreren Sendern bleibt gelegentlich ein altes Schlüsselpaar in Verwendung.

Das kann bei mehreren Versandsystemen für dieselbe Domain auftreten: Anwendungsnachrichten über SES, Support über Microsoft 365 und Kampagnen über einen anderen ESP. Ein gemeinsamer Selektor wird geändert, während ein anderes System noch den alten privaten Schlüssel verwendet. Dadurch können Fehler nur bei einem Teil der Nachrichten auftreten.

Bei TrekMails verwaltetem Versand prüfen Sie Managed TrekMail SMTP und die tatsächliche Signierung im Versandweg. Für Nano oder einen eigenen Sender erläutert eigener SMTP (BYO) die Einrichtung: TrekMail ist dabei SMTP-Client, die Signierung muss beim tatsächlichen Sender konfiguriert sein.

Fehlerklasse 3: lange Schlüssel im DNS

Ein falsch veröffentlichter öffentlicher Schlüssel kann die DKIM-Prüfung verhindern, etwa wenn eine DNS-Oberfläche einen 2048-Bit-Schlüssel nicht vollständig speichert. Mögliche Ergebnisse sind permerror, Formatfehler oder ein unvollständig ausgegebener Schlüssel.

RFC 8301 verlangt bei RSA mindestens 1024-Bit-Schlüssel und empfiehlt mindestens 2048 Bit. Diese Empfehlung sollte nicht wegen Eingabeproblemen aufgegeben werden; prüfen Sie stattdessen die Regeln Ihrer DNS-Oberfläche.

Werte können abgeschnitten oder falsch mit Anführungszeichen versehen werden. Dann hilft auch der korrekte private Schlüssel beim Sender nicht. Das folgende Beispiel zeigt nur das Format, keinen verwendbaren vollständigen Schlüssel:

; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
  "restOfThePublicKeyContinuesHere..."
)

Prüfen Sie bei der Abfrage alle Zeichenketten desselben TXT-Eintrags, nicht nur die erste:

dig txt k1._domainkey.example.com +short

Nach einem DNS-Anbieterwechsel, einer Zonenmigration oder manuellem Kopieren sollten Sie diese Werte besonders sorgfältig vergleichen.

Fehlerklasse 4: Weiterleitungen, Relays und fehlende Ausrichtung

Weiterleitungen können SPF beeinträchtigen und zugleich DKIM scheitern lassen, wenn signierte Inhalte verändert werden. DMARC scheitert dann, wenn kein anderes erfolgreiches, ausgerichtetes Authentifizierungsergebnis verbleibt. Die Zustellentscheidung hängt zusätzlich vom Empfänger ab.

Beispiel: Sie senden von example.com an eine Universität, die an Gmail weiterleitet. SPF kann am Weiterleitungsserver scheitern. DKIM kann erhalten bleiben, sofern signierte Inhalte unverändert bleiben. Fügt der Weiterleiter einen Fußtext hinzu, schreibt Links um oder verändert einen signierten Betreff, kann auch DKIM scheitern. Ohne eine andere ausgerichtete erfolgreiche Prüfung besteht DMARC dann nicht.

Google verlangt für gewöhnliche direkte Sender an persönliche Gmail-Konten SPF oder DKIM; für Massenversender gelten SPF und DKIM sowie DMARC mit Ausrichtung über mindestens einen erfolgreichen Pfad. Für Weiterleitungen und Mailinglisten wird auch ARC behandelt. ARC kann Authentifizierungsinformationen erhalten, seine Bewertung liegt aber beim Empfänger.

Auch SRS und eine geplante Routingrichtlinie können wichtig sein. SRS kann die SPF-Prüfung der neu geschriebenen Envelope-Absenderadresse unterstützen, stellt aber keine SPF-Ausrichtung zur ursprünglichen From-Domain her. Prüfen Sie TrekMails SRS-Unterstützung und die konkrete Weiterleitungskonfiguration; SRS ersetzt weder DKIM noch DMARC-Ausrichtung.

Bei vielen Aliasen helfen E-Mail-Alias-Weiterleitung und E-Mail mit eigener Domain erstellen. Manche schwer nachvollziehbaren DKIM-Probleme liegen im Weiterleitungsweg, nicht im Aliasnamen selbst.

Ein wiederholbarer Prüfablauf bei dkim fail

Prüfen Sie zunächst das Authentifizierungsergebnis, dann Selektor und DNS, anschließend den Signierungsweg und die Ausrichtung. So vermeiden Sie DNS-Änderungen, wenn tatsächlich ein Gateway die signierte Nachricht verändert.

Öffnen Sie die Originalnachricht und suchen Sie Authentication-Results. Notieren Sie das genaue DKIM-Ergebnis.
Lesen Sie die Tags d=, s= und c= im Header DKIM-Signature.
Fragen Sie den Selektor mit dig ab. Prüfen Sie den Hostnamen selector._domainkey.example.com.
Stellen Sie fest, welches System tatsächlich signiert. Mehrere Sender können unterschiedlich konfigurierte Signaturen erzeugen.
Prüfen Sie Änderungen am Text oder an signierten Headern durch Gateways, Filter und Weiterleitungen.
Prüfen Sie die Ausrichtung: Die Domain in d= muss zur sichtbaren Domain in From: ausgerichtet sein, damit DKIM DMARC erfüllt.

Das Einfügen einzelner Fragmente in einen externen Prüfer kann zusätzliche Formatänderungen und falsche Body-Hash-Fehler verursachen. Verwenden Sie die vollständige Originalnachricht oder eine exportierte .eml-Datei.

DKIM-Störungen mit einem abgestimmten TrekMail-Versandweg beheben

Unkoordinierte Änderungen an DNS, Relays und Fußtexten erschweren die Diagnose. Ein klarer Ablauf mit Signierung nach internen Änderungen, geprüften DNS-Einträgen und getrenntem verwaltetem oder eigenem Versand lässt sich besser untersuchen.

Problematischer Ablauf	Kontrollierter Ablauf
Interne Systeme ändern Nachrichten nach der Signierung	Signierung nach Änderungen am letzten kontrollierten Versandpunkt
Manueller Schlüsselwechsel in mehreren Werkzeugen	Signierung und Schlüsselpflege nach dem Verfahren des verwalteten SMTP-Dienstes
DNS-Änderungen mit doppeltem SPF oder falschen DKIM-Namen	Ein abgestimmter Einrichtungsablauf mit Prüfung jedes Eintrags
Weiterleitung ohne Berücksichtigung von SRS oder ARC	Authentifizierung soweit möglich erhalten und Empfängerbewertung berücksichtigen

Bei TrekMail verwendet Nano eigenen SMTP und wird als kostenloser Tarif angeboten. Kostenpflichtige Tarife werden ab $3.50 monatlich mit verwaltetem SMTP angeboten. Wählen Sie den tatsächlichen Versanddienst passend zu Ihrer gewünschten Schlüsselverwaltung. Bei SES, SendGrid oder Mailgun untersuchen Sie die DKIM-Konfiguration dort. Kostenpflichtige Tarife können eine 14-tägige Testphase mit erforderlicher Kreditkarte bieten. Die aktuellen Preise, Funktionen und Bedingungen finden Sie unter TrekMail-Tarife.

Bei eigenem SMTP sollten Sie DKIM daher im gesamten Versandweg untersuchen. Selektor, Schlüssel und Änderungen nach der Signierung sind naheliegende Prüfstellen; ein Postfachproblem lässt sich daraus allein nicht ableiten.

Abschließende Checkliste bei dkim fail

Behandeln Sie DKIM fail als konkretes Prüfergebnis. Lesen Sie die Details, prüfen Sie Selektor und Signierungsweg und ändern Sie die Konfiguration erst nach einer belastbaren Eingrenzung.

Vor Änderungen im Produktivbetrieb:

Vollständigen Authentifizierungsheader lesen, nicht nur die Zusammenfassung einer Rückmeldung.
Body-Hash-Fehler, Signaturfehler, permerror und temperror unterscheiden.
Genauen Selektor im DNS abfragen.
Vollständigen Schlüssel und korrekte TXT-Zeichenketten prüfen.
Bei internen Änderungen die Signierung hinter diese Verarbeitungsschritte verlegen.
c=relaxed/relaxed auf Eignung prüfen, ohne davon Schutz vor Inhaltsänderungen zu erwarten.
DMARC-Ausrichtung zwischen d= und der sichtbaren Domain in From: kontrollieren.

Bleiben DKIM-Fehler bestehen, untersuchen Sie Signierung, Selektor und verändernde Relays gezielt weiter. Bei vorübergehenden DNS-Fehlern kann eine erneute Prüfung sinnvoll sein; dauerhafte Konfigurationsfehler erfordern eine passende Korrektur.