DKIM ist mehr als nur eine DNS-Einstellung - Warum E-Mail-Sicherheit automatisiert werden muss

Im vorherigen Blogbeitrag „Kann ein Newslettertool E-Mails im Namen Ihres CEOs verschicken? Vermutlich schon“ erläuterte Jens ein oft unterschätztes Risiko: Wenn ein externer Anbieter DKIM-Signaturrechte für eine primäre Domain erhält, kann dieser Anbieter technisch gesehen gültige E-Mails für diese Domain signieren.

Ich möchte dieses Thema noch einen Schritt weiterführen. Jens’ Artikel beantwortet bereits die politische Frage: DKIM-Schlüssel für primäre Domains sollten nicht ohne Kontrolle an externe Anbieter weitergegeben werden.

Im realen Betrieb stellt sich jedoch sofort die nächste Frage:

Wie setzen wir DKIM richtig um, wenn wir nicht nur eine Domain, sondern viele Domains – vielleicht sogar Hunderte – über mehrere Mail-Gateways und regelmäßige Schlüsselrotationen hinweg verwalten?

Denn DKIM-Keys sind kryptographische Schlüssel, und sollten (laut BSI TR-02102: müssen!) regelmäßig rotiert werden. Allerdings haben DKIM-Keys im Gegensatz zu Web-Zertifikaten keine eingebaute Gültigkeit, so dass dieses oft vernachlässigt wird.

Aber an dieser Stelle hört DKIM auf, ein einfacher TXT-Eintrag zu sein, und wird zu einem operativen Prozess.

Das Problem mit der manuellen DKIM-Rotation

Auf dem Papier sieht die DKIM-Rotation einfach aus:

1. einen neuen privaten Schlüssel generieren
2. den neuen öffentlichen Schlüssel im DNS veröffentlichen
3. den Mail-Gateway auf den neuen Selektor umstellen
4. Testnachrichten senden
5. den alten Selektor nach einer Übergangsphase entfernen

Bei einer einzelnen Domain ist dies noch überschaubar. In einer gewachsenen Infrastruktur wird es schnell komplizierter.

Es kann mehrere Domains, Subdomains, interne und externe Versandwege, verschiedene Selektoren, mehrere Postfix-Gateways, unterschiedliche Umgebungen und DNS-Zonen geben, die über viele Jahre hinweg gewachsen sind. Einige Domains werden täglich aktiv genutzt. Andere existieren nur für spezielle Anwendungen oder Legacy-Prozesse. Einige DKIM-Einträge gehören zu internen Gateways, andere zu Anwendungen oder älteren Integrationen.

Wenn eine solche Umgebung manuell rotiert wird, wird der operative Druck sehr schnell spürbar. Typische Fehler sind:

• Ein Selektor ist im DNS veröffentlicht, aber nicht auf jedem Gateway bereitgestellt
• ein privater Schlüssel wird vorübergehend unverschlüsselt auf einer Admin-Workstation gespeichert
• ein Gateway signiert weiterhin mit dem alten Selektor
• ein DNS-Eintrag wird zu früh entfernt
• KeyTable und SigningTable stimmen nicht mehr überein
• Eine Domain wird bei der Rotation vergessen
• Die Dateiberechtigungen auf dem Mail-Gateway sind zu offen
• Es wird nur eine Testnachricht geprüft, während andere Versandwege ungetestet bleiben

Das Problem liegt in der Regel nicht bei DKIM selbst. Das Problem liegt in der manuellen Handhabung rund um DKIM.

Warum Rotation wichtig ist

Private DKIM-Schlüssel sind Signaturschlüssel. Wenn ein solcher Schlüssel offengelegt, kopiert, vergessen oder jahrelang unverändert bleibt, unterliegt ein wichtiger Teil der E-Mail-Authentifizierung nicht mehr der ordnungsgemäßen Kontrolle.

DKIM-Schlüssel sollten daher wie andere kryptografische Schlüssel behandelt werden:

