DKIM-Schlüssel-Rotation: operatives Runbook (T-7 bis T+30)

Die DKIM-Schlüssel-Rotation ist eine wiederkehrende Operation. Die Vendor-Anleitungen (Microsoft, AWS, SendGrid) beschreiben die Schaltfläche "Rotate", ohne das Überlappungsfenster, die DNS-Propagationsverzögerung oder das Rollback-Verfahren zu erklären. Dieses Runbook schließt somit diese Lücke mit einer kalendarischen Timeline von T-7 bis T+30, getesteten openssl-Skripten und Praxisfallen aus dem Feld.

Für die allgemeine Referenz konsultieren Sie den vollständigen DKIM-Leitfaden sowie unsere Einführung zum DKIM-Eintrag. Hier ist das Ziel operativ: das Schlüsselpaar erzeugen, den Selektor veröffentlichen, die Signatur umschalten, DMARC überwachen, den alten Selektor entfernen. Zielpublikum: Sysadmins, DevOps, SRE und Infrastrukturteams in der Produktion.

Warum DKIM-Schlüssel rotieren?

Drei operative Gründe rechtfertigen die periodische Rotation.

Schlüsselkompromittierung. Ein privater DKIM-Schlüssel sickert immer irgendwann durch: unverschlüsseltes Backup, Legacy-KMS-Zugang eines ehemaligen Mitarbeiters, Dump eines SaaS-Anbieters. Die Rotation begrenzt das Ausnutzungsfenster eines Lecks.

Kryptografische Grenze. RFC 8301 hat RSA-Schlüssel unter 1024 Bit bereits 2018 als veraltet eingestuft und empfiehlt mindestens RSA 2048. Ein 2018 veröffentlichter RSA-1024-Schlüssel wird heute von Google, Yahoo und Microsoft abgelehnt. Regelmäßige Rotation erzwingt den Ersatz veralteter Algorithmen.

Kryptografische Hygiene. NIST SP 800-57 Part 1 Rev. 5 empfiehlt kurze Kryptoperioden für Signaturschlüssel: 1 bis 2 Jahre maximal, kürzer für sensible Umgebungen. Ohne regelmäßige Rotation wird die erste erzwungene Rotation zur Katastrophe.

DKIM2, derzeit in der Standardisierung bei der IETF, fügt einen Replay-Schutz hinzu, ersetzt aber nicht den Bedarf an Rotation. Siehe DKIM2 und Replay-Schutz.

Strategie der DKIM-Rotation: parallele Selektoren statt direktem Austausch

Grundprinzip jeder DKIM-Schlüssel-Rotation: einen privaten DKIM-Schlüssel niemals durch Overwrite ersetzen. Immer einen neuen Selektor parallel veröffentlichen, die Signatur umschalten und anschließend den alten Selektor nach einer Karenzzeit entfernen. Daher koexistieren zwei Schlüssel während eines kontrollierten Fensters.

Drei Faktoren erzwingen die zeitweilige Koexistenz:

• DNS-Resolver-Cache. Der TXT-Wert eines Selektors wird für die TTL (1 bis 24 Stunden) gecacht. Einige Resolver liefern weiterhin den alten Wert aus.
• SMTP-Retry. Ein empfangender MTA hält eine Nachricht bis zu 5 Tagen in der Queue. Wird der Selektor zu früh entfernt, schlägt die Neuverifizierung fehl.
• Forensisches Audit. Sicherheitsteams müssen die Signatur einer vor 2 Wochen empfangenen Nachricht überprüfen. Ein entfernter Selektor macht diese Verifizierung unmöglich.

Namenskonvention: quartalsweise datierte Selektoren. Beispiel: s2026-q1 für Januar bis März 2026, s2026-q2 für den folgenden Zeitraum. Diese Konvention vermeidet Kollisionen mit Vendor-Selektoren (selector1 Microsoft 365, google Google Workspace, mte1 SendGrid). Die beiden Selektoren koexistieren im Überlappungsfenster:

s2025-q4._domainkey.captaindns.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
s2026-q1._domainkey.captaindns.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

Minimale Überlappungsdauer: 7 Tage auf Propagationsseite, 30 Tage auf Entfernungsseite, um die längsten SMTP-Retries abzudecken.

Operativer Rotationskalender

Schlüsselpaar mit openssl erzeugen

Vier openssl-Befehle decken alle Anforderungen ab. Alle wurden mit OpenSSL 3.x getestet.

RSA 2048: Erzeugung des privaten Schlüssels.

openssl genrsa -out dkim_private.pem 2048

RSA 2048: Extraktion des öffentlichen Schlüssels in base64 für das DNS.

openssl rsa -in dkim_private.pem -pubout -outform der | openssl base64 -A

