Microsoft 365

Exchange Online Multi-Geo: In-Region Routing erklärt

Multi-Geo In-Region Routing in Exchange Online ist seit Dezember 2025 allgemein verfügbar. Eingehende E-Mails landen damit nicht mehr zuerst in der Primary Provisioned Geography des Tenants, sondern direkt in der Region des Empfängers, inklusive DNSSEC-fähigem mx.microsoft-Endpunkt.

Indeno GmbH

01 Mai 2026 — 5 Min. Lesezeit

Mit der seit Dezember 2025 allgemein verfügbaren Funktion Multi-Geo In-Region Routing (IRR) können Administratoren von Exchange Online steuern, in welcher geografischen Region eingehende E-Mails erstmals in den Microsoft-365-Tenant eintreten. Bisher landete jede eingehende Nachricht zuerst in der Primary Provisioned Geography des Tenants und wurde von dort intern zum tatsächlichen Postfach weitergeleitet. Mit IRR gehen die Mails direkt in die Region, in der das Empfängerpostfach gehostet ist. Microsoft hat die General Availability am 13. Februar 2026 auf dem Exchange Team Blog bekannt gegeben. [1]

Was sich mit In-Region Routing ändert

Vergleich zwischen Mailflow ohne und mit Multi-Geo In-Region Routing in Exchange Online: Ohne IRR treffen eingehende Mails zuerst in der Primary Provisioned Geography ein und werden dann regionenübergreifend zum Empfänger geroutet; mit IRR treffen sie direkt in der Region des Empfängers ein, sofern dessen PreferredDataLocation mit der MailFlowRegion der Domain übereinstimmt

Ohne In-Region Routing schreibt Exchange Online jede eingehende Nachricht zunächst auf einen Endpunkt in der Primary Provisioned Geography des Tenants. Erst von dort geht die Mail per interner Weiterleitung in die Region des Postfachs, in Multi-Geo-Tenants mit Nutzern außerhalb der Primary Geography entspricht das zusätzlich einem Cross-Region-Hop. Mit aktivem IRR verschiebt sich der Einstiegspunkt: Die Mail trifft direkt in der Empfängerregion ein, vorausgesetzt, die zugehörige akzeptierte Domain ist auf diese Region ausgerichtet und der Nutzer ist dort gehostet. [1][2]

Microsoft nennt explizit zwei Mailflows, die durch IRR adressiert werden: anonymer eingehender Verkehr (klassischer SMTP-Empfang von fremden Absendern) und hybrider eingehender Verkehr aus On-Premises-Exchange-Umgebungen. Authentifizierte Clientverbindungen sind im Microsoft-Blog nicht gesondert ausgeführt. [1]

Wichtig für das Verständnis: IRR wird pro Nutzer ausgewertet, nicht pro Domain oder Tenant. Eine Domain kann als IRR-Domain mit MailFlowRegion GBR konfiguriert sein, wirkt aber nur für Nutzer, deren primäre E-Mail-Adresse in dieser Domain liegt und deren PreferredDataLocation ebenfalls GBR ist. Nutzer in anderen Regionen laufen weiter im bisherigen Flow. [2]

Voraussetzungen

IRR baut auf Multi-Geo auf und ist nur in einem entsprechend lizenzierten Tenant nutzbar. Microsoft nennt in der Konfigurationsdokumentation folgende Pflichten: [2]

Microsoft 365 Multi-Geo-Lizenz für jeden Nutzer, der in einer Satellite Geography gehostet werden soll, zusätzlich eine zweite Lizenz, die Mail-Funktionalität einschließt. Multi-Geo ist eine Add-on-Lizenz für Enterprise- oder CSP-Verträge und setzt einen Minimum-Purchase von 5 Prozent der berechtigten Microsoft-365-Benutzer voraus. [3]
Die akzeptierte Domain muss im Exchange Admin Center als Accepted Domain sichtbar sein.
Das primäre E-Mail-Adress-Feld des Nutzers liegt in der IRR-aktivierten Domain.
Die PreferredDataLocation des Nutzers entspricht der MailFlowRegion der Domain. Nur wenn diese Ausrichtung stimmt, verarbeitet Exchange die Nachricht in derselben Region, in der sie auch gespeichert wird.
Auf On-Premises-Seite dürfen Zertifikate oder IP-Adressen, die in Connectors für den Mailfluss aus dem lokalen Exchange in Exchange Online verwendet werden, nicht gleichzeitig für den Mail-Versand aus derselben Umgebung an externe Organisationen über das Internet genutzt werden. Andernfalls kann die Mail-Zuordnung bei IRR-aktivierten Empfänger-Organisationen fehlschlagen.
Der neue MX-Zielpunkt muss auf mx.microsoft zeigen. Dieser Endpunkt ist von Microsoft mit DNSSEC signiert. Ist die eigene Accepted Domain ebenfalls DNSSEC-signiert, greift die vollständige DNSSEC-Validierung bis zum IRR-MX-Record. Ohne DNSSEC an der Accepted Domain funktioniert der Mailflow trotzdem, allerdings ohne DNSSEC-Validierung.

Konfiguration Schritt für Schritt

Der Umstieg läuft über DNS und Exchange Online PowerShell. Microsofts offizielle Schrittfolge im Überblick: [2]