• Sie benötigen einen eindeutigen Eigentümer
• sie dürfen nicht unverschlüsselt in Tickets oder auf Wiki-Seiten gespeichert werden
• sie sollten nicht auf persönlichen Arbeitsplätzen verbleiben
• sie benötigen strenge Dateiberechtigungen auf den Gateways
• ihre Verwendung muss nachvollziehbar sein
• ihre Rotation muss geplant und testbar sein

Eine Rotation muss nicht nur technisch korrekt sein. Sie muss auch betriebssicher sein. E-Mail ist für viele Prozesse geschäftskritisch. Eine fehlerhafte DKIM-Rotation kann dazu führen, dass legitime Nachrichten von großen Anbietern schlecht bewertet oder abgelehnt werden. Das beeinträchtigt nicht nur die Glaubwürdigkeit eines Unternehmens, sondern kann auch den Vertrieb, den Support, die Rechnungsstellung und andere Kommunikationswege unterbrechen, bei denen Verzögerungen schnell teuer werden.

Was technisch zusammenpassen muss

DKIM hat immer zwei Seiten, die zusammenpassen müssen.

Der öffentliche Schlüssel wird im DNS veröffentlicht:

selector2026._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=<PUBLIC_KEY>" 

Der private Schlüssel wird auf dem Mail-Gateway gespeichert. Die DKIM-Konfiguration legt dann fest, welche Domain mit welchem Selektor signiert wird.

In einer typischen Postfix- und DKIM-Milter-Umgebung könnte die Konfiguration in etwa so aussehen:

example.com selector2026._domainkey.example.com

und:

selector2026._domainkey.example.com example.com:selector2026:/etc/dkim/keys/example.com/selector2026.private

(Dieses sind Beispiele, wie sie mit dkimpy-milter eingesetzt werden, den DKIM Signierungsdaemon, den wir seit einigen Jahren einsetzen)

Damit eine Rotation funktioniert, müssen DNS, privater Schlüssel, Selektor, SigningTable, KeyTable, Dateiberechtigungen und die Milter-Konfiguration alle übereinstimmen. Genau deshalb wird der Prozess anfällig, wenn er manuell pro Domain und pro Server verwaltet wird.

Warum Ansible für diesen Anwendungsfall geeignet ist

Ansible eignet sich sehr gut für die DKIM-Rotation, da es die Eigenschaften bietet, die dieser Prozess benötigt:

• idempotente Ausführung
• übersichtliche Inventare für mehrere Gateways
• Vorlagen für wiederholbare Konfigurationen
• kontrollierte Einführung über Gruppen und Phasen hinweg
• Nachverfolgbarkeit durch einen Git-basierten Workflow
• Sicherer Umgang mit sensiblen Variablen mit Ansible Vault
• einfache Validierung und Handler-Logik

Der wichtigste Punkt für mich ist folgender: Mit Ansible beschreiben wir den gewünschten Zustand.

Nicht:

Ich kopiere diesen Schlüssel schnell auf drei Server und bearbeite dann zwei Tabellen von Hand. 

Sondern:

Diese Domains sollten mit diesen Selektoren signiert werden. Diese privaten Schlüssel gehören zu ihnen. Diese Dateien müssen mit diesen Berechtigungen vorhanden sein. Diese Dienste müssen anschließend neu geladen werden. Diese Validierungsprüfungen müssen bestanden werden. 

Das ist eine ganz andere Art, die E-Mail-Infrastruktur zu betreiben.

Zentrale Beschreibung mehrerer Domänen

Ein einfaches DKIM-Datenmodell kann wie folgt aussehen:

dkim_domains:

- domain: example.com 
  selector: selector2026 
  key_path: /etc/dkim/keys/example.com/selector2026.private

- domain: news.example.com
  selector: selector2026
  key_path: /etc/dkim/keys/news.example.com/selector2026.private

- domain: app.example.net
  selector: selector2026
  key_path: /etc/dkim/keys/app.example.net/selector2026.private

Ausgehend von dieser zentralen Definition kann Ansible die erforderlichen Komponenten generieren und bereitstellen:

