DKIM-Record prüfen — Selector nachschlagen und Schlüssel bewerten

Warum DKIM anders funktioniert als SPF und DMARC

SPF steht immer im TXT-Record der Domain, DMARC immer unter _dmarc. Beide lassen sich nachschlagen, wenn man nur den Domainnamen kennt. Bei DKIM ist das anders: Der Schlüssel steht unter <selector>._domainkey.<domain>, und der Selector ist ein frei gewählter Name.

Selectors lassen sich aus dem DNS nicht aufzählen. Es gibt keine Abfrage, die alle _domainkey-Einträge einer Domain zurückgibt — DNS beantwortet nur die Frage nach einem konkreten Namen. Wer den Selector nicht kennt, hat genau zwei Wege: ihn aus dem s=-Tag einer echten Signatur ablesen, oder die Namen durchprobieren, die bekannte Anbieter fest vergeben.

Was dieses Tool prüft

• Gezielter Lookup, wenn du einen Selector angibst.
• 26 feste Selector-Namen, wenn du keinen angibst — google (Google Workspace), selector1/selector2 (Microsoft 365), k1 bis k3 (Mailchimp), s1/s2 (SendGrid), fm1 bis fm3 (Fastmail), protonmail, zoho und die üblichen Eigennamen.
• Exakte Schlüssellänge — der Schlüssel wird tatsächlich geparst, nicht aus der Länge des Base64-Blocks geschätzt. Eine Schätzung liegt an den Rändern daneben: 3072 Bit fällt in denselben Längenbereich wie 4096.
• Bewertung nach RFC 8301 — unter 1024 Bit unzulässig, unter 2048 nicht mehr empfohlen, sha1 abgelehnt.
• Testmodus und Widerruf — t=y markiert den Record als Test und erlaubt Empfängern, ein Scheitern zu ignorieren; ein leeres p= zieht den Schlüssel ausdrücklich zurück.
• Wildcard-Erkennung — antwortet die Domain auf jeden erfundenen Selector, gibt es einen Eintrag unter *._domainkey. Dann „existiert" jeder geratene Name, und Durchprobieren sagt nichts aus. Das Tool prüft das vorab und sagt es dazu.

Kein Treffer heißt nicht „kein DKIM"

Das ist die wichtigste Einschränkung dieses Tools. Wenn keiner der 26 Namen antwortet, kann die Domain trotzdem sauber signieren — nur eben unter einem Selector, den niemand raten kann. Amazon SES etwa vergibt je Domain einen Zufallstoken; solche Namen stehen bewusst nicht in der Liste, weil das Raten daran scheitern muss.

Umgekehrt beweist ein gefundener Schlüssel nur, dass ein Schlüssel veröffentlicht ist. Ob damit tatsächlich signiert wird, ob die Signatur verifiziert und ob sie zur Domain im From-Header ausgerichtet ist, steht nicht im DNS.

Was dieser Check nicht sehen kann

Die Verifikation selbst braucht die Nachricht. Der Body-Hash wird über den Nachrichtentext gerechnet, und welche Kopfzeilen die Signatur abdeckt, steht im h=-Tag der Signatur — nicht im DNS-Record. Ebenso das Alignment mit DMARC. Für all das sende eine beliebige E-Mail an hello@analyzemy.email; die Antwort enthält den vollständigen Report inklusive DKIM-Verifikation.