DKIM in Microsoft 365 aktivieren: die Schritt-für-Schritt-Anleitung

Von Thomas · virtueller CISO · 2026-07-26

Ein frisch eingerichteter Microsoft-365-Tenant signiert seine ausgehende Post bereits mit DKIM. Die Überraschung steckt in der signierenden Domain: contoso.onmicrosoft.com, die bei der Einrichtung vergebene technische Domain — nicht die eigene Domain, die in der Absenderadresse steht. Kryptografisch ist die Signatur einwandfrei; für DMARC ist sie wertlos, denn die Domain, die signiert, ist nicht die Domain, die versendet. DKIM in Microsoft 365 zu aktivieren heißt im nützlichen Sinn des Wortes: Exchange Online dazu bringen, mit der Domain der Organisation zu signieren — nicht mehr und nicht weniger.

Der Eingriff ist einfacher als sein Ruf: kein Schlüssel zu erzeugen, keine Datei anzufassen. Microsoft erzeugt und hostet das Schlüsselpaar; es bleibt, zwei CNAME-Einträge in der DNS-Zone der Domain zu veröffentlichen und anschließend einen Schalter im Defender-Portal oder per PowerShell umzulegen. Die meisten Fehlschläge gehen auf prosaische Details zurück — ein als TXT eingetragener CNAME, ein von der DNS-Oberfläche verdoppeltes Domain-Suffix, eine Aktivierung, die vor dem Ende der DNS-Propagation versucht wird.

Dieser Leitfaden behandelt ausschließlich die DKIM-Seite von Microsoft 365, von der Diagnose bis zur Selektor-Rotation. Die SPF-Seite — der include:spf.protection.outlook.com und seine Feinheiten — ist eine eigene Baustelle, behandelt in SPF für Microsoft 365 und Google Workspace; hier wird sie nicht wiederholt.

Warum die Standardsignatur DMARC nicht hilft

Bei der Einrichtung eines Tenants vergibt Microsoft eine technische Domain unter onmicrosoft.com — die sogenannte MOERA (Microsoft Online Email Routing Address). Solange DKIM auf der eigenen Domain nicht konfiguriert ist, signiert Exchange Online die gesamte ausgehende Post mit dieser technischen Domain: Im DKIM-Signature-Header steht d=contoso.onmicrosoft.com. Jeder Empfänger, der die Signatur prüft, erhält ein völlig korrektes dkim=pass.

Der Haken passt in ein Wort: Ausrichtung (alignment). DMARC begnügt sich nicht mit einem DKIM, das lediglich besteht; verlangt wird, dass die signierende Domain (d=) zur Domain der sichtbaren Absenderadresse (From:) passt. Eine Nachricht von rechnung@beispiel.de, aber signiert mit d=contoso.onmicrosoft.com, ergibt ein gültiges, jedoch nicht ausgerichtetes DKIM: Für die DMARC-Auswertung ist das, als trüge die Nachricht gar keine Signatur. Richtet sich auch SPF nicht aus — ein häufiger Fall, sobald eine Weiterleitung im Spiel ist —, scheitert die Nachricht an DMARC, obwohl sie völlig legitim ist.

Deshalb zeigen die aggregierten Berichte einer unkonfigurierten Microsoft-365-Domain typischerweise große Mengen an Post, die authentifiziert ist… im Namen einer anderen Domain. Die Korrektur verlangt weder Migration noch Werkzeugwechsel: die eigene Domain als signierende Domain deklarieren, zwei CNAMEs veröffentlichen, die Signatur einschalten. Der Rest dieses Leitfadens geht jede dieser Etappen durch.

Wo DKIM aktiviert wird: Defender-Portal oder PowerShell

Die Aktivierung wohnt an zwei Orten, nach Wahl — das Ergebnis ist identisch.