• Domänen-Schlüsselverzeichnisse
• private DKIM-Schlüssel
• SigningTable
• KeyTable
• TrustedHosts, falls erforderlich
• korrekte Dateiberechtigungen
• Neuladen des DKIM-Milter

Wenn später eine weitere Domain hinzugefügt wird, muss diese nicht manuell in jedes Gateway eingefügt werden. Sie wird dem Datenmodell hinzugefügt, überprüft und bereitgestellt.

Schutz privater DKIM-Schlüssel mit Ansible Vault

Private DKIM-Schlüssel dürfen nicht im Klartext in einem Repository gespeichert werden. Wenn sie mit Ansible verwaltet werden, sollten sie in verschlüsselten Vault-Dateien gespeichert oder aus einem dedizierten Secret-Management-System abgerufen werden.

Mit Ansible Vault kann der logische Inhalt vor der Verschlüsselung wie folgt aussehen:

vault_dkim_private_keys:
  example.com: 
    selector2026: | -----BEGIN PRIVATE KEY----- <REDACTED_PRIVATE_KEY> -----END PRIVATE KEY-----
  news.example.com:
    selector2026: | -----BEGIN PRIVATE KEY----- <REDACTED_PRIVATE_KEY> -----END PRIVATE KEY-----

In Git wird diese Datei verschlüsselt gespeichert, nicht als Klartext. Das ist wichtig, aber es ist nicht die ganze Sicherheitsgeschichte.

Selbst mit Ansible Vault sind einige Regeln zu beachten:

• Das Vault-Passwort darf nicht im Repository gespeichert werden
• Der Zugriff auf das Vault-Passwort muss eingeschränkt sein
• CI/CD-Protokolle dürfen niemals Geheimnisse preisgeben
• sensible Aufgaben sollten no_log: true verwenden
• Private Schlüssel auf Zielsystemen sollten minimale Dateiberechtigungen haben
• Alte Schlüssel müssen nach der Übergangsphase auf kontrollierte Weise entfernt werden

Eine Ansibletask, die einen privaten DKIM-Schlüssel bereitstellt, sollte daher nicht nur den Inhalt schreiben, sondern auch Eigentümer und Berechtigungen durchsetzen:

- name: DKIM-Privatschlüssel bereitstellen 
  ansible.builtin.copy: 
    content: “{{ vault_dkim_private_keys[item.domain][item.selector] }}”
    dest: “{{ item.key_path }}”
    owner: opendkim
    group: opendkim
    mode: "0600" 
  loop: “{{ dkim_domains }}”
  no_log: true
  notify: DKIM-Dienst neu laden

Das Interessante daran ist nicht nur das Kopiermodul. Das Interessante daran ist, dass der Prozess reproduzierbar wird. Jeder Schlüssel wird mit den erwarteten Berechtigungen auf den erwarteten Pfad in der erwarteten Gruppe von Mail-Gateways geschrieben.

Konfiguration aus Vorlagen generieren

SigningTable und KeyTable sollten ebenfalls nicht manuell bearbeitet werden. Sie können aus derselben Domänenliste generiert werden. Hier kommen Jinja-Vorlagen zum Einsatz.

SigningTable:

{% for item in dkim_domains %} *@{{ item.domain }} {{ item.selector }}._domainkey.{{ item.domain }} {% endfor %}

KeyTable:

{% for item in dkim_domains %} {{ item.selector }}._domainkey.{{ item.domain }} {{ item.domain }}:{{ item.selector }}:{{ item.key_path }} {% endfor %}

Dies verhindert ein häufiges Betriebsproblem: Eine Domain ist in der SigningTable vorhanden, aber der passende Eintrag in der KeyTable fehlt oder verweist auf den falschen Schlüssel. Beide Dateien werden aus derselben Quelle generiert.

Das klingt einfach, aber kleine Unstimmigkeiten wie diese sind oft der Grund für langwierige Fehlerbehebungssitzungen.

Ein sicherer DKIM-Rotationsablauf

