Ein kompromittierter DKIM-Schlüssel ist kein theoretisches Risiko – er ist ein aktives Sicherheitsproblem. Wenn ein Angreifer im Besitz Ihres privaten DKIM-Schlüssels ist, kann er E-Mails signieren, die scheinbar authentisch von Ihrer Domain stammen. Empfangende Mailserver sehen eine gültige Signatur und liefern die Nachricht ab. Ihren Kunden und Partnern gegenüber sieht alles legitim aus. Diese Anleitung führt Sie Schritt für Schritt durch den Reaktionsprozess – von der Erkennung bis zur verifizierten Behebung.

Wie ein DKIM-Schlüssel kompromittiert wird

Private DKIM-Schlüssel werden auf dem Mailserver gespeichert und bei jeder ausgehenden Nachricht verwendet. Es gibt mehrere Wege, auf denen ein Schlüssel in die falschen Hände geraten kann:

  • Server-Einbruch. Wenn ein Angreifer sich Zugang zu Ihrem Mailserver verschafft – sei es über eine ungepatchte Sicherheitslücke, gestohlene SSH-Credentials oder eine kompromittierte Webanwendung –, kann er den privaten Schlüssel aus dem Dateisystem auslesen. Typische Speicherorte sind /etc/opendkim/keys/ oder ähnliche Verzeichnisse, je nach Mailserver-Software.
  • Geleakte Konfigurationsdateien. Konfigurationsdateien, die versehentlich in ein öffentliches Git-Repository eingecheckt wurden, auf einem unsicheren Webserver exponiert sind oder in einem Backup-Archiv ohne ausreichende Zugangskontrolle liegen, können den privaten Schlüssel direkt preisgeben.
  • Shared-Hosting-Umgebungen. In Shared-Hosting-Umgebungen, in denen mehrere Kunden denselben Server nutzen, können Fehlkonfigurationen bei Dateizugriffsrechten dazu führen, dass ein Tenant die Schlüsseldateien eines anderen lesen kann.
  • Alte Backups. Backups, die DKIM-Schlüsseldateien enthalten und über Jahre hinweg aufbewahrt werden, ohne dass die Schlüssel jemals rotiert wurden, sind ein häufig übersehenes Risiko. Wenn ein Backup-Archiv kompromittiert wird, sind alle darin enthaltenen Schlüssel exponiert.

Was kann ein Angreifer mit Ihrem privaten DKIM-Schlüssel tun? Er kann E-Mails signieren, die von Ihrer Domain zu stammen scheinen – und zwar mit einer Signatur, die von empfangenden Mailservern als gültig bewertet wird. Das bedeutet: Phishing-E-Mails gegen Ihre Kunden, gefälschte interne Kommunikation gegen Ihre Mitarbeiter oder betrügerische Nachrichten gegen Ihre Geschäftspartner – alles mit einer DKIM-Signatur, die authentisch wirkt. Solange der Angreifer im Besitz des Schlüssels ist und Sie nichts unternehmen, besteht das Risiko fort.

Sofortmaßnahmen: Kein Grund zur Panik, aber schnell handeln

Wenn Sie den Verdacht haben oder wissen, dass Ihr DKIM-Schlüssel kompromittiert wurde, ist eine geordnete Reaktion wichtiger als Panik. Der Prozess ist klar und beherrschbar. Das Ziel ist es, den kompromittierten Schlüssel so schnell wie möglich außer Kraft zu setzen und durch einen neuen zu ersetzen, ohne dabei den legitimen E-Mail-Versand zu unterbrechen.

Der Reaktionsprozess umfasst sechs Schritte:

  1. Neues DKIM-Schlüsselpaar generieren
  2. Neuen öffentlichen Schlüssel im DNS veröffentlichen
  3. Mailserver auf neuen Schlüssel umstellen
  4. Alten Schlüssel widerrufen
  5. Rotation verifizieren
  6. DMARC-Reports überwachen

Führen Sie die Schritte in dieser Reihenfolge durch. Insbesondere ist es wichtig, den neuen Schlüssel im DNS zu veröffentlichen und den Mailserver umzustellen, bevor Sie den alten Schlüssel widerrufen – andernfalls riskieren Sie eine temporäre Unterbrechung der DKIM-Signierung für legitime E-Mails.

Schritt 1: Neues DKIM-Schlüsselpaar generieren

Generieren Sie ein neues RSA-Schlüsselpaar mit mindestens 2048 Bit. 1024-Bit-Schlüssel gelten als unsicher und werden von modernen Mailservern zunehmend abgelehnt. Verwenden Sie für den neuen Schlüssel einen neuen Selektor-Namen – so können Sie den alten und neuen Schlüssel gleichzeitig im DNS veröffentlichen, ohne Konflikte zu erzeugen.

Mit OpenSSL lässt sich ein neues Schlüsselpaar auf der Kommandozeile erzeugen:

openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

