DKIM-Selector finden und DKIM-Schlüssel prüfen

So steht DKIM im Kopf einer Mail, gekürzt auf die Teile, die hier zählen:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=beispiel.example; s=selector1;
        h=From:Date:Subject:Message-ID:To;
        bh=…; b=…
Authentication-Results: mx.empfaenger.example;
       dkim=pass header.d=beispiel.example header.s=selector1

Der DKIM-Selector ist der Wert hinter s=, hier selector1. Zusammen mit der Domain hinter d= ergibt er den Namen, unter dem der Empfänger den öffentlichen Schlüssel im DNS sucht: erst der Selector, dann _domainkey, dann die Domain. So legt es RFC 6376 fest. Der Selector ist frei wählbar und erlaubt einer Domain, mehrere Schlüssel gleichzeitig zu veröffentlichen, etwa einen für das Postfach und einen für den Newsletter-Dienst.

Wer unter den üblichen Namen keinen Schlüssel findet, hat damit nicht bewiesen, dass die Domain kein DKIM hat. Es gibt kein Verzeichnis aller Selector einer Domain, und der Name kann alles sein, von k1 bis zu einem Datum. Sicher weiß man es nur aus einer echten Mail.

Den Selector finden#

Drei Wege, vom sichersten zum unsichersten:

1. Aus dem Header einer Mail. Eine Mail von der Domain an ein eigenes Postfach schicken, den vollständigen Nachrichtenkopf öffnen und nach DKIM-Signature suchen. Wie man den Kopf insgesamt liest, steht in E-Mail-Header lesen. Wie man den Kopf in Gmail, Outlook, Apple Mail und Thunderbird anzeigt, steht in E-Mail-Spoofing erkennen. Stehen dort mehrere Signaturen, hat jeder beteiligte Dienst seine eigene. Für DMARC zählt die, deren d= zur Domain im From: passt.
2. Beim Anbieter nachsehen. Microsoft 365 verwendet für jede eigene Domain die beiden Namen selector1 und selector2, jeweils als CNAME auf einen Eintrag bei Microsoft. Google Workspace schlägt google vor. Andere Dienste zeigen den Namen in ihrer DNS-Anleitung, meist zusammen mit dem Eintrag, den man anlegen soll.
3. Gängige Namen durchprobieren. Das ist ein Notbehelf, mehr nicht. Ein Treffer zeigt, dass unter diesem Namen ein Schlüssel liegt. Ob mit ihm auch signiert wird, sagt er nicht.

Die Domain hinter d= ist dabei so wichtig wie der Selector. Ein Newsletter-Dienst, der mit seiner eigenen Domain signiert, liefert dkim=pass, hilft deiner Domain bei DMARC aber nicht. Wie SPF und DKIM mit der sichtbaren Absenderadresse zusammenhängen, steht in DMARC einrichten.

Den Schlüssel abfragen#

Mit dem Selector ist der Rest eine einzige DNS-Abfrage. Unter Linux und macOS:

dig +short TXT selector1._domainkey.beispiel.example

Unter Windows:

nslookup -type=TXT selector1._domainkey.beispiel.example

Ohne Kommandozeile geht es im Browser über DNS-over-HTTPS, etwa bei Google Public DNS:

https://dns.google/resolve?name=selector1._domainkey.beispiel.example&type=TXT

Zurück kommt ein TXT-Eintrag, bei Microsoft 365 vorher ein CNAME, der auf den eigentlichen Eintrag zeigt:

selector1._domainkey.beispiel.example.  CNAME  selector1-beispiel-example._domainkey.<präfix>.onmicrosoft.com.
selector1-beispiel-example._domainkey.<präfix>.onmicrosoft.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB…"

Die Felder, die man lesen muss (RFC 6376, Abschnitt 3.6.1):

• p= ist der öffentliche Schlüssel, Base64-kodiert. Ist p= leer, ist der Schlüssel widerrufen, und jede Signatur mit diesem Selector scheitert.
• k= nennt das Verfahren. Fehlt es, gilt rsa. ed25519 ist das neuere Verfahren aus RFC 8463.
• t=y heißt Testbetrieb: Empfänger behandeln die Mail wie unsigniert, auch wenn die Signatur stimmt. t=s verlangt, dass die Domain in i= exakt d= entspricht und keine Subdomain ist.
• h= beschränkt die erlaubten Hashverfahren, meist auf sha256.

Wie das an einem vollständigen Eintrag aussieht, ist in DMARC einrichten an cyberscale.io durchgerechnet.

Die Schlüssellänge ablesen#

