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.