Viele Mailserver-Pakete bringen eigene Tools mit. Bei Postfix mit OpenDKIM etwa lautet der Befehl:

opendkim-genkey -b 2048 -d ihre-domain.de -s neuer-selektor

Dieser Befehl erzeugt zwei Dateien: neuer-selektor.private (privater Schlüssel, bleibt auf dem Server) und neuer-selektor.txt (der DNS-TXT-Record-Eintrag, den Sie im nächsten Schritt veröffentlichen). Wählen Sie einen Selektor-Namen, der das Datum oder einen anderen eindeutigen Bezeichner enthält, z. B. mail202504 – das erleichtert späteres Key-Management.

Schritt 2: Neuen öffentlichen Schlüssel im DNS veröffentlichen

Der öffentliche Schlüssel wird als TXT-Record unter der Subdomain [selektor]._domainkey.[ihre-domain] im DNS veröffentlicht. Das Format des Records lautet:

neuer-selektor._domainkey.ihre-domain.de  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Die wichtigsten Tags:

  • v=DKIM1 - Version (Pflichtfeld)
  • k=rsa - Schlüsseltyp
  • p= - Base64-kodierter öffentlicher Schlüssel

Setzen Sie die TTL für diesen Record auf einen niedrigen Wert, z. B. 300 Sekunden (5 Minuten). Das stellt sicher, dass Änderungen – insbesondere der spätere Widerruf des alten Schlüssels – schnell im DNS propagieren. Warten Sie nach der Veröffentlichung, bis der neue Record global aufgelöst werden kann, bevor Sie mit Schritt 3 fortfahren. Sie können dies mit dig prüfen:

dig TXT neuer-selektor._domainkey.ihre-domain.de +short

Schritt 3: Mailserver auf neuen Schlüssel umstellen

Konfigurieren Sie Ihren Mailserver so, dass er für ausgehende E-Mails den neuen privaten Schlüssel und den neuen Selektor verwendet. Der genaue Vorgang hängt von Ihrer Mailserver-Software ab:

  • Postfix + OpenDKIM: Aktualisieren Sie die KeyTable und SigningTable in der OpenDKIM-Konfiguration, um auf den neuen Schlüssel und Selektor zu verweisen. Starten Sie OpenDKIM neu.
  • Exim: Aktualisieren Sie die DKIM-Konfiguration im Exim-Konfigurationsfile, typischerweise im transport-Block. Laden Sie die Konfiguration neu.
  • Hosted E-Mail-Dienste (Google Workspace, Microsoft 365 etc.): Folgen Sie der Dokumentation des jeweiligen Anbieters zur DKIM-Key-Rotation. In der Regel erfolgt dies über die Admin-Konsole.

Nachdem Sie den Mailserver umgestellt haben, senden Sie eine Test-E-Mail und prüfen Sie die E-Mail-Header der empfangenen Nachricht. Sie sollten den neuen Selektor im DKIM-Signature-Header sehen:

DKIM-Signature: v=1; a=rsa-sha256; s=neuer-selektor; d=ihre-domain.de; ...

Schritt 4: Alten Schlüssel widerrufen

Sobald der Mailserver erfolgreich auf den neuen Schlüssel umgestellt ist und Sie verifiziert haben, dass ausgehende E-Mails mit dem neuen Selektor signiert werden, widerrufen Sie den alten Schlüssel. Das geschieht, indem Sie den p=-Tag im alten DNS-TXT-Record auf einen leeren Wert setzen:

alter-selektor._domainkey.ihre-domain.de  IN TXT  "v=DKIM1; p="

Ein leerer p=-Wert signalisiert empfangenden Mailservern explizit, dass der Schlüssel widerrufen wurde. E-Mails, die mit diesem Schlüssel signiert sind, werden nicht mehr als gültig DKIM-signiert betrachtet. Das schließt auch E-Mails ein, die ein Angreifer mit dem kompromittierten Schlüssel signiert.

Warten Sie, bis die TTL des alten Records abgelaufen ist, bevor Sie davon ausgehen, dass der Widerruf vollständig propagiert ist. Danach können Sie den alten Record wahlweise vollständig aus dem DNS entfernen oder für eine weitere Übergangsperiode belassen.

Schritt 5: Rotation verifizieren

Verifizieren Sie die Rotation auf zwei Ebenen: DNS-Auflösung und E-Mail-Signierung.

Für die DNS-Auflösung prüfen Sie mit dig, dass der neue Schlüssel korrekt aufgelöst wird und der alte als widerrufen erscheint:

dig TXT neuer-selektor._domainkey.ihre-domain.de +short
dig TXT alter-selektor._domainkey.ihre-domain.de +short

Der erste Befehl sollte den vollständigen öffentlichen Schlüssel zurückgeben. Der zweite sollte einen Record mit leerem p= zurückgeben.

