DKIM schlägt fehl, aber Ihr DNS sieht richtig aus — vermutlich der Selector

Das ist einer der frustrierendsten Zustände beim E-Mail-Setup: Ihr Anbieter sagt, DKIM sei nicht verifiziert, SPF und DMARC bestehen beide, und wenn Sie Ihr DNS abfragen, liegt der DKIM-Key genau dort. Jeder öffentliche DKIM-Checker bestätigt, dass der Record gültig ist.

Sie haben alle recht. Und die Mail wird trotzdem nicht so signiert, wie Ihr Sender es erwartet.

Was ein Selector wirklich ist

DKIM-Keys liegen nicht in der Wurzel Ihrer Domain. Sie liegen unter einem Selector, bei <selector>._domainkey.ihredomain.de. Der Selector ist ein Label, mit dem eine Domain viele Keys gleichzeitig veröffentlichen kann — einen für Ihren Mailhost, einen für Ihr Rechnungssystem, einen für Ihre Marketing-Plattform.

Das ist die ganze Falle. Eine Domain kann völlig legitim mehrere gültige DKIM-Keys haben, und ein Checker, der einen Key findet, meldet bereitwillig, DKIM sei konfiguriert. Signaturprüfung fragt aber nicht, ob die Domain einen Key hat:

1. Das Sendesystem signiert die Nachricht und stempelt den verwendeten Selector in den Header: DKIM-Signature: … s=zc1; d=ihredomain.de.
2. Der Empfänger liest diesen Selector, fragt zc1._domainkey.ihredomain.de ab und prüft gegen diesen Key.

Signiert Ihr Sender mit zc1 und der einzige veröffentlichte Key liegt unter smtp, fragt der Empfänger zc1._domainkey ab, findet nichts, und die Signatur scheitert.

Warum das so häufig passiert

Weil der falsche Key meist ein echter Key ist, den etwas anderes aus gutem Grund dort hinterlegt hat. Liegen Ihre Postfächer irgendwo gehostet, hat dieser Anbieter mit hoher Wahrscheinlichkeit DKIM für seine eigene ausgehende Mail eingerichtet, unter seinem eigenen Selector. Sie fügen dann eine Marketing- oder Transaktionsplattform hinzu, sehen "DKIM" bereits im DNS und schließen nachvollziehbar, dass es erledigt ist. Für Ihren Mailanbieter ist es erledigt — für Ihren neuen Sender nicht.

In zwei Minuten diagnostiziert

Senden Sie sich eine echte Nachricht über den scheiternden Sender und lesen Sie die Roh-Header. In Gmail: Original anzeigen. Suchen Sie nach:

DKIM-Signature: v=1; a=rsa-sha256; s=zc1; d=ihredomain.de; …

Der Wert in s= ist der Selector, den Ihr Sender tatsächlich verwendet — nicht das, was Ihr DNS-Panel zeigt. Fragen Sie genau diesen Namen ab:

dig +short zc1._domainkey.ihredomain.de TXT
dig +short zc1._domainkey.ihredomain.de CNAME

Leere Ausgabe ist Ihre Antwort.

Was es verschlimmert: DMARC

Scheitert DKIM und Ihre DMARC-Policy ist p=quarantine oder p=reject, fehlt Ihnen nicht nur eine Signatur — Sie weisen Mailbox-Anbieter aktiv an, der Mail zu misstrauen. Die Reihenfolge, die funktioniert: Key veröffentlichen, Signatur an einer echten Nachricht verifizieren, danach DMARC verschärfen. Bleiben Sie bei p=none, solange Sie die Authentifizierung noch reparieren.

Was gutes Tooling sagen sollte

"Nicht verifiziert" ist aus mindestens vier verschiedenen Gründen wahr — überhaupt kein Record, ein Record unter einem anderen Selector, ein CNAME auf das falsche Ziel, oder der Key-Host der Plattform selbst ist nicht erreichbar — und nur einer davon ist in Ihrem DNS-Panel behebbar.

Die Domain-Verifizierung von WeZend liefert zu jeder Prüfung einen maschinenlesbaren reason plus einen menschlichen Hinweis — wrong_selector nennt den Selector, unter dem Sie veröffentlicht haben, und den, mit dem wir signieren, und esp_target_unresolved sagt offen, dass das Problem bei uns liegt. Siehe E-Mail: Domains, DNS & Versand, oder prüfen Sie eine Domain im kostenlosen SPF-, DKIM- & DMARC-Checker.

Kurzfassung

• Ein gültiger DKIM-Key in Ihrem DNS bedeutet nicht den richtigen Key für den Sender, den Sie debuggen.
• Der Wert in s= im DKIM-Signature-Header einer echten Nachricht ist der einzige Selector, der zählt.
• Fragen Sie mit dig genau diesen <selector>._domainkey-Namen ab. Leer heißt: gefunden.
• Reparieren Sie die Authentifizierung, bevor Sie DMARC verschärfen — nicht danach.