Die Länge eines RSA-Schlüssels steht nicht im Eintrag, man liest sie am Anfang von p= ab. Der Wert ist ein kodierter Schlüssel, und dessen erste Zeichen hängen von der Länge ab:

Auch die Länge von p= verrät es: In der Messung unten waren alle 47 Schlüssel mit 1024 Bit 216 Zeichen lang, alle 66 mit 2048 Bit 392 Zeichen.

RFC 8301 regelt, was gilt: Signierende müssen RSA-Schlüssel mit mindestens 1024 Bit verwenden und sollen mindestens 2048 Bit verwenden. Empfänger müssen Schlüssel von 1024 bis 4096 Bit prüfen können und dürfen Signaturen mit weniger als 1024 Bit nicht als gültig werten. Ein 1024-Bit-Schlüssel ist also erlaubt, aber unter der Empfehlung. Google Workspace empfiehlt 2048 Bit und bietet 1024 nur für DNS-Anbieter an, die keine langen TXT-Einträge zulassen.

Bei Microsoft 365 lohnt der Blick besonders. Wer DKIM per PowerShell einrichtet, bekommt laut Microsoft-Dokumentation ohne Angabe 1024 Bit. Umstellen lässt es sich mit Rotate-DkimSigningConfig -Identity <Domain> -KeySize 2048. Die Umstellung braucht vier Tage und gilt zuerst nur für den nächsten aktiven Selector, der andere bekommt die neue Länge erst bei der folgenden Rotation.

Messung: 146 Tiroler Domains, 40 Selector-Namen#

In eigener Sache: In der Nacht auf den 04.10.2026 (23:42 UTC) habe ich für 146 Tiroler Domains je 40 gängige Selector-Namen abgefragt, darunter selector1, selector2, google, default, k1 bis k3 und die Namen einiger Newsletter-Dienste. Es sind dieselben Domains wie in E-Mail abgelehnt: 550 5.7.1: 34 Tourismusverbände und 115 Betriebe, drei davon existieren nicht mehr. Die Abfrage lief über DNS-over-HTTPS bei Cloudflare, rein passiv. Die Schlüssellänge habe ich aus dem Schlüssel selbst berechnet, nicht geschätzt.

• Bei 59 Domains liefert mindestens einer der 40 Namen einen Schlüssel, zusammen 113 Schlüssel. Bei den übrigen 87 heißt das nur: nicht unter diesen Namen.
• Alle 113 sind RSA. Kein einziger Ed25519-Schlüssel, kein widerrufener mit leerem p=, keiner im Testbetrieb t=y.
• 47 der 113 Schlüssel haben 1024 Bit. Auf Domains umgerechnet: 34 der 59 veröffentlichen mindestens einen solchen, 20 davon ausschließlich.

Microsoft 365 ist mit 39 Domains der häufigste Dienst, und 19 davon haben mindestens einen Schlüssel mit 1024 Bit. Das passt zur Voreinstellung oben. Beim Selector mailjet sind es 10 von 11. Auffällig ist noch etwas: Bei 26 der 39 Microsoft-Domains liefert nur einer der beiden Selector einen Schlüssel, der andere CNAME zeigt auf keinen Eintrag. Das ist kein Fehler. Microsoft beschreibt selbst, dass immer nur ein Selector aktiv ist und der zweite erst bei einer Rotation zum Zug kommt.

Und eine Verbindung zur SPF-Messung: Von den 22 Domains, bei denen SPF nie besteht, liefern nur 3 unter den 40 Namen einen DKIM-Schlüssel. Bei den anderen 19 lässt sich von außen nicht feststellen, ob sie überhaupt signieren. Namen nenne ich auch hier nicht. Den eigenen Stand zeigt der E-Mail-Check.

Wenn dkim=fail im Header steht#

RFC 6376 nennt die Gründe, aus denen ein Empfänger eine Signatur verwirft. Die Texte stehen oft wörtlich in Authentication-Results:

Eine gescheiterte Signatur bei einer weitergeleiteten Mail ist oft kein Fehler des Absenders. Mailinglisten verändern Mails und brechen DKIM damit absichtlich. Wo das häufig vorkommt, hilft die DMARC-Auswertung, die solche Wege sichtbar macht.

Den Schlüssel wechseln#

RFC 6376 beschreibt den Wechsel so: einen neuen Schlüssel unter einem neuen Selector veröffentlichen, beide eine Übergangszeit lang parallel stehen lassen, dann mit dem neuen signieren und den alten entfernen oder mit leerem p= widerrufen. Denselben Selector mit einem neuen Schlüssel zu überschreiben rät der Standard ab. Mails, die noch unterwegs sind oder später geprüft werden, scheitern sonst an signature did not verify.