Eine saubere DKIM-Rotation sollte nicht damit beginnen, den alten Schlüssel zu überschreiben. Ein sicherer Ansatz ist es, einen neuen Selektor parallel zu betreiben.

Ein möglicher Ablauf:

1. Definieren Sie einen neuen Selektor, zum Beispiel selector2026
2. ein neues privates und öffentliches Schlüsselpaar generieren
3. speichern Sie den privaten Schlüssel verschlüsselt mit Ansible Vault
4. den öffentlichen Schlüssel im DNS veröffentlichen
5. Überprüfen Sie die DNS-Verbreitung
6. Konfigurieren Sie die Mail-Gateways mit Ansible so, dass sie den neuen Selektor verwenden
7. Testnachrichten senden und die DKIM-Signatur überprüfen
8. Überprüfen Sie die DMARC-Konformität
9. Protokolle und Bounces überwachen
10. Entfernen Sie den alten Selektor erst nach einer Übergangsphase

Die Parallelphase ist wichtig. Empfangende Mailserver verarbeiten Nachrichten möglicherweise mit Verzögerung, Warteschlangen können noch ältere Nachrichten enthalten und DNS-Caches können noch alte Daten vorhalten. Wird der alte Selektor zu früh entfernt, können ansonsten gültige Signaturen nicht mehr verifiziert werden.

DNS bleibt Teil des Prozesses

Ansible kann die Mail-Gateways sehr gut verwalten. Der DNS-Teil muss jedoch mit derselben Sorgfalt integriert werden.

Je nach Umgebung kann der öffentliche DKIM-Eintrag über BlueCat, eine DNS-API, Terraform oder einen kontrollierten Änderungsprozess verwaltet werden. Wichtig ist, dass der DNS-Eintrag vorhanden und extern auflösbar ist, bevor das Gateway mit dem neuen Selektor zu signieren beginnt.

Typische Überprüfungen:

dig TXT selector2026._domainkey.example.com 
dig TXT _dmarc.example.com 
dig MX example.com

Nach dem Senden einer Testnachricht sollten die Nachrichten-Header überprüft werden:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector2026;
Authentication-Results: ... dkim=pass ... dmarc=pass

Erst wenn DNS, die DKIM-Signatur und die DMARC-Ausrichtung übereinstimmen, ist die Umstellung wirklich abgeschlossen.

Warum dies bei mehreren Domains noch wichtiger ist

Der wahre Wert der Automatisierung zeigt sich nicht bei einer Domain, sondern bei vielen.

Wenn zehn oder zwanzig Domains rotiert werden müssen, wird ein manueller Prozess schnell unüberschaubar. Jede Domain benötigt einen passenden DNS-Eintrag, einen privaten Schlüssel, einen Selektor, Tabelleneinträge und Tests.

Mit Ansible kann dieselbe Rolle für alle Domains ausgeführt werden. Die Unterschiede werden in Variablen ausgedrückt. Dies reduziert sowohl den Aufwand als auch das Risiko.

Beispielsweise kann die Einführung zunächst auf eine Testgruppe abzielen:

mailgateways_test

dann eine kleine Produktions-Canary-Gruppe:

mailgateways_canary

und schließlich auf alle Produktions-Gateways:

mailgateways_prod

Dadurch wird die DKIM-Rotation von einer manuellen nächtlichen Wartungsaufgabe zu einer kontrollierten Bereitstellung.

Was ich immer validieren würde

Bei der DKIM-Rotation reicht es nicht aus, dass Ansible ohne Fehler abläuft. Das Ergebnis muss technisch validiert werden.

Ich würde mindestens Folgendes überprüfen:

• Existiert der neue DKIM-TXT-Eintrag im DNS?
• Wird der neue Selektor in ausgehenden Nachrichten verwendet?
• Stimmt der d=-Wert mit der erwarteten Domain überein?
• Wird DKIM bei externen Empfängern akzeptiert?
• Wird DMARC bestanden?
• Gibt es Fehler in den DKIM-Milter-Protokollen?
• Gibt es nach der Umstellung Bounces oder Ablehnungen?
• Werden alte Selektoren nach der Übergangsphase entfernt?
• Sind private Schlüssel mit 0600 und dem richtigen Eigentümer auf dem Gateway gespeichert?