Das Microsoft-Defender-Portal. Die Seite liegt auf security.microsoft.com, unter E-Mail und Zusammenarbeit → Richtlinien und Regeln → Bedrohungsrichtlinien → Einstellungen für die E-Mail-Authentifizierung, Reiter DKIM. Die Konsole listet alle akzeptierten Domains des Tenants. Die Auswahl der eigenen Domain öffnet ein Panel mit dem Schalter „Nachrichten für diese Domäne mit DKIM-Signaturen signieren". Beim ersten Versuch antwortet das Portal in der Regel mit der Aufforderung, die DKIM-Schlüssel zu erstellen: Dieser obligatorische Schritt erzeugt das Schlüsselpaar auf Microsofts Seite und zeigt die beiden zu veröffentlichenden CNAME-Werte an.

Exchange Online PowerShell. Das Kommandozeilen-Pendant, vorzuziehen, sobald mehrere Domains im Spiel sind oder Nachvollziehbarkeit zählt:

Connect-ExchangeOnline
New-DkimSigningConfig -DomainName beispiel.de -KeySize 2048 -Enabled $false
Get-DkimSigningConfig -Identity beispiel.de |
  Format-List Selector1CNAME, Selector2CNAME

New-DkimSigningConfig legt die Signaturkonfiguration an — hier ausdrücklich mit einem 2048-Bit-Schlüssel, wo die Oberfläche lange Zeit 1024-Bit-Schlüssel erzeugte — und Get-DkimSigningConfig liefert die exakten CNAME-Ziele. Der Parameter -Enabled $false hält die Signatur ausgeschaltet, bis das DNS bereit ist; die Aktivierung folgt später mit Set-DkimSigningConfig -Enabled $true.

Die zwei CNAMEs: selector1 und selector2

Die Werte folgen einem vorhersehbaren Muster. Für beispiel.de im Tenant contoso lauten die beiden zu veröffentlichenden Einträge:

selector1._domainkey.beispiel.de  CNAME  selector1-beispiel-de._domainkey.contoso.onmicrosoft.com
selector2._domainkey.beispiel.de  CNAME  selector2-beispiel-de._domainkey.contoso.onmicrosoft.com

Der Teil beispiel-de ist die eigene Domain, deren Punkte zu Bindestrichen werden; contoso.onmicrosoft.com ist die Initial-Domain des Tenants. Die Konsole zeigt diese Werte wortwörtlich an — es gibt keinen Grund, sie von Hand nachzubauen, aber wer das Muster kennt, erkennt einen Tippfehler auf den ersten Blick.

Zwei Designentscheidungen verdienen eine Erklärung. Erstens: warum ein CNAME und kein TXT. Der öffentliche Schlüssel wird nicht in der Zone der Domain veröffentlicht; er bleibt bei Microsoft gehostet, am Ende des Alias. Genau diese Indirektion ist es, die später die Schlüsselrotation ohne jeden DNS-Eingriff erlaubt. Zweitens: warum zwei Selektoren. selector1 und selector2 wechseln sich ab — einer signiert, der andere wartet auf die nächste Rotation. Welche Rolle der Selektor in einer DKIM-Signatur genau spielt und wie er sich in den Headern beobachten lässt, zerlegt der DKIM-Selektor erklärt.

Dieses Funktionsprinzip unterscheidet Microsoft 365 vom generischen Verfahren, bei dem die Administration das Schlüsselpaar selbst erzeugt und den öffentlichen Schlüssel als TXT veröffentlicht — der Weg, den wie sich ein DKIM-Schlüssel erzeugen lässt beschreibt. Hier verlässt der private Schlüssel Microsofts Infrastruktur nie: weniger Freiheit, aber auch weniger Gelegenheiten, ihn zu kompromittieren.

DNS-Veröffentlichung und die klassischen Fallen

Auf dem Papier dauert die Veröffentlichung zweier CNAMEs drei Minuten. In der Praxis kehren vier Fallen immer wieder.

Der als TXT eingetragene CNAME. Der häufigste Fehler: An andere Plattformen gewöhnt, trägt die Administration den Wert in einen TXT-Eintrag ein. Microsoft 365 arbeitet aber ausschließlich über Aliasse — die Prüfung schlägt fehl, solange der Eintragstyp nicht CNAME lautet. Google Workspace veröffentlicht den öffentlichen Schlüssel dagegen direkt als TXT: zwei Logiken für denselben Standard, verglichen in DKIM in Google Workspace aktivieren.