Microsoft 365 erledigt den Wechsel selbst, wenn man ihn im Verwaltungsbereich oder per Rotate-DkimSigningConfig auslöst. Dafür liegen die zwei Selector bereit, und der Wechsel dauert vier Tage.

Was nicht hilft#

Eine Selector-Liste abarbeiten und aus „nichts gefunden“ „kein DKIM“ schließen. In der Messung oben liefert bei 87 von 146 Domains keiner von 40 Namen einen Schlüssel. Bei wie vielen davon wirklich keiner existiert, weiß niemand, der keine Mail von ihnen hat.

Einen zweiten TXT-Eintrag unter denselben Selector legen, weil der Anbieter einen neuen Schlüssel ausgegeben hat. RFC 6376 lässt den Empfänger bei mehreren Einträgen frei wählen, welchen er nimmt. Das Ergebnis sind Signaturen, die mal bestehen und mal nicht.

Den Schlüssel im DNS tauschen, ohne dass der Server mit dem neuen privaten Schlüssel signiert. Der öffentliche Schlüssel allein ändert nichts, außer dass jede Signatur scheitert.

Auf 4096 Bit gehen, um ganz sicher zu sein. Empfänger müssen nach RFC 8301 bis 4096 Bit prüfen können, darüber nicht. Manche DNS-Anbieter begrenzen die Länge von TXT-Einträgen, darauf weist auch Google hin. 2048 Bit sind die Empfehlung, und sie passen überall hinein.

Häufige Fragen#

Was ist ein DKIM-Selector?#

Der Name, unter dem der öffentliche DKIM-Schlüssel einer Domain im DNS liegt, als Teil von <selector>._domainkey.<domain>. In jeder signierten Mail steht er im Feld DKIM-Signature hinter s=.

Wie finde ich den DKIM-Selector meiner Domain?#

Am sichersten im Header einer eigenen Mail: DKIM-Signature suchen, s= und d= ablesen. Bei Microsoft 365 heißen die Selector selector1 und selector2, bei Google Workspace standardmäßig google.

Ist ein DKIM-Schlüssel mit 1024 Bit noch erlaubt?#

Ja. RFC 8301 verlangt mindestens 1024 Bit und empfiehlt mindestens 2048. Wer kann, stellt auf 2048 um. Bei Microsoft 365 geht das mit einer Schlüsselrotation.

Was bedeutet „body hash did not verify“?#

Der Text der Mail wurde nach dem Signieren verändert, meist durch eine Mailingliste, einen angehängten Haftungsausschluss oder einen Virenscanner. Die Signatur selbst kann in Ordnung sein. Sie passt nur nicht mehr zum veränderten Text.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Das Paket E-Mail-Schutz richtet DKIM für jeden Versandweg mit der eigenen Domain ein, stellt alte Schlüssel auf 2048 Bit um und führt SPF und DMARC dazu, ohne dass Rechnungen oder Newsletter hängen bleiben. Vorher kostenlos selbst prüfen: der E-Mail-Check.

Stand 04.10.2026. Quellen an diesem Tag abgerufen, DNS-Messung in der Nacht auf den 04.10.2026.

Quellen#

• RFC 6376: DKIM: Selector (3.1), Tags s=, d=, bh= (3.5), Schlüsseleintrag mit p=, k=, t=y, t=s (3.6.1), DNS-Name (3.6.2.1), Prüfschritte und Fehlergründe wie no key for signature, key revoked, body hash did not verify (6.1.2, 6.1.3), Schlüsselwechsel über neue Selector (3.1)
• RFC 8301: Kryptografische Anforderungen an DKIM: mindestens 1024 Bit, empfohlen 2048, Prüfung bis 4096 Bit, rsa-sha1 nicht mehr zulässig
• RFC 8463: Ed25519 für DKIM: k=ed25519, Doppelsignatur mit getrennten Selector
• Microsoft Learn: DKIM für eigene Domains: CNAME selector1/selector2, nur ein Selector aktiv, KeySize mit Voreinstellung 1024, Rotate-DkimSigningConfig, vier Tage bis zur Umstellung
• Google Workspace: DKIM einrichten: Standard-Selector google, 2048 Bit empfohlen, 1024 bei begrenzten TXT-Einträgen
• RFC 2606: Beispieldomains (.example)
• Eigene Messung: DKIM-Einträge unter 40 Selector-Namen für 146 Tiroler Domains (34 Tourismusverbände, 115 Betriebe, davon 3 nicht mehr existent) am 03.10.2026 um 23:42 UTC per DNS-over-HTTPS (Cloudflare), passiv; Schlüssellänge aus dem Modulus berechnet. Veröffentlicht werden nur Summen, keine Namen.