Aktiven Selektor identifizieren
Eigene Mail an Gmail oder Outlook senden, Header anschauen: DKIM-Signature: … d=example.com; s=selector1; …. s= ist der aktive Selektor.
Werkzeug
Prüft die gängigen Selektoren (default, google, selector1/2, k1, mail u. a.) und meldet, wo ein DKIM-Public-Key gefunden wurde. Wir probieren automatisch die 11 verbreitetsten Selektor-Namen.
Permalink:?domain=… funktioniert auch.
—
——
—
—
DKIM (DomainKeys Identified Mail) ergänzt SPF um eine kryptographische Signatur. Während SPF nur prüft, ob die sendende IP autorisiert ist, signiert DKIM ausgewählte Header-Felder und den Mail-Body mit einem privaten Schlüssel. Empfangende Server holen den dazu passenden Public-Key aus dem DNS und verifizieren — stimmt die Signatur, ist die Mail garantiert unverändert und stammt von einem System, das Zugriff auf den privaten Schlüssel hat.
Der Public-Key wird in einem TXT-Record am Hostnamen <selektor>._domainkey.<domain> abgelegt. Der Selektor ist ein frei wählbarer Name — üblich sind default, google, selector1/selector2, k1, mail. Mehrere Selektoren parallel ermöglichen Key-Rotation ohne Downtime und unabhängige Schlüssel pro Versender.
Eine ankommende Mail trägt im Header eine DKIM-Signature:-Zeile mit Selektor (s=), signierender Domain (d=) und der Signatur. Der Empfänger schlägt den Public-Key nach, verifiziert kryptographisch und meldet das Ergebnis als dkim=pass oder dkim=fail. Für DMARC-Alignment muss zusätzlich d= mit der From-Domain übereinstimmen.
Versand läuft über neuen Selektor, alter ist im DNS verwaist. Prüftools melden ihn als gültig, obwohl er nichts mehr signiert. Aufräumen — sonst wirkt der Record verwirrend bei Debugging.
Vor 2015 Standard, heute zu schwach. Empfehlung: RSA-2048. Prüftools markieren 1024-Bit-Keys oft schon als warn. Rotation auf 2048 Bit ist täglich Brot.
Versender signiert mit Selektor X, im DNS gibt es aber keinen TXT unter X._domainkey.…. Resultat: dkim=fail. Häufig nach Provider-Wechsel oder DNS-Migration.
Zwei Records unter demselben Selektor-Hostnamen → Empfänger nehmen den ersten oder verweigern beide. Pro Selektor exakt ein TXT mit v=DKIM1.
Schlüssel älter als 12 Monate — unkritisch im Normalbetrieb, aber bei Key-Kompromittierung verheerend. Zwei Selektoren parallel betreiben und halbjährlich rotieren ist gängige Praxis.
2048-Bit-Keys passen nicht in einen 255-Byte-String, müssen aufgeteilt werden. Manche DNS-Provider zerlegen automatisch falsch. Test: dig TXT ….
Versender benutzt Custom-Namen wie v1, 2024a. Pauschale Prüftools probieren nur 10–15 Standard-Namen — Custom-Selektor erscheint dann fälschlich als „fehlt“. Manuelles dig nötig.
Eigene Mail an Gmail oder Outlook senden, Header anschauen: DKIM-Signature: … d=example.com; s=selector1; …. s= ist der aktive Selektor.
Beim Versand-Provider neuen Selektor anlegen, Key-Länge 2048 Bit, Public-Key als TXT ins DNS, Versand-System auf den neuen Selektor umstellen.
selector2._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…"
1–2 Wochen warten — in dieser Zeit verteilen Mail-Provider noch Mails mit der alten Signatur aus Caches. Erst dann den alten TXT entfernen.
In den Aggregat-Reports steht pro IP, ob DKIM-Pass + Alignment. Wenn alle Quellen dkim=pass + aligned liefern, ist das Setup sauber.
Der vollständige SelfCheck testet zusätzlich SPF/DKIM/DMARC, BIMI, MTA-STS, TLS-RPT, DNSSEC und MX in einem Durchgang.
Vollständigen SelfCheck starten →<selektor>._domainkey.<domain>. Mehrere Selektoren erlauben parallele Keys für verschiedene Versender oder für Key-Rotation ohne Downtime.warn. Prüfen Sie den Selektor manuell mit dig TXT <selektor>._domainkey.<domain>.d=-Tag mit der From-Domain übereinstimmen.