Was ist der DKIM-Selektor (und warum gibt es mehrere)

selector1._domainkey.beispiel.de

selector1._domainkey.beispiel.de.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq... (öffentlicher Schlüssel)"

Warum es oft mehrere Selektoren gibt

Das ist der Punkt, der überrascht. Eine Domain hat fast nie einen einzigen Selektor, und das ist normal:

• Eine Plattform = ein Selektor (mindestens). Läuft der Versand über Microsoft 365, einen Marketing-Router und ein Rechnungstool, hat jeder seinen eigenen DKIM-Schlüssel, also seinen eigenen Selektor. Veröffentlicht wird ein TXT-Eintrag pro Selektor.
• Die Schlüsselrotation erzeugt Selektoren. Bei der Erneuerung eines DKIM-Schlüssels wird ein neuer Schlüssel unter einem neuen Selektor veröffentlicht, die Signatur darauf umgeschaltet und dann der alte entfernt. 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. Anzutreffen sind zum Beispiel selector1/selector2 (Microsoft 365), google (Google Workspace), datierte Namen wie s1024-2024 oder von einem Dienstleister erzeugte Zeichenketten. 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.

Einen DKIM-Selektor aktivieren

In der Praxis wird kein Selektor von Hand „erstellt": Die Versandplattform erzeugt ihn und liefert 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). Die Arbeit beschränkt sich auf:

1. DKIM aktivieren in der Konsole der Plattform (Microsoft 365, Google Workspace, der eigene Router …).
2. Den gelieferten Eintrag veröffentlichen am angegebenen Selektor.
3. 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 das DNS angerührt werden muss.

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 des From: alignen. Der Selektor betrifft nur das Abrufen des Schlüssels; es ist das d=-Etikett, das das Alignment trägt. Eine vollkommen gültige Signatur kann also für DMARC nicht zählen, weil das d= das des Dienstleisters ist, nicht das der Marke. Die Lösung ist, auf jeder Plattform eine markeneigene Signatur (d=beispiel.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.

Zur Bestätigung wird der Selektor direkt im DNS abgefragt (dig TXT selector1._domainkey.beispiel.de) oder über den kostenlosen DKIM-Prüfer, und geprüft, 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 rotieren zu können, ohne dass bei jeder Rotation das DNS angerührt wird. Das ist im Allgemeinen die richtige Option: einmal veröffentlichen, 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. Eine Rechnung geht von unternehmen.de über eine Plattform raus, die mit s=mail2025; d=unternehmen.de signiert. Hier ist, was der empfangende Server tut:

1. Er liest den DKIM-Signature-Header und findet dort s=mail2025 und d=unternehmen.de.
2. Er baut die DNS-Adresse zusammen: mail2025._domainkey.unternehmen.de.
3. Er fragt diese Adresse ab und ruft den veröffentlichten öffentlichen Schlüssel ab.
4. Er berechnet den Hash der Nachricht neu und vergleicht ihn mit der Signatur. Wenn alles übereinstimmt: dkim=pass.
5. Er prüft schließlich, dass d=unternehmen.de der Domain des From: 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, jeden Fehler zu diagnostizieren: Der Ort des Blicks und seine Reihenfolge stehen dann fest.

Die 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. Selektoren verdienen sprechende und datierte Namen, wo sie kontrollierbar sind (mail-2025, router-marketing), statt undurchsichtiger Zeichenketten: So findet sich schneller wieder, welcher wozu dient. Ein einfaches Inventar — welcher Selektor für welche Plattform, seit wann — gehört dazu, ebenso wie das Inventar der Versandquellen. Und vor allem gilt es, die toten Selektoren zu entfernen, 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.

Lassen sich Selektoren von außen auflisten?

Eine Frage, die in Sicherheitsaudits regelmäßig auftaucht: Da Selektoren öffentlich sind, kann ein Außenstehender dann alle DKIM-Schlüssel einer Domain aufzählen? In der Praxis nein — das DNS bietet keine Möglichkeit zu fragen „gib mir jeden Eintrag unter _domainkey". Ein Dritter entdeckt einen Selektor nur, indem er eine damit signierte Nachricht erhält oder gängige Namen wie selector1 oder google errät. Das schneidet in beide Richtungen. Einerseits geben die Selektoren für sich genommen wenig preis. Andererseits bedeutet es, dass sich das eigene Inventar nicht von außen per Abfrage rekonstruieren lässt: Wenn niemand festgehalten hat, welche Selektoren existieren, kennt nur die DNS-Zone selbst die Antwort. Ein Argument mehr für das oben erwähnte Inventar — am Tag des Domain-Audits muss die Liste aus den eigenen Einträgen kommen, nicht aus einer Entdeckungstour.

Selektor und Subdomains: ein Fall, den man kennen sollte

Ein Punkt, der oft überrascht: Die Subdomains „erben" nicht den Selektor der Wurzeldomain. Läuft der Versand über news.unternehmen.de, 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. Vor der Frage „ist mein Schlüssel gut?" steht die Frage „ist auch für jede versendende Domain und Subdomain ein Schlüssel veröffentlicht?"

Thomas kartografiert die Selektoren

Zwischen den Selektoren jeder Plattform und denen, die alte Rotationen zurückgelassen haben, verliert man leicht den Überblick. Thomas, der virtuelle 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 der Domain aligned — und meldet die toten Selektoren, die aufzuräumen sind.

Eine Domain kostenlos analysieren oder ein Konto anlegen, um in den DKIM-Schlüsseln klar zu sehen.