TTL des bestehenden MX-Records reduzieren. Beim DNS-Hoster die Time-to-Live des existierenden MX-Records auf mindestens 30 Sekunden senken und dann so lange warten, bis die vorherige TTL abgelaufen ist. Wer das überspringt, riskiert spürbare Downtime beim Umschwenken auf den neuen Endpunkt.
Neuen MX-Record anlegen und testen. Beim DNS-Hoster einen zusätzlichen MX-Record mit Priorität 20, dem eben erzeugten Zielwert als Hostname und einer TTL von mindestens 30 Sekunden eintragen. Danach über den Inbound SMTP Email-Test im Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) prüfen, ob Mails am neuen Endpunkt ankommen. Je nach DNS-Caching kann der Test einen zweiten Versuch brauchen.
Prioritäten umstellen. Sobald der Test erfolgreich ist: den neuen IRR-Record auf Priorität 0 (höchste Priorität) setzen und den bestehenden MX-Record auf Priorität 30 absenken.
Legacy-MX-Records entfernen. Alte Zielwerte wie mail.protection.outlook.com., mail.eo.outlook.com. oder mail.protection.outlook.de. löschen.
TTL finalisieren. Die TTL des IRR-Records auf 3600 Sekunden erhöhen.

Domain mit Region verknüpfen. Pro Domain:

Set-AcceptedDomain -Identity contoso.com -MailFlowRegion GBR

Der letzte Parameter ist der dreistellige PDL-Code aus der Multi-Geo-Region-Liste (etwa GBR für Großbritannien, DEU für Deutschland, EUR für den EU-Cluster, NAM für Nordamerika). Nach der Aktivierung weitere 30 Minuten warten, damit gecachte DNS-Datensätze ablaufen und Routing-Informationen propagieren. [2]

Tenant-Schalter setzen. In Exchange Online PowerShell:

Set-OrganizationConfig -InRegionRoutingEnabled $true

Microsoft empfiehlt, anschließend eine Stunde zu warten, bevor es weitergeht.

DNSSEC-MX-Wert erzeugen. In Exchange Online PowerShell:

Enable-DnssecForVerifiedDomain -DomainName <Domain>

Exchange Online liefert dann den neuen MX-Zielwert im Format <domain-als-label>.o-v1.mx.microsoft. Jeder Punkt der Domain wird dabei durch einen Bindestrich ersetzt: contoso.com wird zu contoso-com.o-v1.mx.microsoft, foo.example.com entsprechend zu foo-example-com.o-v1.mx.microsoft.

Unterstützte Regionen

Die Microsoft-Dokumentation zu Multi-Geo-Verfügbarkeit listet aktuell 30 Geografien. Die passenden PreferredDataLocation- und MailFlowRegion-Codes sind: APC (Südkorea, Japan, Singapur, Malaysia, Hongkong SAR), AUS (Australien), AUT (Österreich), BRA (Brasilien), CAN (Kanada), CHL (Chile), DEU (Deutschland), DNK (Dänemark), ESP (Spanien), EUR (EU-Cluster mit Frankreich, Niederlanden, Irland, Norwegen, Schweiz, Österreich, Finnland, Schweden, Deutschland), FRA (Frankreich), GBR (Vereinigtes Königreich), IND (Indien), IDN (Indonesien), ISR (Israel), ITA (Italien), JPN (Japan), KOR (Korea), MYS (Malaysia), MEX (Mexiko), NAM (Nordamerika/USA), NOR (Norwegen), NZL (Neuseeland), POL (Polen), QAT (Katar), SWE (Schweden), CHE (Schweiz), TWN (Taiwan), ARE (Vereinigte Arabische Emirate), ZAF (Südafrika). [3]

Mögliche Fehlerbilder im Betrieb

Bei falscher Routing-Konfiguration tauchen bei IRR-aktivierten Tenants einige spezifische SMTP-Fehler auf: [2]

451 4.4.62 ATTR35 | Mail wurde an den falschen Microsoft-365-Endpunkt zugestellt. In korrekt konfigurierten Multi-Geo-Tenants sollte der Fehler nicht mehr auftreten.
550 5.7.64 TenantAttribution; Relay Access Denied | Versuch, über Microsoft 365 zu einer nicht gehosteten Domain zu relayen.
550 4.4.4 ATTR5 | Nachricht kam unauthentifiziert an einer Empfänger-Domain an, die in einem Tenant ohne gültige Mail-Subscription konfiguriert ist.
451 4.3.2 ATTR55 oder 451 4.4.3 ATTR55.1 | Temporäre Systemfehler; sendende MTAs sollten den Retry übernehmen.

Allgemeine Einordnung der Funktionalität

IRR ist als Feature im Multi-Geo-Add-on enthalten und ohne Aufpreis nutzbar. Es ist standardmäßig deaktiviert; wer die Funktion nicht braucht, muss nichts tun. Wer IRR aktiviert, gewinnt drei Dinge: Reduzierter Cross-Region-Verkehr (und damit messbar niedrigere Latenz bei globalen Mailflows), klarere Compliance-Story für regionale Datenresidenz-Vorgaben (etwa EU-Data-Boundary oder nationale Anforderungen) sowie die Möglichkeit, den SMTP-Einstiegspunkt sauber auf eine bestimmte Geografie festzulegen. [1]

Kritisch ist das saubere Ausrichten von Domain, PreferredDataLocation und MailFlowRegion. Läuft eine Domain nach GBR, der Nutzer sitzt aber in EUR, greift IRR nicht und die Mail landet weiter im bisherigen Flow. In komplexen Tenants mit mehreren Domains und mehreren Regionen ist es deshalb ratsam, den Ausrollplan pro Domain zu machen, zunächst auf Domain-Ebene zu testen und erst danach tenant-weit zu aktivieren. [2]