Für die E-Mail-Signierung nutzen Sie den DMARCFlow DKIM-Prüfer: Geben Sie Ihre Domain und den neuen Selektor ein. Das Tool löst den DNS-Record auf und zeigt Ihnen, ob der Schlüssel korrekt veröffentlicht ist und die Schlüssellänge den Mindestanforderungen entspricht.

Schritt 6: DMARC-Reports überwachen

Nach der Key-Rotation sollten Sie Ihre DMARC-Reports für einige Tage besonders aufmerksam beobachten. DMARC-Reports enthalten pro Datensatz das DKIM-Authentifizierungsergebnis – inklusive des verwendeten Selektors. Achten Sie auf folgende Signale:

  • DKIM-Fehler mit dem neuen Selektor deuten darauf hin, dass der Mailserver noch nicht korrekt konfiguriert ist oder der DNS-Record fehlerhaft ist.
  • DKIM-Passes mit dem alten Selektor nach dem Widerruf könnten auf zwischengespeicherte DNS-Einträge hinweisen oder – schlimmer – auf E-Mails, die tatsächlich mit dem kompromittierten Schlüssel signiert wurden.
  • Unerklärliche DKIM-Passes von unbekannten IP-Adressen könnten ein Zeichen sein, dass ein Angreifer noch aktiv den alten Schlüssel nutzt, bevor der Widerruf vollständig propagiert ist.

DMARCFlow aggregiert und analysiert Ihre DMARC-Reports automatisch, gruppiert Ergebnisse nach Selektor und sendender Quelle und macht es einfach, Anomalien nach einer Key-Rotation schnell zu erkennen.

Künftige Kompromittierungen verhindern

Die Reaktion auf einen kompromittierten Schlüssel ist der akute Teil. Der wichtigere Teil ist, dafür zu sorgen, dass es nicht erneut passiert:

  • Zugriff auf private Schlüssel einschränken. Private DKIM-Schlüssel sollten nur für den Mailserver-Prozess lesbar sein. Setzen Sie Dateizugriffsrechte restriktiv: chmod 600 für die Schlüsseldatei, Eigentümer ist der Mailserver-User. Kein anderer Prozess oder Benutzer sollte lesenden Zugriff haben.
  • Schlüssel nie in Versionskontrollsystemen speichern. Private Schlüssel gehören nicht in Git-Repositories – weder in öffentliche noch in private. Fügen Sie Schlüsseldateimuster zu Ihrer .gitignore hinzu und prüfen Sie bestehende Repositories auf versehentlich eingecheckte Schlüssel.
  • Regelmäßige Key-Rotation einplanen. Auch ohne konkreten Kompromittierungsverdacht sollten DKIM-Schlüssel regelmäßig rotiert werden – mindestens einmal jährlich, idealerweise alle sechs Monate. Tragen Sie die Rotation als wiederkehrende Aufgabe in Ihren Kalender ein.
  • Mindestens 2048-Bit-Schlüssel verwenden. 1024-Bit-Schlüssel sind veraltet und angreifbar. Wenn Sie noch 1024-Bit-Schlüssel im Einsatz haben, ist dies ein guter Anlass, sie unabhängig von einem Kompromittierungsverdacht zu rotieren.
  • Backups auf enthaltene Schlüssel prüfen. Stellen Sie sicher, dass Backup-Archive nicht ungeschützt private Schlüsseldateien enthalten. Verschlüsseln Sie Backups und schränken Sie den Zugriff auf Backup-Systeme ein.
  • DMARC-Reports laufend überwachen. Anomalien in DMARC-Reports – unbekannte Selektoren, DKIM-Passes von unerwarteten IP-Adressen – können frühe Hinweise auf eine Kompromittierung sein, bevor der Schaden offensichtlich wird.
DKIM-Setup kostenlos prüfen
Überprüfen Sie Ihren DKIM-Schlüssel, Selektor und DNS-Record in Sekunden – kostenlos und ohne Registrierung.
DKIM prüfen

Fazit

Ein kompromittierter DKIM-Schlüssel ist ein ernstes Problem, aber kein unlösbares. Der Reaktionsprozess ist klar: neuen Schlüssel generieren, im DNS veröffentlichen, Mailserver umstellen, alten Schlüssel widerrufen, Rotation verifizieren, Reports beobachten. Wer die Schritte in der richtigen Reihenfolge durchführt, kann den Schaden begrenzen und die E-Mail-Sicherheit seiner Domain schnell wiederherstellen.

Langfristig ist regelmäßige Key-Rotation keine optionale Best Practice – sie ist ein notwendiger Bestandteil eines soliden E-Mail-Sicherheitskonzepts. In Kombination mit DMARC-Monitoring, das Ihnen zeigt, welche Selektoren aktiv verwendet werden und ob DKIM-Signaturen erfolgreich validiert werden, haben Sie die Kontrolle, Anomalien frühzeitig zu erkennen und zu reagieren, bevor ein Angreifer dauerhaften Schaden anrichten kann.