MOERA - Microsoft Online Email Routing Address

Diese Seite beschreibt die Zusammenhänge dieser besonderen SMTP-Adresse mit Exchange Online.

.onmicrosoft.com

Kaum richtigen Sie einen Office 365/Microsoft 365 Tenant neu ein, haben Sie auch schon einen Administrator mit einem Anmeldenamen. Da es in der Cloud keine NT4-Domain gibt und der Anmeldename weltweit eindeutig sein muss, sieht er aus wie eine Mailadresse., d.h. hat einen frei definierbaren "Userpart" und einen "Domainname" hinter dem @-Zeichen. Als Domainnamen kommen dabei nur DNS-Domänen im Internet zum Einsatz, welche Sie im Tenant addiert und ihren Besitz über einen z.B. DNS-Eintrag nachgewiesen haben. Solange Sie aber noch keine eigene Domain definiert haben, stellt ihnen Microsoft eine eindeutige Domain im Format <tenantname>.onmicrosoft.com bereit. Dieser UPN ist damit nicht nur in ihrem Tenant sondern über alle Microsoft 365 Tenants hinweg eindeutig. Sie können den UPN natürlich jederzeit selbst ändern oder mit ADSync aus dem lokalen AD verwalten lassen.

Wobei dies eine der wenigen, wenn nicht sogar die einzige schriftliche Fundstelle für den Begriff "MOERA" ist.

Mailrouting

Der Begriff MOERA hat aber nichts mit der Anmeldung zu tun, sondern mit dem Mailrouting. Für den Anwender ist eigentlich nur die primäre Mailadresse wichtig, unter der er nicht nur erreichbar sein will, sondern mit der auch all seine ausgehenden Mails versendet werden. Hier sollten Sie nie die "<tenant>.onmicrosoft.com"-Adresse verwenden, sondern immer ihre eigene Domain. Wenn Sie noch keine eigene Domain haben, dann kaufen Sie sich besser sofort eine um flexibel zu sein.

Ich finde es immer traurig, wenn auf einem Handwerkerbulli eine www.<handwerkername>.de-Adresse und darunter dann eine t-online-Mailadresse geschrieben wird. Mailadressen einer Domain, die an einen Provider gebunden sind, können nie umgezogen werden.

Dennoch hat die besondere Mailadresse eine Funktion. Sie ist als zusätzliche Mailadresse am Postfach für eine eindeutige Zustellung erforderlich. Der MX-Record für diese Domain geht immer zu Microsoft 365 und egal wo sie in der Welt sind, können Sie eine Mail an diese "geheime" Adresse umleiten lassen und sie kommt immer im Exchange Online Postfach.

Sie ist damit essentiell, wenn sich mehrere Mailadressen die gleiche SMTP-Domain teilen, wie dies bei Exchange Online - Hybrid der Fall ist. Bei der Einrichtung des Exchange Hybrid Mode werden in ihrem lokalen Exchange Server folgende Einstellungen durch den HCW - Hybrid Configuration Wizard addiert.

  • Remote-Domain mit -TargetDeliveryDomain:$True
    Damit lernt Exchange, dass er z.B. OOF-Meldungen und Weiterleitungen an diese Domain erlaubt und nach einer Postfachmigration diese Domain als Zieladresse für den lokalen "RemoteMailbox"-Eintrag verwenden darf
  • Accepted Domain (autoritativ)
    Erst dann nimmt Exchange auch Mails an, die an diese Domain gehen und nutzt die RemoteMailbox-Objekte als Allow-Eintrag zur Weiterleitung. Sie muss dazu nicht als "Internal Relay" konfiguriert sein.
  • Empfängerrichtlinie
    Da Objekte in Exchange Online durch ADSync verwaltet werden, muss die MEORA-Adresse in die ProxyAddresses im lokalen AD. Exchange Online stellt aber auch bei einem Fehler selbst in der Cloud sicher, dass die Adresse passt.
  • Send-Connector
    Zuletzt konfiguriert der HCW einen Send-Connector von InPremises zu ihrem Tenant für die Domain "<tenant>.mail.onmicrosoft.com" und nutzt dazu normalerweise den MX-Record.

