DKIM-Schlüsselrotation: warum, wann und wie (ohne etwas kaputtzumachen)

Die Methode des doppelten Selektors (ohne Unterbrechung)

Hier ist der Kern des Themas. Die sichere Rotation beruht darauf, dass eine Domain mehrere Selektoren gleichzeitig aktiv haben kann (siehe der Selektor). Die Sequenz:

1. Einen neuen Schlüssel erzeugen unter einem neuen Selektor (zum Beispiel s2) und seinen öffentlichen Schlüssel im DNS veröffentlichen — ohne den alten Selektor (s1) anzurühren.
2. Propagieren lassen und prüfen, dass der neue öffentliche Schlüssel überall gut sichtbar ist.
3. Die Signatur umschalten auf Plattformseite, sodass sie fortan mit s2 signiert.
4. Ein paar Tage überwachen: Die neuen Signaturen (s2) müssen durchgehen und in den aggregierten Berichten aligned sein.
5. Den alten Selektor entfernen (s1) — aber erst nach einer ausreichenden Frist.

Während des gesamten Übergangs koexistieren die beiden Selektoren: Die mit dem alten Schlüssel signierte Post bleibt verifizierbar, die neue auch. Diese Überlappung macht die Rotation unterbrechungsfrei.

Die unbedingt zu vermeidende Falle

Der klassische Fehler ist, den alten Selektor zu früh zu entfernen. Mit dem alten Schlüssel signierte Post kann noch unterwegs sein, in einer Warteschlange oder für einen verzögerten Versand gespeichert. Wird ihr Selektor gelöscht, bevor sie vollständig zugestellt ist, schlägt ihre Signatur bei der Verifikation fehl — obwohl sie vollkommen legitim ist. Die Regel: Der alte Selektor bleibt mehrere Tage an Ort und Stelle, nachdem die Signatur umgeschaltet wurde, bis die gesamte alte Post verarbeitet ist. Besser ein Selektor zu viel für ein paar Tage als eine kaputte Signatur.

Manuelle oder automatisierte Rotation

Zwei Ansätze, je nach Konfiguration:

• Automatisiert. Läuft die Signatur über eine Plattform, die den CNAME anbietet (Microsoft 365, viele SaaS), wird die Rotation oft mitverwaltet: Der Dienstleister rotiert den Schlüssel hinter dem einmal veröffentlichten CNAME. Das ist ideal — es bleibt nichts zu tun.
• Manuell. Bei eigener Infrastruktur oder festen TXT wird die Rotation selbst gesteuert, nach der obigen Sequenz des doppelten Selektors. Das ist mehr Arbeit, aber mit einer schriftlichen Prozedur und einem Kalender vollkommen machbar.

Wo die privaten DKIM-Schlüssel gehören

Die Rotation nützt nichts, wenn die privaten Schlüssel in einer zugänglichen Konfigurationsdatei oder einer E-Mail herumliegen. Der private DKIM-Schlüssel ist ein kritisches Geheimnis: Wer ihn erlangt, kann im Namen der Domain Post signieren. Er verdient daher dieselbe Sorgfalt wie jedes Produktionsgeheimnis — verschlüsselte Speicherung, nachverfolgter Zugriff, werkzeuggestützte Rotation.

DMARC.com wird herausgegeben von Hucency, einem Spezialisten für Cybersicherheit; um diese Art von Geheimnissen zu zentralisieren und zu verschlüsseln — private DKIM-Schlüssel, DNS-Zugangsdaten, API-Token — und ihre Rotation zu orchestrieren, lohnt ein Blick auf Hucency Vault. Eine gute DKIM-Rotationsrichtlinie setzt einen sicheren Ort voraus, an dem die Schlüssel leben; der Tresor ist dieses oft vernachlässigte Glied.

Einen Rotationskalender aufbauen

Die beste Rotation ist die, an die man nicht denken muss. Statt sich auf das Gedächtnis zu verlassen, gehört die DKIM-Rotation in einen Sicherheitskalender, ebenso wie die Erneuerung der TLS-Zertifikate. Eine halbjährliche oder jährliche Kadenz, im Voraus notiert, verwandelt einen angstbesetzten Handgriff in eine vorhersehbare Routine. Die Prozedur einmal dokumentiert — welcher Selektor, welche Plattform, welche Schlüssellänge, wie viele Tage Überlappung — und jede folgende Rotation ist nur noch eine Ausführung, keine Neuerfindung. Für Domains mit mehreren Plattformen staffeln sich die Rotationen besser, statt alles am selben Tag: Das begrenzt die Risikofläche, falls eine Umschaltung schiefgeht, und hält die Aufmerksamkeit frei, um jeden Übergang einzeln zu überwachen.

Notfall: ein kompromittierter Schlüssel

Die geplante Rotation ist eine Sache; die Notfallrotation eine andere. Besteht auch nur der geringste Grund zur Annahme, dass ein privater Schlüssel geleckt ist — kompromittierter Server, exponiertes Backup, Weggang eines Dienstleisters mit Zugängen — verbietet sich das Warten auf den geplanten Termin: sofort rotieren. Die Sequenz bleibt dieselbe (neuer Selektor, neuer Schlüssel, Umschaltung der Signatur), aber die Überlappung wird verkürzt und der alte Schlüssel so schnell wie möglich widerrufen, indem an seinem Selektor ein leeres p= veröffentlicht wird, was jede darauf berufende Signatur ungültig macht. Ein kompromittierter Schlüssel, den man leben lässt, ist eine offene Tür zur signierten Imitation: Der Angreifer kann Nachrichten erzeugen, die im Namen der Domain DKIM bestehen, das schlimstmögliche Szenario. Das gehört wie ein Passwortleck behandelt — Rotation und Widerruf ohne Verzug — und der Vorfall für die Nachvollziehbarkeit dokumentiert.

