DKIM-Checker:
ist Ihr Schlüssel stark genug?

Geben Sie oben Ihre Domain ein — der Selektor ist optional. Wir holen den TXT-Eintrag unter selector._domainkey.yourdomain (bei leerem Feld fragen wir zehn gängige Selektoren ab), prüfen jedes Tag gegen RFC 6376 und nehmen uns dann den Schlüssel selbst vor: Der Wert in p= wird aus base64 dekodiert, die DER-Struktur darin Feld für Feld durchlaufen, der Modulus vermessen und bewertet — unter 1024 Bit ist schwach, 1024 akzeptabel, ab 2048 empfohlen. Kostenlos, ohne Anmeldung.

Der Selektor ist der Name vor ._domainkey — vergeben von dem, der die Signierung eingerichtet hat, und über keine DNS-Auflistung sichtbar. Drei Wege dorthin: Öffnen Sie eine gesendete Nachricht und lesen Sie das s=-Tag im DKIM-Signature-Header (in Gmail über »Original anzeigen«); fügen Sie diesen kompletten Header hier ein, dann lesen wir ihn aus; oder lassen Sie das Feld leer, dann fragen wir die zehn häufigsten Standards ab — google, selector1/2, k1/k2, s1/s2, default, dkim, mail. Zwei aktive Selektoren zu finden ist normal — so sieht funktionierende Rotation aus.

Akzeptabel, in die Jahre gekommen und einen Termin im Kalender wert. RSA-1024 hat noch niemand öffentlich faktorisiert — aber NIST hat es schon 2013 für neue Signaturen untersagt, RFC 8301 sagt den DKIM-Signierern, sie sollten 2048 verwenden, und die großen Mailanbieter signieren selbst mit 2048. Der Notfall ist nicht 1024 — der Notfall ist 512, faktorisiert 2012 auf gemieteter Rechenleistung. Es ist der Schlüssel, den Sie nach Ihrem Zeitplan wechseln statt irgendwann nach dem eines Angreifers.

Testmodus. RFC 6376 §3.6.1 weist Prüfsysteme an, Mail aus einer Domain im Testmodus nicht anders zu behandeln als unsignierte Mail — selbst wenn die Signatur einwandfrei aufgeht. Es gibt das Flag, damit Sie DKIM bei der Einführung folgenlos im Trockenlauf fahren können. Der Haken: Es funktioniert zu gut. Solange es gesetzt ist, geht nichts kaputt, also wird es nie entfernt. Ihre Domain signiert dann jahrelang Mail, ohne dafür etwas zu bekommen. Findet dieses Tool eines, besteht die Behebung darin, vier Zeichen zu löschen.

Ein bewusster Widerruf. RFC 6376 definiert ein leeres p= als »Dieser öffentliche Schlüssel wurde widerrufen«. Für einen stillgelegten Selektor ist das die richtige Markierung und klarer, als den Eintrag zu löschen, denn eine Löschung sieht aus wie ein Tippfehler. Daraus folgen zwei Lesarten. Haben Sie diesen Selektor abgelöst und signiert nichts mehr damit, ist es Hygiene: stehen lassen. Signiert dagegen noch irgendein Absender damit, scheitert gerade jede dieser Nachrichten an DKIM. Prüfen Sie Ihre DMARC-Berichte auf dkim=fail mit diesem Selektor.

Prüfsysteme müssen bis 4096 unterstützen (RFC 8301). Nur ergibt ein Schlüssel mit 4096 Bit einen TXT-Wert, der lang genug ist, um in Teilstrings zerlegt werden zu müssen — und daran scheitern manche Oberflächen von DNS-Anbietern. Gegenüber 2048 bringt er keine praktische Sicherheit für einen Schlüssel, den Sie ohnehin rotieren sollten; deshalb ist 2048 der beste Kompromiss. Die andere Richtung ist k=ed25519 (RFC 8463): winzige 32-Byte-Schlüssel, moderne Kryptografie. Die Unterstützung auf Prüfseite ist noch nicht flächendeckend, deshalb signieren Installationen, die ihn einsetzen, meist zusätzlich mit RSA. Dieses Tool liest k= und sagt Ihnen, was Sie veröffentlicht haben.

Allein — nein, und das sagen wir lieber deutlich. DKIM belegt zwei Dinge: die Nachricht wurde seit der Signierung nicht verändert, und die Domain aus d= steht für sie ein. Es belegt nicht, dass die From:-Zeile, die Ihr Leser sieht, zu dieser Domain passt — ein Fälscher kann tadellos mit seiner eigenen Domain signieren und dabei Ihre anzeigen. Diese Lücke schließt DMARC (Alignment), und welche Server überhaupt senden dürfen, sagt SPF. Der funktionierende Aufbau heißt SPF + DKIM + DMARC. Dieses Tool stellt sicher, dass das DKIM-Bein trägt — ein widerrufener Schlüssel oder ein Testmodus zieht den beiden anderen still den Boden weg.