In die Gegenrichtung kommt die Adresse übrigens nicht zum Tragen. Da kommt ihre normale SMTP-Domain als Adresse zum Einsatz. Der HCW legt dazu im Tenant dann einen Outbound-Connector für alle "Accepted Domain" im Tenant an, um diese Mails zum lokalen Mailsystem zu routen.

Das Prinzip solcher Routingdomänen ist immer dann wichtig, wenn zwei oder noch mehr Mailsysteme sich einen gemeinsamen SMTP-Adressraum teilen, damit jedes Mailsystem über einen Adressbuchabgleich nicht nur alle Empfänger und Mailadressen kennt, sondern auch direkt an das finale Zielsystem routen kann. Der oft gerne gewählte Ansatz die Systeme zu verketten führt ansonsten schnell zu schleifen.

Autodiscover

Es gibt aber noch eine weitere Funktion dieser Adresse. Im Hybrid Mode verweist der "autodiscover.<maildomain>"-Eintrag immer auf die OnPremises-Umgebung. Wenn nun ein Postfach schon mittels Report-MoveRequest zu ExchangeOnine verschoben wurde, dann konvertiert der MRSProxy am Ende die lokale Mailbox zu einer "RemoteMailbox" und setzt in das Feld "TargetAddress" eine SMTP-Adresse, die jede Mail an das Postfach in der Cloud weiter leitet. Genau dafür wird auch die MEORA-Adresse genutzt.

Wobei hier dann noch ein "MAIL" dazwischen dazu kommt.

<userpart>@<tenantname>.mail.onmicrosoft.com

Bildungsregel

Damit stellt sich natürlich die Frage, wie diese Adresse generiert wird, denn Sie muss eindeutig sein aber vor allem solle sie nie wieder von einem Benutzer entfernt werden. Sie wissen ja schließlich nicht, in welchen anderen Systemen die MEORA-Adresse genutzt wird. Bei Microsoft gibt es mehrere Quellen:

Microsoft Online Email Routing Address (MOERA): The address constructed from the user's userPrincipalName prefix, plus the initial domain suffix, which is automatically added to the proxyAddresses in Microsoft Entra ID
https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/proxyaddresses-attribute-populate

Because the Microsoft Entra UserPrincipalName attribute value could be set to MOERA, it is important to understand how the Microsoft Entra MailNickName attribute value, which is the MOERA prefix, is calculated.
When a user object is synchronized to a Microsoft Entra tenant for the first time, Microsoft Entra ID checks the following items in the given order and sets the MailNickName attribute value to the first existing one:

On-premises mailNickName attribute
Prefix of primary SMTP address
Prefix of on-premises mail attribute
Prefix of on-premises userPrincipalName attribute/Alternate login ID
Prefix of secondary smtp address
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-userprincipalname#microsoft-entra-mailnickname-attribute-value-calculation 

Sobald ADSync im Spiel ist, ist der OnPremises MailNickName für die Bildung der MEORA-Adresse maßgeblich und dieses Feld wird wohl auch bei einer Änderung im lokalen AD durch ADSync wieder in die Cloud übertragen und dann dort auch aktualisiert. Die MEORA-Adresse wird aber auch neu ermittelt, wenn sich der UPN des Anwenders ändert, weil dieser z.B. OnPremises geändert und durch ADSync repliziert wurde oder Sie haben nachträglich die Custom Domain im Tenant registriert, so dass nun der richtige lokale UPN auch in der Cloud anstelle des <tenant>.onmicrosoft.com-Platzhalters verwendet werden kann.

Microsoft hat die verschiedenen Fälle, insbesondere wenn vom lokalen AD das Feld ProxyAddresses gefüllt aber Mailnickname leer ist, auf folgender Seite beschrieben:

Microsoft Entra UserPrincipalName population
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-userprincipalname#microsoft-entra-mailnickname-attribute-value-calculation

Wobei mir nicht wirklich ein Szenario einfällt, dass ein lokaler Benutzer eine ProxyAddresse aber keine Mailnickname hat. Ohne MailNickname ist das Objekt für Exchange unsichtbar und hat dann in der Regel auch keine ProxyAddresses. Es sei denn sie verwenden das Feld für eigene Zwecke oder pflegen es ohne einen lokalen Exchange Server.

Weitere Links