Prüfen, dass eine Rotation gut verlaufen ist

Nach einer Rotation reichen zwei Kontrollen:

1. Der neue Selektor signiert und ist aligned: Die Berichte müssen die s2-Signaturen zeigen, die durchgehen. Siehe wie man eine E-Mail-Signatur verifiziert.
2. Keine legitime Signatur bricht während des Übergangs: Zu überwachen ist das Ausbleiben plötzlicher DKIM-Fehler auf den echten Quellen.

Unser kostenloser Analyzer bestätigt das Vorhandensein und die Gültigkeit der öffentlichen Schlüssel am aktuellen Selektor, ein nützlicher Blick direkt nach einer Umschaltung.

Häufige Fragen

In welcher Häufigkeit erneuern? Alle sechs Monate bis zu einem Jahr für die meisten Fälle. Wichtig ist, dass es geplant und systematisch ist, nicht die perfekte Häufigkeit.

Unterbricht die Rotation den Versand? Nein, sofern die Methode des doppelten Selektors befolgt wird: Die beiden Schlüssel koexistieren während des Übergangs, also keine Unterbrechung.

Wann kann ich den alten Selektor entfernen? Mehrere Tage nach der Umschaltung der Signatur, bis die gesamte alte Post zugestellt wurde. Zu früh entfernen bricht legitime Signaturen.

Verwaltet meine Plattform die Rotation? Bei einem vom Dienstleister gelieferten CNAME wahrscheinlich ja. Bei festen TXT bleibt die Steuerung beim Betreiber.

Muss ich bei jeder Rotation den Selektor wechseln? Ja, das ist der ganze Sinn: Ein neuer Schlüssel unter einem neuen Selektor erlaubt die Überlappung ohne Unterbrechung. Denselben Selektor für einen neuen Schlüssel wiederzuverwenden schafft ein Fenster, in dem die Signaturen fehlschlagen.

DKIM und Compliance: was die Rahmenwerke erwarten

In einer regulierten Umgebung — Finanzwesen, Gesundheit, öffentliche Hand — ist die DKIM-Schlüsselrotation womöglich nicht mehr eine bloße Wahl guter Praxis, sondern eine dokumentierte Anforderung. Rahmenwerke wie ISO 27001 (kryptografische Kontrollen §A.10) oder NIS2 erwarten eine Richtlinie zur Verwaltung von Geheimnissen, die deren periodische Erneuerung einschließt. Ein vor fünf Jahren gesetzter und nie erneuerter DKIM-Schlüssel ist bei einem Audit schwer zu verteidigen. Die Nachvollziehbarkeit zählt ebenfalls: Wer hat den Schlüssel erzeugt, wann, welche Länge, wann ist die nächste Rotation — lauter Elemente, die Auditoren verlangen können. Ein einfaches DKIM-Rotationsjournal (Datum, Selektor, Plattform, Länge) löst diese Situationen mühelos und zeigt, dass die E-Mail-Sicherheit gesteuert wird, nicht erduldet. Es ist nicht viel Arbeit, aber genau das, was den Unterschied macht zwischen „wir handhaben es" und „wir dokumentieren, dass wir es handhaben".

Rotation über einen CNAME: der bequemste Fall

Hat die Versandplattform bei der DKIM-Einrichtung einen CNAME statt eines rohen TXT geliefert, ist bereits die Hälfte der Rotationsarbeit ausgelagert — oft unbemerkt. Der einmal veröffentlichte CNAME zeigt auf einen Eintrag, den der Dienstleister in seiner Zone verwaltet. Rotiert er seinen Schlüssel, ändert er diesen Zieleintrag — und der CNAME folgt automatisch, ohne dass das eigene DNS angerührt wird. Für viele Domains ist das der ideale Betriebsmodus: einmal veröffentlichen, und die Rotation geschieht danach transparent hinter den Kulissen. Das erklärt, warum wir den CNAME dem rohen TXT vorziehen, sobald der Dienstleister ihn anbietet — nicht aus technischer Eleganz, sondern weil er ein wiederkehrendes manuelles Ritual eliminiert, das man sonst leicht vergisst.

Der Preis dieser Bequemlichkeit ist ein Kontrollverlust: Der genaue Rotationszeitpunkt des Dienstleisters bleibt oft unbekannt, und die Aufbewahrung des privaten Schlüssels ruht auf seiner Sicherheitspraxis. Für die meisten Organisationen ist dieser Kompromiss vernünftig — ein seriöser Dienstleister verwaltet seine Schlüssel besser als ein von Hand gepflegter Server. Aber in einer regulierten Umgebung, in der Rotationskadenz und Speicherung der Geheimnisse zu belegen sind, empfiehlt sich womöglich die Rotation in Eigenregie, auch wenn das mehr Arbeit bedeutet. Es gibt keine universell richtige Antwort; die Wahl hängt davon ab, wie viel Nachvollziehbarkeit der Kontext verlangt.

Thomas taktet die Rotationen

Eine vergessene Rotation lässt einen Schlüssel altern; eine hingepfuschte Rotation bricht Signaturen. Thomas, der virtuelle CISO, verfolgt das Alter der DKIM-Schlüssel, meldet, wann es Zeit zum Rotieren ist, führt durch die Sequenz des doppelten Selektors und prüft in den Berichten, dass die Umschaltung ohne Schaden erfolgt ist.

Eine Domain kostenlos analysieren oder ein Konto anlegen für stets frische und gut gehütete DKIM-Schlüssel.