MX für Microsoft 365 einrichten
Schritt-für-Schritt-Anleitung: MX-Record für Exchange Online konfigurieren, im Microsoft 365 Admin Center anlegen oder bei externem DNS-Provider eintragen und mit dig/PowerShell verifizieren — inklusive DNSSEC-Aktivierung und Single-Host-Failover-Strategie.
MX-Records für Microsoft 365 (Exchange Online)
Microsoft 365 nutzt einen einzigen MX-Hostnamen pro Tenant im Format <tenant>.mail.protection.outlook.com mit Priorität 0. Der Hostname leitet sich aus Ihrer Domain ab — Punkte werden durch Bindestriche ersetzt: aus example.com wird example-com.mail.protection.outlook.com, aus ihre-domain.de wird ihre-domain-de.mail.protection.outlook.com. Hinter dem einzelnen Hostnamen steht ein Microsoft-internes Cluster mit automatischem Failover über mehrere Rechenzentren in der EU/USA. Ein eigener Backup-MX ist nicht nötig und kann sogar schädlich sein, weil er Microsofts Exchange-Online-Protection-Filter umgeht.
Als Maßnahme nach NIS2 Art. 21 Abs. 2 lit. h (Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung) und BSI TR-03108 ist die MX-Infrastruktur die Vorbedingung für SPF, DKIM und DMARC. Microsoft als Auftragsverarbeiter (DSGVO Art. 28) liefert für EU-Tenants den AVV plus EU Data Boundary für Speicherort-Kontrolle. Der Wolf-Agents Email Security Check prüft das Microsoft-MX-Pattern (165 Punkte gesamt), verfolgt die A/AAAA-Auflösung des MX-Hostnamen, validiert PTR/FCrDNS und erkennt den klassischen Microsoft-365-Fehler: parallele MX-Records aus früheren Hostern (z.B. mxXX.ionos.com oder smtpin.rzone.de), die nach Migration nicht entfernt wurden.
Hardening-Pfad: Nach dem MX-Record folgt direkt SPF für Microsoft 365 mit v=spf1 include:spf.protection.outlook.com -all, danach DKIM und DMARC. MTA-STS erzwingt zusätzlich Transport-Verschlüsselung — Microsoft unterstützt es seit 2022. Bedrohungs-Cluster: Ein korrekter, DNSSEC-geschützter MX-Record schließt zwei Klassen von Angriffen — DNS-Hijacking-Spoofing auf den MX-Eintrag und SubdoMailing über verwaiste Subdomains mit Microsoft-Legacy-MX (FBI IC3 2024: 21.442 BEC-Beschwerden, 2,77 Mrd. USD Schaden).
MX-Hostname aus Microsoft 365 Admin Center holen
Microsoft generiert den MX-Hostnamen automatisch pro Tenant. Den exakten Wert finden Sie im Admin Center unter Setup → Domains → Ihre Domain → DNS-Records. Die in der MDX-Quelle dokumentierte Ableitung „Punkte werden durch Bindestriche ersetzt“ ist die Faustregel — verlassen Sie sich aber immer auf den im Admin Center angezeigten Wert.
ihre-domain-de.mail.protection.outlook.com. ; Microsoft-Hostname
ihre-domain.de. IN MX 0 ihre-domain-de.mail.protection.outlook.com.Die Microsoft-365-Doku gibt explizit Priorität 0 vor — andere Werte funktionieren technisch, aber bei Migrationen aus anderen Hostern bleiben oft Legacy-MX-Records mit Priorität 10 zurück, die das Routing brechen. Setzen Sie genau einen MX-Record mit Priorität 0 und entfernen Sie alle anderen MX-Einträge.
Hinter <tenant>.mail.protection.outlook.com steht Exchange Online Protection (EOP) mit Geo-redundanten Rechenzentren. Ein eigener Backup-MX (z.B. ein zweiter Hoster mit niedrigerer Priorität) wäre nicht nur unnötig, sondern aktiv schädlich: Angreifer könnten EOP-Filter umgehen, indem sie direkt an Ihren schwächer gesicherten Backup-MX zustellen — der klassische MX-Bypass-Angriff. Die offizielle Empfehlung lautet: nur ein MX-Record, ausschließlich Microsoft. Quelle: learn.microsoft.com/.../mail-flow-best-practices (abgerufen 2026-05-14).
Wer Exchange Hybrid (On-Premises + Microsoft 365) betreibt, nutzt den Hybrid Configuration Wizard (HCW), der Inbound- und Outbound-Connectors automatisch konfiguriert. Wichtig — direktes Microsoft-Zitat: „Inbound mail flow is controlled by your organization's MX record. Inbound internet mail for a hybrid deployment isn't configured by the Hybrid Configuration wizard.“ Heißt: Der MX-Record bleibt der Eingangs-Schalter — Sie entscheiden, ob er auf <tenant>.mail.protection.outlook.com (alle Mails über EOP) oder direkt auf den On-Prem-Server zeigt (zentralisiertes Mail-Routing). Für die Mehrheit der Hybrid-Setups gilt: MX auf Exchange Online, Routing zu On-Prem-Mailboxen via Connector. Quelle: learn.microsoft.com/.../hybrid-configuration-wizard + use-connectors-to-configure-mail-flow (abgerufen 2026-05-16).
MX-Record bei DNS-Provider anlegen
Microsoft 365 verwaltet keinen eigenen DNS-Server für Kundendomains — Sie tragen den MX-Record beim Provider Ihrer Wahl ein (Cloudflare DNS, Hetzner DNS, Route 53, IONOS-Panel, etc.). Bei manchen Registraren kann das Admin Center die Records auch automatisch setzen (Connect-Option), bei externer DNS-Verwaltung manuell.
Beispiel: Manuelle Einrichtung bei externem DNS-Provider
- Microsoft 365 Admin Center → Setup → Domains → Ihre Domain → DNS-Records öffnen
- Den angezeigten MX-Hostnamen kopieren (Format:
<tenant-mit-bindestrich>.mail.protection.outlook.com) - Im DNS-Panel Ihres Providers einen neuen MX-Record anlegen
- Host:
@· Priorität:0· Wert: der kopierte Microsoft-Hostname - Alle anderen MX-Records (aus früheren Hostern) löschen
- Speichern — Propagation typisch 5-30 Minuten, max. 24 Stunden
Bei Migration von IONOS, Strato, Google Workspace oder Self-Hosted-Servern bleiben oft alte MX-Records aktiv. Wenn die Legacy-Records eine niedrigere Priorität haben (z.B. IONOS mit 10), greifen sie vor Microsoft (0) — bei höherer Priorität (z.B. Self-Hosted mit 20) öffnen sie ein Backup-MX-Bypass-Risiko. Lösung: Alle Nicht-Microsoft-MX-Records vollständig löschen, nicht nur überschreiben.
DNSSEC am Apex aktivieren (NIS2 lit. h)
Microsoft signiert die Apex-Zone Ihrer Domain nicht — DNSSEC ist Aufgabe Ihres DNS-Providers. Cloudflare DNS aktiviert DNSSEC mit einem Klick und synchronisiert den DS-Record automatisch zum Registrar; Hetzner DNS und IONOS bieten die gleiche Funktion im Panel. Ohne DNSSEC ist der MX-Record gegen Cache-Poisoning und gezieltes DNS-Hijacking ungeschützt — ein Angreifer kann eingehende Mails auf seinen Server umleiten, ohne dass der Domain-Inhaber es sofort merkt.
Microsoft 365 Mail-Server haben sowohl A- als auch AAAA-Records mit gültigen PTR-Records — das ist Microsoft-intern und benötigt keine Aktion des Kunden. Wer eigene DKIM-Selektoren oder MTA-STS-Subdomains hostet, ergänzt die AAAA-Records dort separat.
MX-Record verifizieren
Nach dem Speichern prüfen Sie die DNS-Propagierung. Die Microsoft-Doku gibt 5-30 Minuten für die meisten Provider an, mit bis zu 24 Stunden bei langen TTL-Werten.
# Linux / macOS
dig MX ihre-domain.de +short
# Windows (PowerShell)
Resolve-DnsName -Name ihre-domain.de -Type MX
# Erwartete Ausgabe:
# 0 ihre-domain-de.mail.protection.outlook.com.
# DNSSEC-Validierung
dig +dnssec MX ihre-domain.de | grep -E "RRSIG|ad;"Validieren Sie zusätzlich mit dem Wolf-Agents Email Security Check — dieser prüft den Microsoft-Hostnamen-Pattern, verfolgt A/AAAA-Auflösung, validiert die DNSSEC-Kette bis zur Root-Zone und erkennt Restbestände alter MX-Records aus früheren Hostern. Das Monitoring überwacht den Record alle 6 Stunden und alarmiert bei Abweichungen vom Soll-Zustand.
Häufige Fehler bei Microsoft 365 MX-Records
Bindestriche statt Punkte vergessen
Problem: Domain example.com mit MX-Eintrag example.com.mail.protection.outlook.com statt example-com.mail.protection.outlook.com — Tippfehler nach dem Pattern . → -. Ursache: manuelle Eingabe statt Copy-Paste aus dem Admin Center. Lösung: Wert immer direkt aus Microsoft 365 → Setup → Domains kopieren.
Legacy-MX nach Migration nicht gelöscht
Problem: Nach Migration von IONOS bleibt 10 mx00.ionos.com aktiv, parallel zu Microsoft 0 example-com.mail.protection.outlook.com. Ursache: Migration nur „neuen Eintrag hinzufügen“, alten nicht entfernt. Lösung: Im DNS-Panel alle MX-Records außer Microsoft löschen — Wolf-Agents Email Security Check zeigt parallele MX-Hostnamen explizit an.
Eigener Backup-MX trotz Microsoft EOP
Problem: Domain hat Microsoft als Prio 0 + eigener Mailserver als Prio 20 als „Backup“. Ursache: Konzeptioneller Fehler — Annahme, dass Microsoft ausfallen könnte. Lösung: Backup-MX entfernen, Microsoft-interne EOP-Redundanz reicht. Andernfalls können Angreifer das EOP-Filter via direkter Zustellung an den Backup-MX vollständig umgehen.
Compliance: NIS2, BSI TR-03108 und DSGVO mit Microsoft 365
Ein korrekt konfigurierter Microsoft-365-MX-Record mit DNSSEC ist der prüfbare Nachweis für NIS2 Art. 21 Abs. 2 lit. h (Kryptografie und Verschlüsselung). Microsoft als EU/US-Auftragsverarbeiter (DSGVO Art. 28) liefert für EU-Tenants AVV und EU Data Boundary — die Speicherung erfolgt für EU-Kunden in EU-Rechenzentren. Microsoft 365 Compliance-Center dokumentiert die TOM nach DSGVO Art. 32 inklusive Verschlüsselung in Transit (TLS), Verschlüsselung at-Rest und Backup-Strategie.
Microsoft 365 MX-Compliance-Stack: NIS2 lit. h (DNSSEC für MX, kundenseitig zu aktivieren) + BSI TR-03108 (MX-Redundanz Microsoft-intern + FCrDNS Microsoft-managed) + DSGVO Art. 32 lit. b (Verfügbarkeit Microsoft-managed). Wolf-Agents-USP: Der Email Security Check erkennt Microsoft-365-MX-Pattern automatisch (Stack-Detection), validiert DNSSEC am Apex und prüft auf parallele Legacy-MX-Records aus früheren Hostern — kein anderer DACH-Scanner deckt diese drei Microsoft-spezifischen Drift-Klassen ab. Cross-Verweis: DNS-Hijacking-Spoofing auf den MX-Eintrag und SubdoMailing über Legacy-MX-Subdomains.
Wie steht Ihre Domain bei MX-Infrastruktur · Microsoft 365?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.