Diese Anleitung betrifft den Exchange-Online-Versand einer eigenen Domain oder Subdomain. Ein privates Outlook.com-Konto, die anfängliche onmicrosoft.com-Domain und ein zusätzlicher Newsletterdienst sind andere Fälle.
Domain, Versandweg und Berechtigung klären
Die eigene Domain muss bereits erfolgreich zu Microsoft 365 hinzugefügt sein. Prüfen Sie, ob Nachrichten tatsächlich über Exchange Online versandt werden und ob ein Gateway sie danach verändert. Für jede dort verwendete eigene Versanddomain beziehungsweise Subdomain benötigen Sie die passende DKIM-Konfiguration. Ein Domainname im Tenant richtet nicht alle anderen Versanddienste ein.
Sie brauchen Zugriff auf die aktive DNS-Zone und die erforderlichen Verwaltungsrechte in Ihrer Microsoft-365-Organisation. Für PowerShell setzen die folgenden Befehle eine bereits eingerichtete, berechtigte Exchange-Online-PowerShell-Sitzung voraus. Microsoft verweist bei jedem Cmdlet auf die zugewiesenen Rollen und Parameterrechte. Eine beliebige Anmeldung oder ein pauschaler Global-Administrator-Zwang ist daraus nicht abzuleiten. Prüfen Sie die tatsächlich erforderlichen Cmdletrechte, bevor Sie eine Änderung vornehmen.
Lesen Sie zuerst die bestehende Konfiguration. Erstellen oder ersetzen Sie keine Schlüssel, nur weil Sie eine neue Anleitung verwenden. example.com ist in allen folgenden Befehlen eine Beispieldomain; ersetzen Sie sie durch Ihre eigene bestätigte Domain. Hier wurden die Befehle nicht ausgeführt.
1. Die aktuellen CNAME-Werte übernehmen und veröffentlichen
Bestehende Konfiguration lesen oder neue gezielt anlegen
In einer berechtigten Exchange-Online-Sitzung lesen Sie die Werte für genau eine Domain:
Get-DkimSigningConfig -Identity "example.com" | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAMEKontrollieren Sie, dass Name in der Antwort genau die beabsichtigte Domain bezeichnet. Microsoft warnt, dass ein fehlender beziehungsweise ungültiger Identity-Wert unter Umständen alle Objekte zurückliefert. Übernehmen Sie keine CNAMEs einer anderen zurückgegebenen Domain.
Fehlt für die bereits hinzugefügte Domain tatsächlich eine DKIM-Konfiguration, beschreibt Microsoft deren Anlage zunächst mit deaktivierter Signierung. Der folgende Befehl verändert die Konfiguration und ist nur für diesen geklärten Neuanlagefall gedacht; ein Lesefehler ist noch kein Nachweis, dass die Konfiguration fehlt:
New-DkimSigningConfig -DomainName "example.com" -Enabled $false -KeySize 2048
Get-DkimSigningConfig -Identity "example.com" | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAMEAlternativ finden Sie die Domain im Defender-Portal unter E-Mail und Zusammenarbeit → Richtlinien und Regeln → Bedrohungsrichtlinien → E-Mail-Authentifizierungseinstellungen → DKIM. Öffnen Sie die Domaindetails und den Bereich Publish CNAMEs. Bei einer neuen Konfiguration mit NoDKIMKeys beschreibt Microsoft zunächst das Erzeugen der Schlüssel; der erste Aktivierungsversuch kann dabei die benötigten CNAMEs als Fehlermeldung liefern und in CnameMissing übergehen. Das ist noch keine erfolgreiche Aktivierung. Folgen Sie für diesen Ausgangszustand dem aktuellen Portalverfahren, statt den Schalter wiederholt ohne DNS-Abgleich zu betätigen.
Zwei Recordnamen, zwei gelieferte Ziele
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Name in der eigenen Zone | Typ | Ziel |
|---|---|---|
selector1._domainkey | CNAME | Exakt der Wert aus Selector1CNAME beziehungsweise dem Portal |
selector2._domainkey | CNAME | Exakt der Wert aus Selector2CNAME beziehungsweise dem Portal |
Für example.com lauten die vollständigen Namen selector1._domainkey.example.com und selector2._domainkey.example.com. Prüfen Sie, ob Ihre DNS-Verwaltung den Domainsuffix selbst ergänzt. Am CNAME-Ziel stellt Microsoft den öffentlichen DKIM-Schlüssel bereit. Der private Schlüssel bleibt beim Dienst; er gehört nicht ins DNS.
Konstruieren Sie die Ziele nicht aus dem Tenantnamen. Microsoft dokumentiert seit Mai 2025 für neue eigene Domains ein Format unter dkim.mail.microsoft mit dynamischem Bestandteil. Bestehende Konfigurationen können das ältere Ziel unter onmicrosoft.com behalten. Ein funktionierendes älteres Format wird nicht allein durch sein Alter falsch. Maßgeblich sind die aktuell für Ihre Domain ausgegebenen Werte. Alte und neue Zielvarianten werden nicht zusätzlich unter demselben Selektor veröffentlicht.
Die beiden CNAMEs sind die Vorbereitung für Microsofts Schlüsselverwaltung. Aus ihrer bloßen Existenz folgen weder der aktuell verwendete Selektor noch eine bereits vollzogene Rotation oder zwei aktive Signaturen pro Nachricht.
2. DNS prüfen und Signierung aktivieren
Lesen Sie beide CNAMEs. Die Kurzabfragen mit dig setzen eine entsprechende Installation voraus:
dig CNAME selector1._domainkey.example.com +short
dig CNAME selector2._domainkey.example.com +shortUnter Windows mit dem DnsClient-Modul:
Resolve-DnsName -Name selector1._domainkey.example.com -Type CNAME -DnsOnly
Resolve-DnsName -Name selector2._domainkey.example.com -Type CNAME -DnsOnlyVergleichen Sie jede Antwort mit dem zugehörigen gelieferten Ziel. Bei einer leeren oder unklaren Kurzantwort lesen Sie die vollständige DNS-Ausgabe, etwa ohne +short. Ein falscher Abfragename, eine falsche Zone, DNS-Fehler und Cachezustände sind unterschiedliche Ursachen. Ein passender CNAME ist zunächst ein DNS-Nachweis; auch der öffentliche Schlüssel am Ziel und die tatsächliche Signierung müssen zum Versand passen.
Nach passender Veröffentlichung aktivieren Sie die Signierung für dieselbe Domain im DKIM-Bereich des Defender-Portals. Der dortige Status soll die Signierung anzeigen. Als Alternative in einer berechtigten Sitzung:
Set-DkimSigningConfig -Identity "example.com" -Enabled $true
Get-DkimSigningConfig -Identity "example.com" | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAMESet-DkimSigningConfig ist ein Änderungsschritt. Kontrollieren Sie danach Enabled und Status; Microsoft beschreibt für die erfolgreiche Konfiguration True und Valid. CnameMissing verlangt einen Abgleich der DNS-Werte und der Erkennung durch Microsoft. Eine starre Wartefrist ersetzt diesen Abgleich nicht. Der Verwaltungsstatus ist noch kein Empfangsbefund einer Nachricht.
3. Eine extern empfangene Nachricht prüfen
Verwenden Sie eine eigene Nachricht über den tatsächlich untersuchten Exchange-Online-Versand an einen berechtigt genutzten Empfänger außerhalb derselben Microsoft-365-Organisation. Microsoft weist darauf hin, dass Nachrichten innerhalb derselben Organisation auch zwischen unterschiedlichen Domains ohne DKIM-Signatur bleiben können. Eine solche interne Probe ist kein geeigneter Gegenbeweis für die externe Signierung.
Öffnen Sie die Originalheader beim Empfänger. Ordnen Sie die erwartete DKIM-Signature anhand von d= und s= zu und lesen Sie das dazugehörige DKIM-Ergebnis des vertrauenswürdigen Empfangssystems in Authentication-Results. Der Selektor in der Nachricht, der DNS-Name unter der signierenden Domain und das Microsoft-CNAME-Ziel haben unterschiedliche Rollen. Leiten Sie den tatsächlich verwendeten s=-Wert nicht aus einem kopierten fremden Zielbeispiel ab.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Beleg | Aussage | Offene Grenze |
|---|---|---|
| Beide passenden CNAMEs | DNS verweist auf die für diese Domain vorgesehenen Ziele. | Kein Beweis aktiver Signierung. |
| Aktivierter Verwaltungsstatus | Der Dienst meldet die Konfiguration als aktiv. | Kein Nachweis jedes Versandwegs. |
Signatur und vertrauenswürdiges dkim=pass | Die konkrete Signatur wurde für diese empfangene Nachricht erfolgreich geprüft. | Keine Inboxgarantie; kein Nachweis, dass der Inhalt unbedenklich ist oder sämtliche Versandwege des Tenants geprüft sind. |
| DMARC-Ergebnis | Erfolgreiche Authentifizierung wird zusätzlich mit der sichtbaren From-Domain abgeglichen. | Ein DKIM-Pass allein ist nicht automatisch ein DMARC-Pass. |
Die Einordnung von Headerbefunden hilft bei der Zuordnung. Für den nächsten Authentifizierungsschritt folgt DMARC-Alignment verstehen. DMARC kann mit passendem SPF oder DKIM bestehen; eine veröffentlichte Policy garantiert keine tatsächliche Ablehnung, Zustellung oder vollständige Phishingabwehr.
Schlüsselrotation und Schlüssellänge getrennt kontrollieren
Microsoft dokumentiert RSA-Schlüssel mit 1024 oder 2048 Bit. Bestehende Schlüssel sind nicht zwingend schon 2048 Bit. RFC 8301 verlangt für RSA-Schlüssel beim Signieren mindestens 1024 Bit und empfiehlt mindestens 2048 Bit; der Standard und der tatsächliche Tenantzustand sind getrennte Belege. Die dokumentierten Exchange-Online-Cmdlets bieten für diese Signierkonfiguration RSA und keine Ed25519-Auswahl. Daraus folgt keine Aussage darüber, welche eingehenden Signaturen ein Empfänger verifizieren kann.
Vor einer geplanten Rotation lesen Sie den Zustand beider Selektoren und den Wechseltermin:
Get-DkimSigningConfig -Identity "example.com" | Format-List Name,Enabled,Status,Selector1CNAME,Selector1KeySize,Selector2CNAME,Selector2KeySize,KeyCreationTime,RotateOnDate,SelectorBeforeRotateOnDate,SelectorAfterRotateOnDateFür eine dazu berechtigte, vorbereitete Änderung beschreibt Microsoft beispielsweise:
Rotate-DkimSigningConfig -Identity "example.com" -KeySize 2048Das ist eine Änderung, kein Prüfkommando. Microsoft nennt für das dokumentierte Verfahren vier Tage beziehungsweise 96 Stunden, bis der neue Schlüssel zum Signieren verwendet wird. Bis dahin bleibt der bisherige aktiv; während einer laufenden Rotation kann keine weitere gestartet werden. Lesen Sie den Zustand erneut und prüfen Sie nach dem angezeigten Wechsel eine neue externe Nachricht. Die 96 Stunden sind eine Microsoft-Verfahrensangabe, keine allgemeine DNS- oder DKIM-Wartefrist und kein hier gemessener Abschluss.
Bei einer Umstellung von 1024 auf 2048 Bit wird in der ersten Rotation nur der als Nächstes aktive Selektor aktualisiert. Microsoft beschreibt eine weitere Rotation nach Abschluss, um auch den anderen umzustellen. Kontrollieren Sie deshalb beide Selector…KeySize-Werte. Löschen Sie nicht vorschnell einen der benötigten CNAMEs und ersetzen Sie einen durch Microsoft verwalteten Schlüssel nicht manuell. Für noch relevante ältere Nachrichten und DNS-Caches gibt es keine aus dieser Anleitung abgeleitete universelle Löschfrist. Ein vermuteter Schlüsselvorfall benötigt eine gesonderte Reaktion.
Beobachtung und nächsten Schritt zuordnen
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Beobachtung | Nächste Prüfung |
|---|---|
CnameMissing | Beide Namen und Zielwerte, die aktive DNS-Zone und Microsofts Erkennungsstand vergleichen. Kein erfundenes Ziel oder blindes Wiederholen der Aktivierung. |
Älteres onmicrosoft.com-Ziel | Mit den aktuellen Werten der bestehenden Domain vergleichen; nicht allein wegen einer neuen Formatbeschreibung ersetzen. |
| Nur einer der CNAMEs vorhanden | Auch den zweiten vorgesehenen Record veröffentlichen; zwei DNS-Namen sind trotzdem kein Rotationsnachweis. |
dkim=none an einer internen Nachricht | Einen passenden externen Versandweg prüfen, bevor Sie die Domain als falsch konfiguriert einstufen. |
Signatur vorhanden, aber fail | Schlüssel, Selektor und Empfängerdiagnose abgleichen; Gateway-/Inhaltsänderungen sind mögliche Ursachen, kein bewiesener Einzelfall. |
| Exchange-Online-Nachricht besteht, anderer Dienst nicht | Zusätzlichen Versanddienst separat konfigurieren und dessen eigene Nachricht prüfen. |
| Nach einer Rotation noch ein 1024-Bit-Schlüssel | Wechselstatus und beide Schlüssellängen prüfen; eine weitere Rotation erst nach Abschluss der ersten einplanen. |
Ein Fehler kann mehrere Ursachen haben. Diese Tabelle ist eine Auswahl begründeter Prüfschritte, keine gemessene Häufigkeitsrangliste. Deaktivierung ist kein allgemeiner Reparaturschritt für eine unklare Signatur.
DNS, Nachricht oder dokumentierten Befund wählen
Der E-Mail-Security-Check untersucht den öffentlichen Domainstand und begrenzt auffindbare beziehungsweise angegebene DKIM-Selektoren. Ein fehlender Fund beweist nicht, dass kein DKIM existiert. Ein gefundener Schlüssel beweist keine aktive Exchange-Online-Signierung. Der DNS-Check liest keine Nachrichten und überwacht spätere Änderungen nicht automatisch.
Die kostenlose DE-Testmail-Beta im begrenzten Startprofil ist über den E-Mailcheck für eine neue eigene Nachricht erreichbar. Prüfen Sie die dortigen Voraussetzungen. Privater Testmailbefund und öffentliche Domainbewertung bleiben getrennt. Ein vollständiger englischer Funktionsweg ist derzeit nicht freigegeben.
Wenn Sie nach einer Änderung eine Unterlage benötigen, zeigt die Reportübersicht den jeweiligen dokumentierten Umfang. Halten Sie DNS-Zeitpunkt, Domain/Selektor, Verwaltungsstatus und beobachtete Nachricht auseinander. Ein solcher Befund ist kein vollständiger Audit-, Zustell- oder Compliance-Nachweis. Diese Anleitung bietet keinen Kaufweg an.
Häufige Fragen
Muss ich neue CNAME-Ziele selbst berechnen?
Nein. Übernehmen Sie die für Ihre konkrete Domain gelieferten Werte aus dem Portal oder Get-DkimSigningConfig. Das neue Format enthält einen von Microsoft vergebenen dynamischen Bestandteil. Ein kopiertes Ziel eines anderen Tenants ist kein Ersatz.
Sind beide Selektoren gleichzeitig aktiv?
Microsoft beschreibt einen aktiven und einen für den Wechsel vorgesehenen Selektor. Zwei sichtbare CNAMEs sagen nicht, welcher Schlüssel eine konkrete Nachricht signiert hat. Dafür lesen Sie den Nachrichtenbefund und den Verwaltungsstatus.
Deckt Microsoft 365 meinen Newsletterdienst mit ab?
Nicht allein dadurch, dass dieselbe sichtbare Absenderdomain verwendet wird. Der tatsächliche Signierer des zusätzlichen Dienstes braucht dessen eigene Einrichtung. Prüfen Sie den Dienst und seinen Versandweg separat.
Weiterführende Anleitungen
DKIM-Grundlagen, allgemeine Einrichtung, SPF und DMARC ordnen die einzelnen Nachweise ein.
Weitere DKIM-Anleitung: Google Workspace
Quellen und Prüfgrenzen
Microsoft: DKIM für eigene Domains, New-DkimSigningConfig, Rotate-DkimSigningConfig, RFC 6376, RFC 8301, Resolve-DnsName.
Für die Unterscheidung zwischen Lesen und Ändern außerdem geprüft: Get-DkimSigningConfig und Set-DkimSigningConfig.
Primärquellenprüfung am 29. September 2026. Microsofts Hauptanleitung nennt den 3. Juli 2026 als Aktualisierungsdatum. Kein Tenant geöffnet, keine DNS-/Signierkonfiguration geändert und keine Nachricht oder Rotation bei Microsoft praktisch geprüft. Die lokalen Signaturproben der allgemeinen DKIM-Anleitung belegen keine Exchange-Online-Aktivierung oder Zustellung. Die Anbieterbefehle wurden hier nicht ausgeführt; Oberfläche, Rechte und Zustand müssen zur konkreten Umgebung passen.