Das verdoppelte Suffix. Viele DNS-Oberflächen hängen die Domain automatisch an den eingegebenen Namen an. Aus selector1._domainkey.beispiel.de im Namensfeld wird dann selector1._domainkey.beispiel.de.beispiel.de — ein perfekt veröffentlichter, perfekt nutzloser Eintrag. Eine dig-Abfrage oder eine Online-Prüfung räumt den Zweifel sofort aus.

Die verfrühte Aktivierung. Solange die CNAMEs öffentlich nicht auflösen, verweigert das Portal die Aktivierung mit einer Meldung wie „CNAME record does not exist". Das ist kein Konfigurationsfehler, sondern die DNS-Propagation, die ihren Lauf nimmt: einige Minuten bis einige Stunden je nach TTL und Hoster, wobei Microsoft vorsichtshalber bis zu 48 Stunden ankündigt. Ein späterer neuer Versuch genügt.

Mehrere Domains. Jede akzeptierte Domain des Tenants hat ihre eigene Konfiguration: ihre zwei CNAMEs, ihren Schalter, ihre Rotation. DKIM auf beispiel.de zu aktivieren deckt weder separat deklarierte Subdomains noch die übrigen Domains des Tenants ab. Die onmicrosoft.com-Domain selbst braucht nichts: Microsoft signiert sie nativ.

Ein letzter Punkt zum Geltungsbereich: Die Signatur von Exchange Online deckt die Post ab, die Exchange Online verlässt. Drittplattformen, die im Namen der Domain versenden — Marketing-Routing, Rechnungsstellung, Anwendungsbenachrichtigungen —, signieren mit eigenen Selektoren, die jeweils dort zu konfigurieren sind.

Die Verifikation: Header und externe Prüfung

Sobald der Schalter umgelegt ist (oder Set-DkimSigningConfig -Identity beispiel.de -Enabled $true gelaufen ist), steht der Beweis in den Headern. Eine Testnachricht an ein externes Postfach — Gmail oder Outlook.com genügen — muss zwei Dinge zeigen. Zuerst die Signatur selbst:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=beispiel.de; s=selector1; ...

Das d= trägt jetzt die eigene Domain, das s= einen der beiden Selektoren. Dann das Urteil des Empfängers in Authentication-Results:

Authentication-Results: ...; dkim=pass header.d=beispiel.de;
  dmarc=pass header.from=beispiel.de

dkim=pass mit header.d=beispiel.de: Die Signatur ist gültig und ausgerichtet. Ist bereits ein DMARC-Eintrag veröffentlicht, folgt das dmarc=pass mechanisch.

Auf der Konsolenseite muss Get-DkimSigningConfig den Wert Enabled : True zeigen, das Defender-Portal den Schalter in aktiver Stellung. Für den Blick von außen, ohne in Header einzutauchen, liefert eine Online-Prüfung der Domain den beobachtbaren DNS-Zustand — veröffentlichte Einträge, Auflösung der Selektoren — und liest ihn gegen die geltende DMARC-Policy. In den folgenden Tagen bestätigen die aggregierten Berichte den Umschwung: Die von Exchange Online versendeten Volumina wandern zu ausgerichtetem DKIM.

Selektor-Rotation ohne Eingriff in die DNS-Zone

