MX-Migration Microsoft 365 zu mx.microsoft: automatisches DNSSEC, Graph API obligatorisch und erforderliche Maßnahmen vor Juli 2026
Von CaptainDNS
Veröffentlicht am 6. März 2026
- 1. Juli 2026: Microsoft provisioniert die MX-Einträge neuer Accepted Domains unter
mx.microsoftstatt untermail.protection.outlook.com(MC1048624, verschoben von Februar 2026) - Wenn deine Domain DNSSEC aktiviert hat, erstreckt sich die Vertrauenskette automatisch auf den MX unter
mx.microsoft-- DANE wird ohne zusätzliche Maßnahmen möglich - Jede Automatisierung, die den MX nach dem Pattern
<domain>.mail.protection.outlook.comzusammenbaut, wird nach dem 1. Juli nicht mehr funktionieren - Die Graph API
serviceConfigurationRecordswird zur einzigen zuverlässigen Quelle - Bestehende Domains sind nicht sofort betroffen, aber Microsoft plant eine schrittweise Migration nach Juli 2026
- Prüfe jetzt, ob deine Domain für DNSSEC bereit ist, mit einem DNSSEC-Check -- das ist die Voraussetzung für den DANE-Schutz
Am 4. April 2025 veröffentlichte Microsoft die Ankündigung MC1048624: Ab dem 1. Juli 2026 erhalten alle neuen Accepted Domains, die zu Exchange Online hinzugefügt werden, ihre MX-Einträge unter der Domain mx.microsoft und nicht mehr unter mail.protection.outlook.com. Der ursprüngliche Termin im Februar 2026 wurde nach Feedback der Community auf Juli verschoben.
Das ist keine kosmetische Änderung. Die Domain mail.protection.outlook.com ist nicht DNSSEC-signiert. Die TLD .microsoft hingegen ist durchgehend signiert. Durch die Migration der MX-Einträge unter mx.microsoft beseitigt Microsoft das wichtigste technische Hindernis für die Einführung von DNSSEC und DANE für eingehende E-Mails auf Exchange Online. Administratoren müssen die MX-Migration nicht mehr manuell auslösen.
Für IT-Teams hat das doppelte Auswirkungen. Einerseits ist es eine gute Nachricht: DNSSEC "gratis", wenn deine Domain bereits signiert ist. Andererseits wird jede Automatisierung, die auf dem Pattern <domain>.mail.protection.outlook.com basiert, nicht mehr funktionieren. Nur die Graph API serviceConfigurationRecords liefert den korrekten MX-Wert.
Zielgruppe: Microsoft-365-Administratoren, MSPs mit Multi-Domain-Tenants, DevOps-Teams mit automatisierten DNS-Provisioning-Workflows.
Was sich am 1. Juli 2026 konkret ändert
Vorher: mail.protection.outlook.com
Bisher provisioniert Microsoft beim Hinzufügen einer benutzerdefinierten Domain zu Exchange Online den MX in einem vorhersehbaren Format:
captaindns.com. 3600 IN MX 0 captaindns-com.mail.protection.outlook.com.
Dieses Format erlaubte es, den MX-Wert anhand des Domainnamens zu erraten: Punkte durch Bindestriche ersetzen und .mail.protection.outlook.com anhängen. Viele Automatisierungen (PowerShell-Skripte, Terraform-Workflows, MSP-Provisioning-Tools) nutzen dieses Pattern.
Nachher: mx.microsoft
Ab Juli 2026 erhalten neue Accepted Domains einen MX im folgenden Format:
captaindns.com. 3600 IN MX 0 captaindns-com.o-v1.mx.microsoft.
Das Suffix o-v1.mx.microsoft lässt sich nicht allein aus dem Domainnamen ableiten. Der genaue Wert muss über das Exchange Admin Center oder die Graph API abgerufen werden.
Detaillierte Timeline
| Datum | Ereignis |
|---|---|
| 4. April 2025 | Veröffentlichung der Ankündigung MC1048624 |
| Februar 2026 | Ursprünglich geplanter Termin (verschoben) |
| 2. Februar 2026 | Update: Verschiebung auf Juli 2026 |
| Anfang Juli 2026 | Beginn der schrittweisen Umstellung |
| Ende Juli 2026 | Alle neuen Accepted Domains unter mx.microsoft |
| Nach Juli 2026 | Schrittweise Migration bestehender Domains (kein genauer Termin kommuniziert) |
Wer ist betroffen?
| Situation | Auswirkung |
|---|---|
| Bestehende Domain, MX bereits konfiguriert | Keine sofortige Auswirkung. Der aktuelle MX unter mail.protection.outlook.com funktioniert weiterhin |
| Neue Domain nach Juli 2026 hinzugefügt | Der MX liegt unter mx.microsoft. Automatisierungen, die auf dem alten Pattern basieren, schlagen fehl |
| DNS-Provisioning-Automatisierung | Handlungsbedarf: Migration auf die Graph API serviceConfigurationRecords |
| DNSSEC bereits auf der Domain aktiv | Bonus: DNSSEC erstreckt sich automatisch auf den MX, DANE ohne Reibungsverluste aktivierbar |
Warum diese Änderung? Das DNSSEC-Problem von outlook.com
Die Domain outlook.com -- und damit auch mail.protection.outlook.com -- ist nicht DNSSEC-signiert. Das ist eine historische Entscheidung von Microsoft: Eine so massive Domain mit so vielen dynamischen Subdomains zu signieren, bringt erhebliche betriebliche Herausforderungen mit sich.
Das Problem: Ohne DNSSEC auf dem MX ist DANE unmöglich. Ein sendender Server will das TLS-Zertifikat von Exchange Online über DANE verifizieren. Er muss die DNSSEC-Vertrauenskette durchgehend validieren können, vom MX bis zum TLSA. Wenn der MX auf eine unsignierte Domain zeigt, ist die Kette unterbrochen.
Microsofts Lösung: die TLD .microsoft. Diese Brand TLD ist durchgehend DNSSEC-signiert. Mit der Infrastruktur mx.microsoft erhält Microsoft eine DNS-Zone, die vollständig unter eigener Kontrolle und signiert ist -- ohne die von outlook.com geerbten Einschränkungen.
Die vollständige DNSSEC-Vertrauenskette wird zu:
root (.) → .microsoft → mx.microsoft → o-v1.mx.microsoft → captaindns-com.o-v1.mx.microsoft
Jedes Glied ist signiert. Die von Microsoft unter _25._tcp.captaindns-com.o-v1.mx.microsoft veröffentlichten TLSA-Einträge sind von jedem DANE-kompatiblen sendenden Server überprüfbar.
Für ein detailliertes Verständnis der DNSSEC-Vertrauenskette lies unseren Leitfaden zur DNSSEC-Vertrauenskette.
Automatisches DNSSEC: Was du kostenlos bekommst
Die Änderung MC1048624 hat einen wichtigen Nebeneffekt: Wenn deine Domain bereits DNSSEC-signiert ist, profitierst du automatisch vom durchgehenden DNSSEC-Schutz für eingehende E-Mails -- ohne jegliche Aktion im Exchange Admin Center.
Szenario 1: Deine Domain hat kein DNSSEC
Funktional ändert sich nichts. Der MX zeigt auf mx.microsoft statt auf mail.protection.outlook.com, aber die DNS-Auflösung funktioniert normal. Kein DANE, keine TLSA-Verifizierung -- das Verhalten ist identisch mit heute.
Szenario 2: Deine Domain hat DNSSEC aktiv
Dann passiert Folgendes:
- Der sendende Server löst den MX von
captaindns.comauf →captaindns-com.o-v1.mx.microsoft - Die Antwort ist DNSSEC-signiert (deine Domain ist signiert,
mx.microsoftist signiert) - Der Server fragt den TLSA für
_25._tcp.captaindns-com.o-v1.mx.microsoftab - Microsoft veröffentlicht automatisch die TLSA-Einträge, die den Zertifikaten von Exchange Online entsprechen
- Der Server verifiziert das TLS-Zertifikat über DANE -- Serverauthentifizierung ohne Abhängigkeit von Zertifizierungsstellen
Ergebnis: Schutz gegen Man-in-the-Middle-Angriffe auf den E-Mail-Transport -- automatisch. Vor dieser Änderung erforderte DANE auf Exchange Online ein manuelles Aktivierungsverfahren. Nach Juli 2026 ist es für neue Domains transparent.
Die Graph API wird zur einzigen zuverlässigen Quelle
Das ist der kritische Handlungspunkt der Ankündigung MC1048624. Microsoft sagt es ausdrücklich:
"After July 1, 2026, List serviceConfigurationRecords Graph API will be the only source of truth for your Accepted Domains' MX record value."
Das Problem der aktuellen Automatisierungen
Viele Provisioning-Skripte bauen den MX nach Konvention zusammen:
# VORHER: vorhersehbares Pattern (FUNKTIONIERT NICHT MEHR nach Juli 2026)
$domain = "captaindns.com"
$mx = $domain.Replace(".", "-") + ".mail.protection.outlook.com"
# Ergebnis: captaindns-com.mail.protection.outlook.com
Dieses Pattern funktioniert mit mx.microsoft nicht mehr. Das Suffix kann variieren und ist nicht ableitbar.
Die Lösung: serviceConfigurationRecords
# NACHHER: Graph API verwenden (OBLIGATORISCH nach Juli 2026)
Connect-MgGraph -Scopes "Domain.Read.All"
$records = Get-MgDomainServiceConfigurationRecord -DomainId "captaindns.com"
$mxRecord = $records | Where-Object { $_.RecordType -eq "Mx" }
$mxValue = $mxRecord.AdditionalProperties.mailExchange
# Ergebnis: captaindns-com.o-v1.mx.microsoft (tatsaechlicher Wert, nicht geraten)
Der entsprechende REST-Endpoint:
GET https://graph.microsoft.com/v1.0/domains/captaindns.com/serviceConfigurationRecords
Authorization: Bearer {token}
Die JSON-Antwort enthält den genauen MX-Wert im Feld mailExchange des Objekts domainDnsMxRecord:
{
"@odata.type": "microsoft.graph.domainDnsMxRecord",
"isOptional": false,
"label": "captaindns.com",
"recordType": "Mx",
"supportedService": "Email",
"ttl": 3600,
"mailExchange": "captaindns-com.o-v1.mx.microsoft",
"preference": 0
}
Erforderliche Berechtigungen: Domain.Read.All (Minimum). Der angemeldete Benutzer muss die Rolle Domainnamensadministrator oder Globaler Leser besitzen.
Weitere von der API zurückgegebene Records
Die API gibt auch die DKIM-CNAMEs, Autodiscover, SPF und SRV für Teams zurück. Das ist eine gute Gelegenheit, alle deine DNS-Automatisierungen auf diese einzige Quelle zu migrieren:
| OData-Typ | Record | Wichtige Felder |
|---|---|---|
domainDnsMxRecord | MX | mailExchange, preference |
domainDnsTxtRecord | TXT (SPF) | text |
domainDnsCnameRecord | CNAME (DKIM, Autodiscover) | canonicalName |
domainDnsSrvRecord | SRV (Teams) | nameTarget, port, priority |
Umstellung vorbereiten: MTA-STS und TLS-RPT
Parallel zu DNSSEC und DANE empfiehlt Microsoft, MTA-STS und TLS-RPT für einen umfassenden Schutz des E-Mail-Transports einzusetzen.
MTA-STS zwingt sendende Server, TLS für die E-Mail-Zustellung zu verwenden, auch wenn sie DANE nicht unterstützen. Es ist ein ergänzendes Sicherheitsnetz:
_mta-sts.captaindns.com. 3600 IN TXT "v=STSv1; id=20260306T000000"
TLS-RPT sendet dir Berichte, wenn ein sendender Server keine TLS-Verbindung mit deiner Domain herstellen konnte:
_smtp._tls.captaindns.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
Für die detaillierte Konfiguration lies unsere Anleitungen: MTA-STS für Microsoft 365 und TLS-RPT komplett.
Maßnahmenplan vor Juli 2026
- Automatisierungen prüfen: Suche nach jedem Skript, Terraform-Workflow, Ansible-Playbook oder MSP-Tool, das einen MX nach dem Pattern
mail.protection.outlook.comzusammenbaut. Das hat höchste Priorität - Auf Graph API migrieren: Ersetze die konventionsbasierte Konstruktion durch einen Aufruf an
serviceConfigurationRecords. Teste schon jetzt mit einer Testdomain - DNSSEC auf deinen Domains aktivieren: Bei deinem Registrar oder DNS-Hoster. Das ist die Voraussetzung, um nach der Migration automatisch von DANE zu profitieren
- Deine DNSSEC-Konfiguration prüfen: Verwende
dig +dnssec captaindns.com SOA, um zu bestätigen, dass das AD-Flag vorhanden ist - MTA-STS und TLS-RPT einrichten: Vervollständige die Transportsicherheit vor der Migration
- Microsoft-Ankündigungen verfolgen: MC1048624 wurde bereits einmal verschoben. Verfolge die Updates im Microsoft 365 Message Center
FAQ
Sind meine bestehenden Domains von dieser Änderung betroffen?
Nein, nicht sofort. MC1048624 betrifft nur neue Accepted Domains, die nach dem 1. Juli 2026 hinzugefügt werden. Deine bestehenden Domains behalten ihren MX unter mail.protection.outlook.com. Allerdings plant Microsoft eine schrittweise Migration der bestehenden Domains nach diesem Datum, ohne genauen Zeitplan. Es ist ratsam, deine Automatisierungen schon jetzt vorzubereiten.
Was passiert, wenn meine Automatisierung nach Juli 2026 noch das alte Pattern verwendet?
Wenn du nach Juli 2026 eine neue Domain zu Exchange Online hinzufügst und deine Automatisierung den MX nach mail.protection.outlook.com zusammenbaut, wird der MX falsch sein. Der Mailflow funktioniert für diese Domain nicht, bis du den MX-Wert korrigierst -- entweder entsprechend dem Wert im Exchange Admin Center oder dem von der Graph API zurückgegebenen Wert.
Muss DANE nach dieser Änderung manuell aktiviert werden?
Für neue Domains, die nach Juli 2026 provisioniert werden: Wenn deine Domain DNSSEC aktiviert hat, erstreckt sich die DNSSEC-Vertrauenskette automatisch auf den MX unter mx.microsoft, und Microsoft veröffentlicht die TLSA-Einträge. Du musst für eingehendes DANE nichts weiter tun. Für bestehende Domains, die noch unter mail.protection.outlook.com laufen, bleibt das manuelle Verfahren erforderlich.
Was ist der Unterschied zwischen automatischem DANE und manuell aktiviertem DANE?
Das Endergebnis ist identisch: ein DNSSEC-signierter TLSA-Eintrag, der das TLS-Zertifikat von Exchange Online authentifiziert. Der Unterschied liegt im Weg dorthin. Bei der manuellen Aktivierung (bestehende Domains) musst du die MX-Migration per PowerShell auslösen. Bei neuen Domains nach Juli 2026 liegt der MX bereits unter mx.microsoft, und die TLSA-Einträge werden automatisch veröffentlicht, sofern DNSSEC auf deiner Domain aktiv ist.
Ist die Graph API serviceConfigurationRecords in Sovereign Clouds verfügbar?
Ja. Der Endpoint ist in der globalen Cloud, US Government L4, US Government L5 (DoD) und 21Vianet (China) verfügbar. Die erforderlichen Berechtigungen sind identisch: mindestens Domain.Read.All.
Wie prüfe ich, ob meine Domain für DNSSEC bereit ist?
Führe dig +dnssec captaindns.com SOA aus und prüfe, ob das Flag ad (Authenticated Data) in der Antwort erscheint. Falls nicht, aktiviere DNSSEC bei deinem Registrar. Lies unseren Leitfaden zur DNSSEC-Aktivierung für die detaillierte Vorgehensweise je nach DNS-Anbieter.
Betrifft diese Änderung SPF, DKIM und DMARC?
Nein. SPF (include:spf.protection.outlook.com), DKIM (CNAME auf *.onmicrosoft.com) und DMARC sind nicht betroffen. Nur der MX-Eintrag ändert sein Suffix. Die E-Mail-Authentifizierungsmechanismen funktionieren wie bisher weiter.
Warum hat Microsoft den Termin von Februar auf Juli 2026 verschoben?
Microsoft hat keinen offiziellen Grund genannt. Die Verschiebung wurde am 2. Februar 2026 in einem Update des MC1048624 mit dem Hinweis "Thank you for your patience" angekündigt. Es ist wahrscheinlich, dass das Feedback der Community bezüglich mangelnder Vorbereitung der Automatisierungen diese zusätzliche Frist motiviert hat.
Vergleichstabellen herunterladen
Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.
Glossar
- Accepted Domain: Benutzerdefinierte Domain, die einem Microsoft-365-Tenant im Exchange Admin Center hinzugefügt und für den E-Mail-Empfang konfiguriert wurde.
- MC1048624: Kennung der Microsoft-Ankündigung im Microsoft 365 Message Center, die die DNS-Migration der MX-Einträge zu mx.microsoft beschreibt.
- serviceConfigurationRecords: Endpoint der Microsoft Graph API, der die Liste der für die Aktivierung der Microsoft-365-Dienste auf einer bestimmten Domain erforderlichen DNS-Einträge zurückgibt.
- Brand TLD: Top-Level-Domain, die einer Marke entspricht (z. B.
.microsoft,.google,.amazon), vom Unternehmen selbst verwaltet und oft DNSSEC-signiert. - DANE (DNS-based Authentication of Named Entities): Mechanismus, der ein TLS-Zertifikat über einen DNSSEC-signierten TLSA-Eintrag an einen Domainnamen bindet und so die Abhängigkeit von Zertifizierungsstellen eliminiert.
