SPF/DMARC/DKIM-Prüfer
Prüft den veröffentlichten DKIM-Key eines Selectors samt Syntax und Warnungen.
E-Mail-SicherheitDKIM-Schlüssel rotieren, ohne Mail zu brechen
Ein DKIM-Key ist schnell publiziert und ebenso schnell vergessen. Eine belastbare Rotation ist ein Überlappungsprotokoll: neuen Selector einführen, seine Nutzung an echter Mail belegen, den alten Public Key für Nachrichten in Warteschlangen erhalten — und anschließend wirklich aufräumen.
Der Selector ist deine Änderungsgrenze
Eine DKIM-Signatur nennt in d= die Signing-Domain und in s= den Selector; Empfänger holen den Key unter selector._domainkey.domain. Rotation funktioniert, weil alter und neuer Selector gleichzeitig existieren können. Den Schlüssel unter einem unveränderten Selector auszutauschen zerstört genau diese Eigenschaft: DNS-Caches, wartende Nachrichten und langsam auslaufende Systeme können dann den falschen Public Key sehen. Behandle Selector deshalb als unveränderliche Key-IDs, nicht als hübsche Aliase, deren Inhalt du überschreibst.
Namen wie mta2026q3 lassen Generationen auseinanderhalten, ohne Geheimnisse preiszugeben; ein ewiges default tut das nicht. Vom Provider vorgegebene Namen sind in Ordnung, wenn sie im Inventar stehen. Dort gehören Selector, d=-Domain, Signer, Algorithmus, Schlüssellänge, Erzeugungs- und Aktivierungsdatum, Owner und Retirement-Status hinein. Kann niemand sagen, in welchem System die private Hälfte liegt, ist der DNS-Record bereits verwaist — unabhängig davon, wie ordentlich er aussieht.
Wähle für die reale Empfängerwelt
Bei RSA sind 2048 Bit die vernünftige Untergrenze für neue Keys. RSA-1024 hängt noch in alten Appliances und engen DNS-Setups, ist aber Migrationsschuld; kürzere Schlüssel kommen nicht infrage. Größere RSA-Keys erhöhen DNS-Nutzlast und Fragmentierungsdruck, ohne im Mailbetrieb meist ein konkretes Problem zu lösen. Der Public Key liegt base64-kodiert im TXT-Record und wird vom DNS-Panel oft in mehrere quoted Strings zerlegt. Mehrere Strings in einem Record sind korrekt; mehrere eigenständige DKIM-Records am selben Owner nicht.
Ed25519 liefert kompakte Schlüssel und Signaturen, wird aber noch nicht von jedem Signer, Validator und Hosted Provider unterstützt. Der pragmatische Einstieg ist Dual Signing: eine breit kompatible RSA-Signatur behalten, Ed25519 ergänzen und Empfängerresultate messen. Nenne Ed25519 erst dann Ersatz, wenn deine eigene Empfängerpopulation das belegt. Der SPF/DMARC/DKIM-Prüfer kann Form und Warnungen eines bekannten Selectors prüfen; eine Garantie für die Algorithmus-Unterstützung aller Empfänger liefert er nicht.
Vier beobachtbare Phasen statt Big Bang
Erzeuge zuerst den neuen Private Key im Signer oder innerhalb seiner Key-Management-Grenze; in einem DNS-Ticket hat er nichts verloren. Publiziere ausschließlich den Public Key unter einem frischen Selector und mit einer zum Änderungsfenster passenden TTL. Prüfe die vollständige TXT-Antwort autoritativ und über rekursive Resolver. Noch signiert nichts damit. Genau das ist der Vorteil: DNS darf sich setzen, ohne dass eine einzige Nachricht davon abhängt. Notiere den Fingerprint des erzeugten Public Keys und vergleiche ihn mit DNS; so entdeckst du abgeschnittene Strings oder den Key aus der falschen Umgebung, bevor Signaturen entstehen.
Aktiviere den Selector danach auf einem kontrollierten Versandstrom und belege ihn an zugestellter Mail. Stelle anschließend alle vorgesehenen Pfade um, während der alte Record stehen bleibt. Warte mindestens die maximale Cache-Dauer plus die längste glaubhafte Queue- und Retry-Zeit; verzögerte Mail wurde beim Einreihen signiert, nicht bei ihrer späteren Zustellung. Erst dann wird der alte Public Key entfernt. Bei einem kompromittierten Schlüssel läuft alles schneller, aber ein neuer Selector macht selbst den Notfall-Cutover eindeutig.
Mehrere Provider brauchen getrennte Eigentümer
Mehrere Anbieter dürfen dieselbe Organisationsdomain signieren, aber niemals Private Keys oder Selector teilen. Jeder Dienst bekommt seinen eigenen Namensraum und hält die private Hälfte in seiner Service-Grenze. Manche Plattformen signieren zunächst mit ihrer eigenen Domain und bieten kundenbezogenes Signing erst als Zusatz an. Für DMARC hilft DKIM nur, wenn das validierte d= mit der sichtbaren From-Domain aligned ist. Dokumentiere diesen Unterschied, bevor ein grünes „DKIM pass“ als fertige Einführung gilt.
Eine Nachricht darf mehrere DKIM-Signaturen tragen. Das hilft bei Migrationen, zwei Algorithmen oder wenn eine Plattform nach deinem Gateway erneut signiert. Für die DKIM-Seite von DMARC genügt eine überlebende, aligned Signatur; wahlloses Multi-Signing erzeugt dagegen Lärm und weitere Keys. Prüfe Stichproben aus Direktversand, Marketing, Support, Transaktionssystemen und Forwards. Der E-Mail-Header-Analyzer ordnet DKIM- und Authentication-Results-Felder lokal; die kryptografische Prüfung bleibt Sache des protokollierenden Empfängers.
Beweise, dass der neue Key benutzt wird
DNS-Präsenz beweist nur, dass ein Schlüssel abrufbar ist. Sende über jeden Produktionspfad und kontrolliere im DKIM-Signature-Feld das beabsichtigte d=, s=, a= und die Canonicalization. Lies die Authentication-Results des empfangenden Systems, nicht irgendeinen vom Absender gesetzten Header. Pass für den neuen Selector, aligned DMARC-Pass und keine Body-Hash-Fehler sind brauchbare Signale. Ein einziges Testpostfach bleibt ein Smoke-Test, keine Abdeckung. Nimm Empfänger aus mehreren großen Ökosystemen und einen kontrollierten Validator hinzu; unterschiedliche Caches und Implementierungen liefern während der Überlappung wertvolle Evidenz.
Nutze DMARC-Aggregatreports, um DKIM-Ergebnisse nach Quelle und Provider zu verfolgen, ergänzt um Selector-Telemetrie des Anbieters, falls vorhanden. Achte nach Template-Änderungen auf Ausfälle: Footer, Link-Rewriting und Gateways können Header- oder Body-Hashes brechen, obwohl der Key tadellos ist. Bei weitergeleiteter Mail sind aktuelles DKIM-Ergebnis und upstream konserviertes Ergebnis verschiedene Evidenz. Der ARC-Chain-Validator prüft die Kettenstruktur, holt aber keine Keys und validiert nicht kryptografisch.
Keys stilllegen, Historie behalten
Wenn kein System mehr mit dem alten Selector signiert und das Wartefenster abgelaufen ist, lösche seinen DNS-Record. Ein leeres p= widerruft einen Key ausdrücklich und kann kurzfristig ein sinnvolles Signal sein; für immer stehen gelassene Widerrufsrecords sind kein Aufräumen. Tote Keys vergrößern die Unklarheit im Incident, konservieren vergessene Abhängigkeiten und erschweren die Unterscheidung zwischen Legacy-Mail und Missbrauch eines aufgegebenen Private Keys. Löschen ist eine feste Rotationsphase, kein optionales Hygiene-Ticket.
Bewahre die nicht geheime Audit-Spur an anderer Stelle: Public-Key-Fingerprint, Selector, Service-Owner, Aktivierung, Stilllegung, Freigabe und Grund. Mache den alten Private Key mit den Mitteln der Plattform unbrauchbar und prüfe, ob Backups oder Replikate ihn unbemerkt reaktivieren könnten. Dokumentiere auch, wer einen Notfallwechsel auslösen darf und wo sein Runbook liegt. Plane danach die nächste Rotation, solange das Verfahren frisch ist. Ein moderater Zyklus, der alle Phasen zuverlässig abschließt, ist besser als ein aggressiver Kalender, der ständig neue Keys publiziert und keinen alten entfernt.