Das Ergebnis ist der Wert, den Sie in das p=-Tag des TXT-Records einfügen.

Ed25519: Erzeugung des privaten Schlüssels.

openssl genpkey -algorithm ed25519 -out dkim_ed25519_private.pem

Ed25519: Extraktion des öffentlichen Schlüssels in base64 (32 Byte).

openssl pkey -in dkim_ed25519_private.pem -pubout -outform der | tail -c 32 | openssl base64

Das tail -c 32 ist erforderlich: openssl gibt einen ASN.1-Header von 12 Byte vor den effektiven 32 Byte des Ed25519-Schlüssels aus; RFC 8463 verlangt, diesen Header für p= zu entfernen.

Vergleichstabelle der drei realistischen Optionen 2026:

Empfehlung 2026: RSA 2048 allein für maximale Kompatibilität, oder Double-Publish RSA 2048 plus Ed25519, um bei kompatiblen Empfängern von der Ed25519-Signatur zu profitieren. RSA 4096 vermeiden: Der öffentliche Schlüssel überschreitet 255 Zeichen und erzwingt eine TXT-Aufteilung in mehrere Strings, fragil bei jeder DNS-Edition. Für den Detailvergleich siehe RSA vs Ed25519 für DKIM.

Verwaltung des privaten Schlüssels

Der private DKIM-Schlüssel ist ein kryptografisches Geheimnis auf gleicher Stufe wie ein TLS-Schlüssel. Drei akzeptable Speichermodelle existieren in der Produktion.

Managed KMS (AWS KMS asymmetric keys, GCP Cloud KMS, Azure Key Vault). Der Schlüssel wird erzeugt und verbleibt im HSM. Der MTA ruft die KMS-API auf, um jede Nachricht zu signieren. Der private Schlüssel wird nie im Anwendungsspeicher exponiert, die Rotation wird über IAM nachverfolgt. Nachteil: 5 bis 20 ms Latenz pro Aufruf.

HashiCorp Vault Transit. Self-hosted-Äquivalent zum Managed KMS. Der Schlüssel verbleibt im Transit-Backend, der MTA signiert über die API. Konventioneller Pfad: secret/dkim/captaindns/s2026-q1.

PEM-Datei verschlüsselt im Ruhezustand. Akzeptables Minimum für kleine Infrastrukturen. Der Schlüssel wird auf dem versendenden Server in einem verschlüsselten Volume (LUKS, encrypted EBS) gespeichert, mit Berechtigungen 0600 und Eigentümer opendkim:opendkim. Deployment via Ansible Vault, Sealed Secrets für Kubernetes oder SOPS.

Anti-Patterns, die zu vermeiden sind:

• Privater Schlüssel ins Git-Repository eingecheckt, auch in einem privaten Branch. Git bewahrt die Historie für immer auf.
• Privater Schlüssel als unverschlüsselte Umgebungsvariable (DKIM_PRIVATE_KEY=...) in einem docker-compose oder einer .env-Datei übergeben.
• Privater Schlüssel in einem Secret Manager gespeichert, der mit unnötigen Service-Konten geteilt wird (Prinzip der minimalen Rechte verletzt).

Bei der Rotation nicht vergessen, auch die KMS-Zugriffe zu rotieren. Ein ehemaliger Mitarbeiter, der Leserechte auf secret/dkim/captaindns/s2025-q4 hatte, darf diesen Zugang nicht behalten, selbst wenn der Schlüssel nicht mehr aktiv ist: Er bleibt gültig zur Signatur rückdatierter Nachrichten.

Rotation per cron automatisieren

Eine manuelle Rotation wird beim ersten Urlaub des Teams vergessen. Automatisierung ist ab 3 bis 4 aktiven Domänen unverzichtbar. Den Job in 3 idempotente Schritte zerlegen:

1. Generate: das Paar erzeugen und den privaten Schlüssel im KMS speichern.
2. Publish-DNS: die API des DNS-Providers aufrufen, um den TXT hinzuzufügen.
3. Switch-signing: den MTA nach dem T-7-Fenster neu konfigurieren.

Bash-Skelett Generate + Publish-DNS auf Cloudflare:

#!/bin/bash
set -euo pipefail

SELECTOR="s$(date +%Y-q%q)"
DOMAIN="captaindns.com"
ZONE_ID="${CLOUDFLARE_ZONE_ID}"

# Generate RSA 2048
openssl genrsa -out "dkim_${SELECTOR}.pem" 2048
PUB=$(openssl rsa -in "dkim_${SELECTOR}.pem" -pubout -outform der | openssl base64 -A)

# Store private key in Vault
vault kv put "secret/dkim/${DOMAIN}/${SELECTOR}" private_key=@"dkim_${SELECTOR}.pem"

