Was ist der DKIM-Selektor (und warum gibt es mehrere)
Par Thomas · RSSI virtuel · 2026-07-09
Beim Konfigurieren von DKIM taucht immer wieder ein Wort auf, ohne dass man es wirklich erklärt: der Selektor. Man bittet dich, einen DNS-Eintrag unter irgendetwas._domainkey.deine-domain.de hinzuzufügen, und dieses „irgendetwas" ist der Selektor. Zu verstehen, was er ist, räumt mit einem Schlag viele Verwirrungen um DKIM aus — warum es mehrere gibt, wie die Schlüsselrotation funktioniert, und warum eine Signatur fehlschlagen kann, obwohl „der Schlüssel doch da ist". Dieser Leitfaden erklärt den DKIM-Selektor einfach, mit dem, was man in der Praxis wissen muss.
Wozu ein Selektor dient
DKIM beruht auf einem Schlüsselpaar: einem privaten Schlüssel, der deine Nachrichten signiert (von deiner Versandplattform geheim gehalten) und einem öffentlichen Schlüssel, veröffentlicht in deinem DNS, den der Empfänger abruft, um die Signatur zu verifizieren. Aber eine Domain kann mehrere öffentliche Schlüssel gleichzeitig haben — einen pro Versandplattform, zum Beispiel. Woher weiß der Empfänger, welchen er zur Verifikation einer gegebenen Nachricht verwenden soll?
Genau das ist die Rolle des Selektors. Jede zu einer E-Mail hinzugefügte DKIM-Signatur enthält ein s=-Etikett (der Selektor), das dem Empfänger sagt: „Der öffentliche Schlüssel zur Verifikation dieser Nachricht befindet sich an diesem Selektor". Der Selektor ist also ein Zeiger: Er verbindet eine Signatur mit dem richtigen öffentlichen Schlüssel in deinem DNS.
Wo der Selektor auftaucht
Der Selektor lebt an zwei Orten, und es ist nützlich, sie zu verbinden:
- Im
DKIM-Signature-Header der Nachricht, über dass=-Etikett. Zum Beispiel:s=selector1; d=deine-domain.de; .... - In deinem DNS, als
TXT-Eintrag an der Adresse<selektor>._domainkey.<domain>. Fürs=selector1undd=deine-domain.defragt der Empfänger ab:
selector1._domainkey.deine-domain.de
und findet dort den öffentlichen Schlüssel:
selector1._domainkey.deine-domain.de. IN TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkq... (öffentlicher Schlüssel)"
Die Verifikation ist also ein glasklarer Hin- und Rückweg: Der Empfänger liest s= und d= in der Signatur, baut die DNS-Adresse zusammen, ruft den öffentlichen Schlüssel ab und verifiziert. Wenn der Schlüssel nicht da ist oder nicht passt, schlägt die Signatur fehl.
Warum du oft mehrere Selektoren hast
Das ist der Punkt, der überrascht. Eine Domain hat fast nie einen einzigen Selektor, und das ist normal:
- Eine Plattform = ein Selektor (mindestens). Wenn du über Microsoft 365, einen Marketing-Router und ein Rechnungstool versendest, hat jeder seinen eigenen DKIM-Schlüssel, also seinen eigenen Selektor. Du veröffentlichst einen
TXT-Eintrag pro Selektor. - Die Schlüsselrotation erzeugt Selektoren. Wenn du einen DKIM-Schlüssel erneuerst, veröffentlichst du einen neuen Schlüssel unter einem neuen Selektor, schaltest die Signatur darauf um und entfernst dann den alten. Während des Übergangs koexistieren zwei Selektoren (siehe Schlüsselrotation).
- Die Subdomains können ihre eigenen Selektoren haben.
Mehrere Selektoren zu haben ist also kein Problem — es ist das erwartete Funktionieren. Jeder Selektor ist unabhängig, und ein Empfänger verwendet nur den, der in der Signatur angegeben ist, die er verifiziert.
Wie ein Selektorname aussieht
Der Name des Selektors ist frei, und jede Plattform hat ihre Konventionen. Du wirst zum Beispiel selector1/selector2 (Microsoft 365), google (Google Workspace), datierte Namen wie s1024-2024 oder von einem Dienstleister erzeugte Zeichenketten antreffen. Der Name hat keine technische Bedeutung: Was zählt, ist, dass der Selektor der Signatur einem existierenden DNS-Eintrag entspricht. Unnötig also, einen verborgenen Sinn in einem Selektornamen zu suchen — es ist bloß ein Etikett.
Wie du einen DKIM-Selektor aktivierst
In der Praxis „erstellst" du keinen Selektor von Hand: Deine Versandplattform erzeugt ihn für dich und gibt dir den zu veröffentlichenden DNS-Eintrag (oft ein CNAME, der auf einen vom Dienstleister verwalteten Eintrag zeigt, oder ein TXT mit dem öffentlichen Schlüssel). Deine Arbeit beschränkt sich auf:
- DKIM aktivieren in der Konsole der Plattform (Microsoft 365, Google Workspace, dein Router …).
- Den gelieferten Eintrag veröffentlichen am angegebenen Selektor.
- Prüfen, dass die Signatur durchgeht und aligned ist (siehe wie man eine E-Mail-Signatur verifiziert).
Der CNAME ist oft dem rohen TXT vorzuziehen: Er lässt den Dienstleister den Schlüssel rotieren, ohne dass du dein DNS anrühren musst.
Das Alignment: der Selektor macht nicht alles
Ein entscheidender Punkt für DMARC. Eine gültige DKIM-Signatur beweist, dass eine Domain die Nachricht signiert hat — aber für DMARC muss diese Domain (d=) sich obendrein mit der deines From: alignen. Der Selektor betrifft nur das Abrufen des Schlüssels; es ist das d=-Etikett, das das Alignment trägt. Du kannst also eine vollkommen gültige Signatur haben, die für DMARC nicht zählt, weil das d= das des Dienstleisters ist, nicht deins. Die Lösung ist, auf jeder Plattform eine markeneigene Signatur (d=deine-domain.de) zu konfigurieren. Dieser Mechanismus ist im Detail beschrieben in wie die drei Protokolle zusammenarbeiten.
Einen Selektor debuggen
Wenn eine DKIM-Signatur fehlschlägt, ist oft der Selektor die Ursache. Die klassischen Spuren:
- Der DNS-Eintrag des Selektors fehlt oder ist schlecht veröffentlicht (Tippfehler im Namen, falsche Subdomain
._domainkey). - Der öffentliche Schlüssel wurde abgeschnitten beim Kopieren-Einfügen (die Schlüssel sind lang; ein fehlendes Zeichen bricht die Verifikation).
- Der Selektor der Signatur entspricht keinem Eintrag — typischerweise nach einer schlecht abgeschlossenen Rotation, bei der man den alten Selektor entfernt hat, bevor man die Signatur umgeschaltet hatte.
- Die DNS-Propagation ist nicht abgeschlossen: Ein frisch veröffentlichter Selektor kann etwas Zeit brauchen, um überall sichtbar zu sein.
Um es zu bestätigen, frag den Selektor direkt im DNS ab (dig TXT selector1._domainkey.deine-domain.de) und prüfe, dass der öffentliche Schlüssel gut da und vollständig ist.
Häufige Fragen
Wie viele Selektoren kann ich haben? So viele wie nötig — es gibt kein störendes Limit. Eine Plattform pro Selektor, plus die vorübergehend durch die Rotation erzeugten. Mehrere Selektoren zu haben ist gesund, nicht problematisch.
Kann ich einen alten Selektor löschen? Ja, aber nur, wenn keine Signatur ihn mehr verwendet (typischerweise nach einer abgeschlossenen Rotation). Einen noch von Nachrichten im Transit referenzierten Selektor zu löschen bricht deren Verifikation.
Ist der Selektor geheim? Nein. Der Selektor und der öffentliche Schlüssel sind von Natur aus öffentlich (sie stehen im DNS und in jeder signierten E-Mail). Es ist der private Schlüssel auf Seiten der Versandplattform, der geheim bleiben muss.
Warum gibt mir mein Dienstleister einen CNAME statt eines TXT? Um den Schlüssel für dich rotieren zu können, ohne dass du bei jeder Rotation dein DNS anrührst. Das ist im Allgemeinen die richtige Option: Du veröffentlichst einmal, der Dienstleister verwaltet den Rest.
Können zwei Plattformen einen Selektor teilen? In der Theorie, aber es ist abzuraten: Jede Plattform hat ihren eigenen Schlüssel, also ihren eigenen Selektor. Das Mischen erschwert das Debugging und die Rotation.
Eine Verifikation nachvollziehen, Schritt für Schritt
Um die Rolle des Selektors zu verankern, folgen wir einer echten Nachricht. Du schickst eine Rechnung von unternehmen.de über deine Plattform, die mit s=mail2025; d=unternehmen.de signiert. Hier ist, was der empfangende Server tut:
- Er liest den
DKIM-Signature-Header und findet dorts=mail2025undd=unternehmen.de. - Er baut die DNS-Adresse zusammen:
mail2025._domainkey.unternehmen.de. - Er fragt diese Adresse ab und ruft den veröffentlichten öffentlichen Schlüssel ab.
- Er berechnet den Hash der Nachricht neu und vergleicht ihn mit der Signatur. Wenn alles übereinstimmt:
dkim=pass. - Er prüft schließlich, dass
d=unternehmen.deder Domain desFrom:entspricht — das Alignment, unverzichtbar für DMARC.
Wenn einer dieser Schritte fehlschlägt — Selektor nicht auffindbar, Schlüssel abgeschnitten, abweichender Hash — geht die Signatur nicht durch. Diese Kette zu verstehen erlaubt dir, jeden Fehler zu diagnostizieren: Du weißt genau, wo du schauen musst und in welcher Reihenfolge.
Seine Selektoren sauber organisieren
Mit der Zeit häuft eine Domain Selektoren an: einen pro Plattform, plus die von alten Rotationen zurückgelassenen. Ein paar Prinzipien vermeiden das Chaos. Gib deinen Selektoren sprechende und datierte Namen, wenn du sie kontrollierst (mail-2025, router-marketing), statt undurchsichtiger Zeichenketten: Du findest schneller wieder, welcher wozu dient. Führe ein einfaches Inventar — welcher Selektor für welche Plattform, seit wann — ebenso wie dein Inventar der Versandquellen. Und vor allem, entferne die toten Selektoren, sobald ihre Rotationen abgeschlossen sind: Ein verwaister Selektor ist nicht gefährlich, aber er stört und verwirrt die Diagnose an dem Tag, an dem eine Signatur fehlschlägt. Ein gut geführtes DNS ist ein DNS, in dem jeder _domainkey-Eintrag einen bekannten Daseinsgrund hat — das verwandelt ein einstündiges Debugging in einen zweiminütigen Blick.
Selektor und Subdomains: ein Fall, den man kennen sollte
Ein Punkt, der oft überrascht: Die Subdomains „erben" nicht den Selektor der Wurzeldomain. Wenn du von news.unternehmen.de versendest, braucht diese Subdomain ihren eigenen DKIM-Eintrag — zum Beispiel mail._domainkey.news.unternehmen.de — und die Signatur muss d=news.unternehmen.de angeben, damit das DMARC-Alignment korrekt ist. Wurzeldomain und Subdomains sind unabhängig, mit ihren eigenen Selektoren und ihren eigenen Schlüsseln. Diese Realität wird oft ignoriert, wenn man DKIM nur für die Hauptdomain konfiguriert und sich dann fragt, warum die Marketing-Versendungen oder die automatisierten Benachrichtigungen sich in den DMARC-Berichten nicht alignen. Bevor du dich fragst „ist mein Schlüssel gut?", prüfe zuerst „habe ich auch für jede versendende Domain und Subdomain einen Schlüssel veröffentlicht?"
Lass Thomas deine Selektoren kartografieren
Zwischen den Selektoren jeder Plattform und denen, die alte Rotationen zurückgelassen haben, verliert man leicht den Überblick. Thomas, dein virtueller CISO, identifiziert jede Versandquelle, spürt den Selektor auf, den sie verwendet, prüft, dass der öffentliche Schlüssel gut veröffentlicht ist und dass die Signatur sich mit deiner Domain aligned — und meldet dir die toten Selektoren, die aufzuräumen sind.
Analysiere deine Domain kostenlos → oder leg ein Konto an, um in deinen DKIM-Schlüsseln klar zu sehen.
Prêt à appliquer DMARC ?
Atteindre p=reject — gratuitGuides liés
- SPF für Microsoft 365 und Google Workspace: die Konfiguration, die funktioniert
SPF für Microsoft 365 und Google Workspace konfigurieren, getrennt oder gemeinsam, ohne das Limit von 10 Lookups zu überschreiten. Die richtigen include, die Fallen und die Strategie für Drittanbieter.
- SPF PermError: Was das bedeutet und wie du es behebst
Ein SPF PermError bedeutet, dass dein Eintrag nicht auswertbar ist — also ignoriert wird. Die Ursachen (10 Lookups, Syntax, Void Lookups, doppelter Eintrag), wie du sie diagnostizierst und behebst.
- Wie man seinen SPF-Eintrag prüft (und worauf zu achten ist)
Seinen SPF zu prüfen heißt nicht nur zu bestätigen, dass er existiert: Es heißt, seine Syntax, seine Auflösungszählung, seine Qualifikation und seine Ausrichtung zu lesen. Der komplette Leitfaden, Schritt für Schritt.
À propos de l'auteur
Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.
