Exchange Hybrid: 554 5.4.108 SMTPSEND.DNS.MxLoopback

Beim E-Mail-Routing im Exchange Hybrid Modus kann es zwischen Exchange on-Prem und Microsoft 365 Postfächern zu dem folgenden Fehler kommen, wenn Mails von einer lokalen Mailbox (oder eines externen Absenders) zu einer M365 Mailbox gesendet werden:

Remote Server returned ‚554 5.4.108 SMTPSEND.DNS.MxLoopback; DNS records for the next hop domain are configured in a loop -> DnsDomainIsInvalid: InfoMxLoopback‘

Exchange Hybrid: 554 5.4.108 SMTPSEND.DNS.MxLoopback

Dieser Fehler kann bei Postfächern auftreten bei denen die Einstellung „E-Mail-Adressen basierend auf der E-Mail-Adressrichtlinie für diesen Empfänger automatisch aktualisieren“ deaktiviert wurde. Hier mal ein Beispiel:

Adressrichtlinie deaktiviert

Bei Postfächern bei denen die Adressrichtlinie nicht angewendet wird, kann die erforderliche Remoteroutingadresse nicht konfiguriert werden. Statt der korrekten Remoteroutingadresse kann es vorkommen, dass die Standard-E-Mail Adresse des Postfachs als Remoteroutingadresse konfiguriert wird. Hier mal ein Beispiel für so einen Fall:

falsche Remoteroutingadresse

In diesem Fall funktioniert die Umleitung der Mails an die Microsoft 365 Mailbox nicht und es kommt zu den oben angegebenen Fehler. Hier mal eine grafische Darstellung wie das E-Mail Routing zwischen Exchange on-Prem und Microsoft 365 funktioniert:

Exchange Hybrid Transport Routing
Quelle: https://docs.microsoft.com/de-de/exchange/transport-routing

Zu Erklärung: Der Schritt 5 (Umleitung der Mail anhand der Remoteroutingadresse) kann nicht durchgeführt werden, da hier die Standardemailadresse eingetragen war. daher kommt es zum Mail Loop. Das Problem konnte behoben werden indem die korrekte Remoteroutingadresse „alias@tenant.mail.onmicrosoft.com“ für das betreffende Postfach konfiguriert wurde:

richtige Remoteroutingadresse

Das geschilderte Problem ist kürzlich bei einer Exchange Migration zu Microsoft 365 aufgetreten, leider konnte ich nicht genau nachstellen, wie es zu diesem Fehler gekommen ist. Wie in dem oberen Screenshot zu sehen ist, fehlt in diesem Fall die Remoteroutingadresse in den konfigurierten E-Mail Adressen, da die Adressrichtlinie nicht angewendet wurde. Normalerweise lässt sich die Mailbox dann aber auch nicht in die Cloud verschieben und der Migration Batch schlägt mit dem Fehler „Proxy Address not found“ fehl. Ich vermute daher mal, dass beim Erstellen des Migration Batch die falsche „Target Delivery Domain“ angebenden wurde (also nicht tenant.mail.onmicrosoft.com):

Migration Batch mit falscherTarget Delivery Domain

Hier hätte eigentlich die Domain „tenant.mail.onmicrosoft.com“ als Target Delivery Domain ausgewählt werden müssen:

Migration Batch mit richtiger Target Delivery Domain

Wahrscheinlicher ist daher, dass aufgrund der fehlenden Aktualisierung der Adressrichtlinie erst gar keine Remoterouting Adresse konfiguriert wird und der Migration Batch erst gar nicht die Mailbox zu M365 verschiebt (allerdings konnte ich dies nicht in meiner Umgebung nachstellen).

Mit dem folgenden Befehl lassen sich RemoteMailboxen prüfen, bei denen die Aktualisierung via Adressrichtlinie abgeschaltet wurde:

Get-RemoteMailbox | where {$_.EmailAddressPolicyEnabled -eq $False} | select name,RemoteRoutingAddress,WindowsEmailAddress

Lokale Postfächer lassen sich mit dem folgenden Befehl prüfen:

get-mailbox | where {$_.EmailAddressPolicyEnabled -eq $False} | select name,EmailAddresses

Schreibe einen Kommentar