# Publish DNS via Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records" \
  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data "{\"type\":\"TXT\",\"name\":\"${SELECTOR}._domainkey\",\"content\":\"v=DKIM1; k=rsa; p=${PUB}\",\"ttl\":3600}"

# Verify publication
sleep 30
dig +short TXT "${SELECTOR}._domainkey.${DOMAIN}"

Cron: 0 3 1 */6 * (alle 6 Monate, am 1. des Monats um 3 Uhr UTC) löst die Phase Generate plus Publish-DNS aus, gefolgt 7 Tage später von einem zweiten Cron, der Switch-signing ausführt.

Vendor-Integrationen:

• AWS SES BYODKIM: Befehl aws sesv2 put-email-identity-dkim-signing-attributes mit dem Paar DomainSigningSelector und DomainSigningPrivateKey, codiert in base64.
• Microsoft 365: Rotate-DkimSigningConfig -Identity captaindns.com -KeySize 2048 (Exchange Online PowerShell). Die Rotation erzeugt einen neuen Selektor auf Microsoft-Seite, erfordert jedoch das Veröffentlichen des neuen CNAME im DNS, um den neuen Schlüssel zu aktivieren.
• SendGrid: Die Rotation wird über die API POST /whitelabel/domains/{id}/validate verwaltet, nachdem der neue CNAME beim DNS-Provider hinzugefügt wurde.

Empfohlenes Alerting: einen Alarm auslösen, wenn die Rate dkim=fail in den DMARC-Aggregate-Reports im Fenster T+0 bis T+7 1 % überschreitet. In der Praxis läuft die Validierung nach der Rotation programmatisch über die DKIM-Record-Check-API. Bei Inkonsistenzen zwischen Selektoren und DMARC-Alignment konsultieren Sie unseren Leitfaden zu DMARCbis sowie die Analyse DKIM-Fehlerursachen und Korrekturen.

Häufige Fallstricke

Fünf wiederkehrende Fallstricke tauchen in Support-Tickets und Reddit-r/sysadmin-Threads auf.

Zu hohe TTL auf dem alten Selektor. Eine TTL von 24 Stunden verhindert die schnelle Propagation einer Korrektur. Die TTL 48 Stunden vor T+0 auf 300 Sekunden absenken, dann nach T+7 wieder auf 3600 Sekunden anheben.

Selektor mit falsch platzierten Bindestrichen. Manche strikten DKIM-Parser lehnen einen Selektor ab, der einen Bindestrich an erster oder letzter Position enthält. s2026q1 ist -s2026-q1- vorzuziehen.

DMARC im strengen Alignment (adkim=s). Eine Signatur d=mail.captaindns.com wird für ein From: contact@captaindns.com abgelehnt. Überprüfen Sie, dass die d=-Domäne des neuen Schlüssels identisch zur alten bleibt.

Öffentlicher Schlüssel auf SaaS-Seite verborgen. Mailchimp, ActiveCampaign und andere veröffentlichen einen CNAME statt eines direkten TXT. Die Rotation wird vom Provider verwaltet: validieren Sie, dass der CNAME nach der deklarierten Rotation auf das neue Ziel verweist.

Tag s= falsch konfiguriert. Das optionale Tag s=email beschränkt die Nutzung des Schlüssels auf die Signatur von E-Mail-Nachrichten. Ein Schlüssel, der mit s=* oder ohne Tag veröffentlicht wird, akzeptiert alle Dienste. Für Details siehe das s=-Tag im DKIM-Eintrag.

Beispiel eines schlecht codierten TXT (base64-Wrap mehrzeilig mit rohem Zeilenumbruch, von manchen Resolvern abgelehnt):

s2026-q1._domainkey.captaindns.com.  IN  TXT  ( "v=DKIM1; k=rsa; "
                                                "p=MIIBIjANBgkqhkiG\n"
                                                "9w0BAQEFAAOC..." )

Korrektes Beispiel (einzelner String oder sauberer Split in Chunks von 255 Zeichen):

s2026-q1._domainkey.captaindns.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

FAQ

Validieren Sie Ihre nächste DKIM-Schlüssel-Rotation: Nutzen Sie den DKIM Record Check, um zu überprüfen, dass Ihr neuer Selektor vor und nach der Umstellung korrekt veröffentlicht und signiert ist. Daher wird jede Rotation messbar und reproduzierbar. Um Protokoll-Entwicklungen zu antizipieren, siehe auch DKIM2 und Replay-Schutz sowie unsere Anleitung DKIM für Office 365 und Google Workspace.

Quellen

• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301 - Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 8463 - A New Cryptographic Signature Method for DKIM (Ed25519)
• NIST SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management
• Microsoft Learn - Rotate-DkimSigningConfig