Insbesondere in der E-Mail-Infrastruktur ist „Bereitstellung erfolgreich“ nicht gleichbedeutend mit „E-Mails werden korrekt angenommen“.

Warum Ansible besser ist als ein manuelles Runbook

Ein gutes Runbook ist wichtig. Aber bei der DKIM-Rotation stößt ein rein manuelles Runbook schnell an seine Grenzen.

Ein Runbook sagt, was zu tun ist. Ansible macht den Prozess wiederholbar.

Dies bringt mehrere Vorteile mit sich:

• weniger Copy-and-Paste-Fehler
• konsistente Konfiguration über mehrere Gateways hinweg
• eine zentrale Definition für alle Domains
• verschlüsselte Speicherung privater Schlüssel
• Überprüfung vor der Bereitstellung
• reproduzierbare Bereitstellungen
• einfachere Rückkehr zum vorherigen Selektor
• bessere Nachverfolgbarkeit für Audits

Meiner Ansicht nach passt Ansible sehr gut zu diesem Thema, da die DKIM-Rotation genau zwischen klassischer Systemadministration und einem Sicherheitsprozess angesiedelt ist. Sie umfasst Dateien, Vorlagen, Dienste, Berechtigungen, Geheimnisse und kontrollierte Änderungen über mehrere Linux-Systeme hinweg. Das ist eine der Stärken von Ansible.

Fazit

DKIM ist nicht nur ein TXT-Eintrag. Die DKIM-Rotation ist keine manuelle Kopier-und-Einfüge-Aufgabe.

Sobald mehrere Domains und mehrere Mail-Gateways beteiligt sind, muss der Prozess strukturiert ablaufen. Der öffentliche Schlüssel muss im DNS korrekt eingetragen sein, der private Schlüssel muss sicher gespeichert werden, die Milter-Konfiguration muss konsistent sein und die Änderung muss validiert werden.

Ansible ist hierfür ein leistungsstarkes Werkzeug, da es die DKIM-Rotation in einen wiederholbaren Betriebsprozess verwandelt. In Verbindung mit Ansible Vault können private Schlüssel verschlüsselt gespeichert und kontrolliert auf Mail-Gateways bereitgestellt werden.

Der wichtigste Punkt ist jedoch nicht das Tool selbst. Wichtig ist, dass DKIM-Schlüssel als echte Sicherheitsobjekte behandelt werden: mit Eigentumsrechten, Rotation, Zugriffskontrolle, Validierung und sauberer Löschung.

Der Betrieb von DKIM auf diese Weise reduziert nicht nur Zustellungsprobleme. Er gibt einem Unternehmen auch mehr Kontrolle darüber, wer E-Mails im Namen einer Domain signieren darf.

Während wir dies schreiben, können wir bereits beobachten, dass große Provider bei der E-Mail-Authentifizierung strenger werden. Sich allein auf SPF zu verlassen, ist keine komfortable Position mehr. In vielen Fällen in der Praxis hängt die E-Mail-Zustellung davon ab, dass SPF, DKIM, DMARC-Alignment, Reputation und eine konsistente DNS-Konfiguration zusammenwirken.

Dies fügt sich auch in die breitere Diskussion um widerstandsfähige Infrastruktur und digitale Souveränität in Europa ein. Wenn ein Unternehmen seine E-Mail-Infrastruktur sicher skalieren möchte, ist die Antwort nicht nur ein weiterer DNS-Eintrag. Die Antwort ist ein Prozess, der überprüft, wiederholt, automatisiert und validiert werden kann.

Wenn Sie sich mit DKIM-Rotation, E-Mail-Authentifizierung, DNS-Automatisierung oder Infrastrukturautomatisierung im Allgemeinen beschäftigen, stehe ich jederzeit für ein technisches Gespräch zur Verfügung.