Ein DKIM-Schlüssel ist nicht für die Ewigkeit gedacht: Gute Praxis verlangt eine periodische Rotation, und genau dafür schreibt Microsoft zwei Selektoren vor. Ausgelöst wird die Rotation per Knopf im Portal („DKIM-Schlüssel rotieren") oder in PowerShell:

Rotate-DkimSigningConfig -Identity beispiel.de -KeySize 2048

Die Mechanik ist elegant. Microsoft erzeugt ein neues Schlüsselpaar und veröffentlicht den neuen öffentlichen Schlüssel hinter dem inaktiven Selektor — auf Microsofts Seite, am Ende des CNAME. Sobald die Propagation steht, wechselt die Signatur auf den neuen Selektor; der alte wird seinerseits zur Reserve für die nächste Rotation. Zu keinem Zeitpunkt wird die DNS-Zone der Domain angefasst: Die am ersten Tag veröffentlichten CNAMEs bleiben lebenslang gültig. Genau das ist der Sinn der Alias-Indirektion.

Die Rotation ist zugleich die Gelegenheit, eine gealterte Konfiguration zu modernisieren: Vor Jahren eingerichtete Tenants signieren mitunter noch mit 1024 Bit; eine Rotation mit -KeySize 2048 hebt den Schlüssel ohne eine Sekunde Unterbrechung auf den aktuellen Stand. Eine jährliche Rotation, angedockt an ein bestehendes Sicherheits-Review, ist ein vernünftiger Rhythmus — die Operation ist schmerzfrei, es gibt keinen Grund, auf sie zu verzichten.

Was ausgerichtetes DKIM für DMARC freischaltet

DKIM auf der eigenen Domain zu aktivieren ist kein Selbstzweck: Es ist das Teil, das DMARC auf einem Microsoft-365-Tenant wirklich belastbar macht.

Erstens, weil DKIM überlebt, wo SPF bricht. Eine Weiterleitung von Postfach zu Postfach, eine Verteilerliste, ein Relay: In all diesen Szenarien ändert sich die sendende IP, und SPF verliert die Ausrichtung. Die DKIM-Signatur reist dagegen im Inneren der Nachricht und bleibt bei der Ankunft prüfbar, solange der signierte Inhalt unangetastet ist. Eine Domain, deren Exchange-Online-Post signiert und ausgerichtet ist, behält auf den meisten Weiterleitungswegen ein dmarc=pass — die unverzichtbare Bedingung, um eine strikte Policy ins Auge zu fassen, ohne legitime Post zu verlieren.

Zweitens, weil die Berichte lesbar werden. Mit ausgerichtetem DKIM heben sich die legitimen Volumina von Exchange Online scharf von den nicht authentifizierten Quellen ab; was dann noch scheitert, verdient eine echte Untersuchung — eine vergessene Plattform oder ein Fälschungsversuch. Auf dieser gesunden Basis klettert die Policy von p=none über p=quarantine zu p=reject, mit kommentierten Vorlagen für jede Etappe in den DMARC-Eintragsbeispielen zum Anpassen.

Schließlich ist die DKIM-Ausrichtung die Voraussetzung für sichtbarere Ergebnisse: die Anforderungen der großen Postfachanbieter an Massenversender und perspektivisch die Logo-Anzeige über BIMI, die eine durchgesetzte DMARC-Policy voraussetzt.

Fazit

Microsoft 365 signiert standardmäßig mit der technischen Domain onmicrosoft.com: ein gültiges, aber nicht ausgerichtetes DKIM, für DMARC also stumm. Die nützliche Aktivierung passt in drei Handgriffe — die Signaturkonfiguration anlegen (Defender-Portal oder New-DkimSigningConfig), die beiden CNAMEs selector1/selector2._domainkey mit Ziel contoso.onmicrosoft.com veröffentlichen, dann die Signatur einschalten, sobald die Propagation steht. Die Fallen sind bekannt: ein als TXT eingetragener CNAME, ein von der DNS-Oberfläche verdoppeltes Suffix, eine verfrühte Aktivierung und mehrere Domains, von denen jede ihr eigenes Paar verlangt. Die Verifikation steht in den Headern (dkim=pass header.d=beispiel.de), die Rotation kommt ohne Zonen-Eingriff aus, und der Gewinn ist unmittelbar: eine DKIM-Ausrichtung, die Weiterleitungen übersteht und den Weg zu p=reject öffnet.

Zur Standortbestimmung zeigt eine kostenlose DMARC-Analyse der Domain in Sekunden den Zustand der veröffentlichten Einträge und was noch zu korrigieren bleibt. Und um die Wirkung der Aktivierung in den aggregierten Berichten zu verfolgen — Woche für Woche, Quelle für Quelle —, öffnet die Einrichtung eines Kontos das Dashboard, das diese Rohdaten in einen Aktionsplan Richtung durchgesetzter Policy verwandelt.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos