ExchangeServer
DKIM (DomainKeys Identified Mail)
Overview
DomainKeys Identified Mail (DKIM) ist in RFC 6376 (September 2011) beschrieben und hat den Status Internet Standard. Der sendende Server signiert ausgewählte Header und den Inhalt mit einem privaten Schlüssel, der öffentliche Schlüssel liegt im DNS der signierenden Domain unter einem Selektor.
Im Unterschied zu SPF übersteht DKIM in der Regel Weiterleitungen, solange Header und Inhalt unverändert bleiben. DKIM allein verhindert nicht das Fälschen der sichtbaren Absenderadresse, denn die signierende Domain (d=) kann von der sichtbaren abweichen. Erst DMARC verlangt, dass beide zusammenpassen (Alignment).
Für die Zustellung bei Google, Yahoo und Outlook.com ist DKIM für Massenversender inzwischen Pflicht. In Exchange Online hat Microsoft im Mai 2025 ein neues CNAME-Format für neue eigene Domains eingeführt (Ziel unter dkim.mail.microsoft), bestehende Domains behalten das alte Format.
How it works
Signieren und Prüfen laufen so ab:
- Der sendende Server bildet Hashwerte über ausgewählte Header und den Body und signiert sie mit dem privaten Schlüssel.
- Die Signatur steht im Header DKIM-Signature mit Domain (d=), Selektor (s=) und Algorithmus.
- Der Empfänger ruft den öffentlichen Schlüssel unter selektor._domainkey.domain im DNS ab und prüft die Signatur.
- Das Ergebnis (dkim=pass oder fail) steht im Header Authentication-Results und fließt in DMARC ein.
Exchange Online nutzt zwei Selektoren (selector1 und selector2) als CNAME-Einträge, von denen immer einer aktiv ist, damit Schlüssel rotiert werden können. Standard ist ein 1024-Bit-Schlüssel, 2048 Bit lassen sich bei Erstellung oder Rotation wählen. Eine Rotation wird nach 96 Stunden wirksam. Für die Domain onmicrosoft.com signiert Microsoft automatisch, eigene Domains richtest Du im Defender-Portal oder per PowerShell ein.
Benefits
- Schutz vor Veränderung der Nachricht auf dem Transportweg
- Weiterleitungen überstehen die Prüfung meist besser als bei SPF
- Voraussetzung für belastbares DMARC und bessere Zustellbarkeit
- In Exchange Online ohne Zusatzlizenz nutzbar
Practical example
Ein Steuerberatungsbüro mit 40 Mitarbeitenden stellt fest, dass Mandanten Phishing-Mails im Namen der Kanzlei erhalten. Die IT kopiert im Defender-Portal die beiden CNAME-Werte, legt sie in der DNS-Zone an und aktiviert danach die DKIM-Signierung, beim nächsten Rotieren mit 2048-Bit-Schlüssel. Anschließend richtet sie DMARC im Beobachtungsmodus ein. Fälschungen lassen sich dadurch in den Berichten erkennen und später abweisen.
Things to keep in mind
- CNAME-Werte immer aus Portal oder Get-DkimSigningConfig kopieren, nicht selbst zusammenbauen, weil sich das Format geändert hat
- Nach dem Anlegen der DNS-Einträge die Signierung aktiv schalten, der DNS-Eintrag allein reicht nicht
- Drittsysteme wie Newsletter-Dienste und CRM mit eigenen DKIM-Schlüsseln und Selektoren für die Domain ausstatten
- Schlüssel regelmäßig rotieren und dabei auf 2048 Bit umstellen
- Gateways und Signaturtools, die Inhalte nach dem Signieren verändern, brechen die Signatur
Conclusion
DKIM sollte für jede aktiv genutzte Maildomain eingerichtet sein. Der Aufwand ist gering, der Nutzen entsteht in Kombination mit SPF und DMARC.
Further reading
Related articles
Microsoft 365
Exchange Online Hardening | Security & Privacy Best Practices
Microsoft 365
SharePoint Online | December 2026: Smart Tagging for eSignature
Cyber Security
M365 Exchange Online | Preventing Domain Spoofing
Microsoft 365