Einen DKIM-Schlüssel per Selektor abfragen und Typ, echte Schlüssellänge und Probleme sehen
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device.Eine DKIM-Prüfung holt den öffentlichen Schlüssel, den eine Domain unter selector._domainkey.domain veröffentlicht, und liest ihn. RFC 8301 verlangt RSA-Schlüssel mit mindestens 1024 Bit und empfiehlt 2048; ein leeres p= bedeutet, dass der Schlüssel widerrufen wurde. Der Selektor stammt aus dem Tag s= einer signierten Nachricht.
Diese Seite wurde maschinell aus dem englischen Original übersetzt. Die Übersetzung wurde noch von keinem Menschen geprüft; maßgeblich ist die englische Fassung. Englisches Original lesen
Geben Sie die Domain unter Domain und den Selektor unter Selektor (s= in der Signatur) ein.
Drücken Sie DKIM prüfen, um den Schlüssel unter selector._domainkey.domain zu holen.
Lesen Sie Schlüsseltyp und Schlüssellänge, aus dem Schlüssel selbst ermittelt, mit allen Problemen darüber aufgeführt.
Drücken Sie neben dem Schlüsseleintrag auf Kopieren, um ihn zu behalten.
Geben Sie eine Domain und einen Selektor ein, und die Seite fragt einen öffentlichen DNS-over-HTTPS-Resolver nach dem TXT-Eintrag unter dem Selektor, dann ._domainkey., dann der Domain. Die Tags des Eintrags werden so gelesen, wie RFC 6376 Abschnitt 3.6.1 sie definiert: die Version, der Schlüsseltyp, die erlaubten Hash-Algorithmen, die Diensttypen, die Flags und der Schlüssel selbst.
Die Schlüssellänge wird aus dem Schlüssel ermittelt, nicht aus der Länge des Textes geschätzt. Das Base64 in p= wird dekodiert und die darin enthaltene DER-Struktur bis zum RSA-Modulus gelesen, dessen genaue Bitlänge die Schlüsselgröße ist. Ein ed25519-Schlüssel, definiert in RFC 8463, hat immer 256 Bit. RFC 8301 Abschnitt 3.2 besagt, dass Empfänger RSA-Schlüssel unter 1024 Bit ablehnen müssen und Absender 2048 verwenden sollten, und das Ergebnis sagt, auf welcher Seite dieser Grenzen ein Schlüssel liegt.
Andere Probleme werden in klaren Worten aufgeführt: ein leeres p=, das bedeutet, dass der Schlüssel widerrufen wurde; t=y, das die Domain als noch im Test markiert, sodass Empfänger ihre signierte Mail wie unsignierte behandeln; ein h=, das nur sha1 erlaubt, das RFC 8301 abgeschafft hat; und Einträge, die gar kein DKIM sind. Ein Selektor, der wie bei vielen Maildiensten per CNAME woandershin zeigt, wird verfolgt und das Ziel angezeigt.
Den Selektor zu finden ist der schwierige Teil. Es ist der Wert s= im DKIM-Signature-Header einer Nachricht, die die Domain gesendet hat, und das ist der einzige sichere Weg, ihn zu kennen. Die Schaltfläche "Try common selectors" fragt neun Namen ab, die große Anbieter und Hosting-Panels verwenden. Ein Treffer beweist, dass ein Schlüssel existiert; ein Fehlschlag beweist nichts, weil Selektoren beliebige Namen sein können.
Was sie nicht tut: Sie prüft keine Signatur einer Nachricht. Dafür braucht es die Nachricht.
Die Domain und der Selektor, die Sie eingeben, werden an den von Ihnen gewählten Resolver gesendet, weil eine Abfrage sie braucht. Nichts anderes verlässt Ihr Gerät.
Öffnen Sie eine Nachricht, die die Domain gesendet hat, zeigen Sie das Original oder den Quelltext an und suchen Sie den Header DKIM-Signature. Sein Tag s= ist der Selektor, sein Tag d= die Domain. Gängige Selektoren lassen sich erraten, und die Schaltfläche hier probiert neun aus, aber nur der Header sagt es sicher.
RFC 8301 verlangt RSA-Schlüssel mit mindestens 1024 Bit und empfiehlt 2048. Empfänger müssen Schlüssel unter 1024 Bit ablehnen, daher scheitern damit erstellte Signaturen. Schlüssel über 4096 Bit werden womöglich nicht von jedem Empfänger geprüft. Ein ed25519-Schlüssel hat 256 Bit und wird meist neben einem RSA-Schlüssel veröffentlicht.
Ein leeres Tag p= bedeutet, dass der Schlüssel hinter diesem Selektor absichtlich widerrufen wurde. Damit signierte Mail scheitert jetzt bei DKIM. Anbieter veröffentlichen einen widerrufenen Eintrag, wenn sie zu einem neuen Selektor wechseln; ein alter Selektor mit leerem p= ist also normal, wenn aktuelle Mail einen neueren verwendet.
Meist ist der Selektor falsch: Jeder sendende Dienst verwendet seinen eigenen Selektor, und der Name ist frei wählbar. Der Schlüssel ist vielleicht auch noch nicht veröffentlicht, oder der Dienst erwartet einen CNAME-Eintrag, der auf seinen eigenen Schlüssel zeigt. Prüfen Sie zuerst den Wert s= im Header einer echten Nachricht.
Die Domain und der Selektor gehen an den öffentlichen DNS-Resolver, den Sie wählen, Cloudflare oder Google, weil die Abfrage eines Eintrags den Namen braucht. Der Resolver sieht die abgefragten Namen und Ihre IP-Adresse. Nichts anderes verlässt Ihr Gerät, und nichts über die Prüfung wird auf dieser Website gespeichert.
Kommen Sie nicht weiter? Fragen Sie zu DKIM-Prüfung und jeder, der es weiß, kann antworten. Kein Konto nötig.