MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Exchange Online SMTP Sharing

Diese Seite beschreibt die verschiedenen Optionen, um die gleiche SMTP-Domain mit Exchange Online und mehreren Tenants zu nutzen. Dieser Anforderung kommt sehr schnell, wenn eine Firma ein andere Firma aufkauft und nach außen als "eine Firma" auftreten soll. Es geht als um das Senden und Empfangen mit einer Domain, die nicht zum eigenen Tenant gehört.

Hinweis:
Diese Seite beschränkt sich auf zwei Exchange Online Tenants ohne Rücksicht auf einen Hybrid Mode, Multi Tenant Umgebungen mit Cross-Tenant Sync und Cross Tenant Migration.

Beachten Sie dazu auch die Seite Tenant Domain Sharing mit weiteren Varianten des SMTP-Sharing und Rewrite

Grundlagen

Auf der Seite Tenant Domain Sharing habe ich schon allgemein über die Optionen geschrieben, wie eine UPN-Domain und mehrere Tenants genutzt oder eben auch nicht genutzt werden können. Im Grund kann immer nur genau ein Tenant eine DNS-Domain besitzen. Im Jahr 2022 hat Microsoft eine Preview gestartet., mit der ein Tenant einem anderen Tenant die Nutzung einer SMTP-Domain für Exchange Online gestatteten konnte. Diese Funktion, welche es sogar in die Roadmap geschafft hatte aber später wieder verschwunden ist und es auch im Mai 2025 noch keine Neuigkeiten gab, außer dass es bislang nicht gelöste Probleme gibt.

Wer sich mit dem Thema schon länger beschäftigt und auch einige Meetings mit Kunden dazu durchgeführt hat, weiß um die Komplexität. Ganz einfach müssten sie ja nur zwei Dinge erreichen:

  • Eingehende Mails werden an das richtige Ziel verteilt
    Dazu könnten wir einfach die Mail an die Domains weiter über einen MX-Record an den primären Tenant routen lassen und dort gibt es dann MailUser, die Mails an Empfänger im anderen Tenant weiterleiten.
  • Ausgehende Mails
    Mails von Absendern aus Tenant2 können nicht mit einer Domain aus Tenant1 versendet werden. Dies unterbindet Exchange Online aktuell. Also müssten wir diese Mails an ein vorgelagertes System senden, welches die Adressen "umschreibt" und dann versendet:

Wenn ich das als Bild skizziere, dann sieht es auch schön einfach aus:

Das Bild zeigt keine Überraschungen und sollte leicht zu verstehen sein. Der Rewrite-Service ist natürlich eine neue Komponente und das hat nicht mit EXO SRS - Sender Rewriting Scheme (SRS) zu tun.

Es ist komplizierter

Klingt zu einfach, um kompliziert zu sein? Das kann ich doch einfach mit einem Exchange Edge Server oder Postfix in der Cloud mal eben umsetzen. Dann denken Sie aber mal an all die folgenden Fragestellungen:

  • Rewrite Service
    Zuerst müssen Sie so einen Rewrite-Service aufbauen und betreiben. Exchange Online enthält diese Funktion nicht und einen SMTP-Dienst in Azure als VM zu betreiben ist nur mit Einschränkungen möglich. Sie müssen daher entweder einen Exchange Edge Server oder anderen SMTP-Dienst irgendwo betreiben und konfigurieren oder die Dienstleistung einkaufen.
  • Erreichbarkeit Rewriting Service
    Wenn Sie den Dienst selbst betreiben, dann müssen sie eine "sichere Konfiguration" wählen. Der Service darf z.B. nicht aus Internet erreichbar sein aber auch eine Beschränkung auf die Exchange Online Adressen ist nicht ausreichend, denn alle Tenants nutzen die gleiche Range und das gleiche Zertifikat. Eine weitere Filterung über Transport Regeln ist z.B. eine Möglichkeit.
  • DKIM ausgehend
    Wenn Sie ausgehende Mails von Exchange Online aber per Rewrite verändern, dann bricht die eine von ihrem Tenant aufgebrachte DKIM-Signatur. Sie müssten die Mail nach dem Rewrite selbst noch einmal per DKIM signieren. Der Exchange Edge Server kann dies aber nicht von Hause aus. Hier brauchen Sie Zusatzprodukte oder Dienste.
  • SPF ausgehend und IP-Adresse
    Auch der Versand erfolgt im Beispiel über ihren eigenen Server, den Sie natürlich im SPF-Eintrag addieren müssen. Auch die von ihrem Dienst genutzte IP-Adresse muss einen gewissen Vertrauenslevel haben, damit sie ihre Mails auch weiterhin zustellen können.
  • Weiterleitung aus Tenant1
    Der MX-Record für die gemeinsame Domain geht zum Tenant1 und hier müssen alle Empfänger aus Tenant2 mit einer Weiterleitung konfiguriert sein. Der ausgehende Rewrite von Tenant2 ersetzt meist stumpf die Domain in allen Mailadressen aber prüft nicht, ob das Ergebnis damit auch gültig ist.
  • Interne Mails aus Tenant2 an die shared Domain
    Der Rewrite betrifft nur Mails von Tenant2 an externe Empfänger. Die Exchange Nutzer im Tenant2 haben aber nie die "Shared Domain" sondern ihre eigene Domain, die sie intern nutzen. Das kann verwirrend für Anwender sein und einem Ineffizienten Routing führen.
  • Doppeltes Routing, Weiterleitung und SPF/DKIM/DMARC
    Stellen Sie sich vor, dass ein Anwender aus Tenant1 eine Mail an zwei Empfänger in Tenant 2 sendet. Er adressiert natürlich die "Shared Domain" und die Mails wird über die Kontakte im Tenant1 umgeschrieben und an Tenant2 gesendet. Wenn hier nun ein Nutzer eine "Reply All"-Aktion startet, dann sendet die Mailbox im Tenant2 die Mails immer erst an den Tenant1, der dann die Mail an Benutzer2 im Tenant2 wieder zurück sendet. So gibt es noch weitere Fälle und in allen Szenarien muss das Routing über Connectoren u.a. greifen. Denken Sie dabei nicht nur an SPF/DKIM sondern auch an weitere Schutzfunktionen wie MTA-TLS.
  • Verteiler
    Wenn Sie zwei Tenants "wie einen Tenant" aussehen lassen wollen, dann können Sie die Benutzer z.B.: mit Cross-Tenant Sync abgleichen. Dabei werden aber keine Verteiler synchronisiert. Ein Verteiler ist zwar in der Regel kein Absender und damit für ausgehendes Rewriting nicht relevant, aber eingehend wird ein Verteiler im Tenant1 aufgelöst. Allerdings müssen Sie auch eine Lösung für die Anwender im Tenant2 bereitstellen, damit diese den Verteiler im Adressbuch finden. Das könnte einfach ein MailContact sein, der Mails an Tenant1 sendet oder sie bauen einen Dirsync für Verteiler irgendwie auf.

Ich bin sicher, dass ich nicht mal alle Szenarien hiermit beschrieben habe.

Rewriting mit Exchange Edge

Ein Exchange Edge Server wurde von Microsoft ursprünglich als das optimale Relay für Exchange vermarktet, welchen Sie in eine DMZ stellen und Mails zwischen dem Internet und dem intern stehenden Exchange Server vermittelt. Ein Edge Server wird dazu klassisch mit einem Edge Connector an den internen Exchange Server angekoppelt, der von dort z.B. die Connectoren als auch die Liste der gültigen Mailadressen bekommt. Leider sind die "AntiSpam"-Funktionen des Edge Server auf dem Stand von 2007 stehen geblieben. Es gibt kein SPF, kein DKIM und auch sonst merkt man, dass Microsoft seinen Kunden lieber Exchange Online Protection als Spamfilter in der Cloud verkaufen will. Der Edge-Server wird heute überwiegend als Relay bei einer Hybrid-Bereitstellung mit Exchange OnPremises und Exchange Online genutzt, wenn eine Firma wirklich ein Relay zwischen den beiden Plattformen aufsetzen muss oder will.

Interessant ist der Exchange Edge Server aber dennoch, denn er kann auch komplett ohne ein lokale AD und lokales Exchange eingesetzt werden. Da es aber kein Verwaltungs-GUI gibt, müssen Sie alle Connectoren als auch die Rewrite-Regeln von Hand per lokaler Exchange PowerShell anlegen.

Die Connectoren 3,5 und 6 sind "build in" und müssen im Edge-Server nicht manuell konfiguriert werden. Aber die Connectoren 1,2 und 4 müssen Sie auf dem Edge Server und in ihrem Tenant anlegen:

Nr  Name Beschreibung

1 

Tenant zu Rewrite 

Vom Tenant2 müssen sich sicherstellen, dass alle Mails nicht direkt per MX-Auflösung oder andere Connectoren am Rewrite-Service vorbei gehen, sondern alle Mails durch den Rewrite-Service gehen.

2 

Eingehend Edge

Der Edge Server seht systembedingt im Internet und sollte nur Mails von ihrem Exchange Online Tenant annehmen. Denken Sie daran, dass es auch andere Tenants gibt, die vielleicht etwas an ihre System senden könnten. Die Source-IP oder das Zertifikate von Exchange Online sind kein Unterscheidungskriterium.

3

Edge zu Internet 

Dieser Connector dienst dazu dem Edge Server optional den Weg ins Internet zu weisen. Er ist nicht erforderlich, wenn die Mails sowieso über den MX-Record ins Internet versendet werden und sie keine weiteren Einstellung pro Domain hinsichtlich TLS vornehmen wollen.

4

Internet zu Edge 

Auch dieser Connector muss eigentlich nicht angelegt, werden, da ein Edge erst einmal generell Mails annimmt. Wenn der Edge aber nur als Rewrite-Instanz zwischen Tenants genutzt wird, sollten Sie den Empfang aus dem Internet z.B.: über Firewall-Regeln und Anpassung der Receive Connectoren beschränken. gering erscheint.

5

Edge zu Tenat2 

Der Edge-Server muss natürlich wissen, wie er den Tenant2 mi seinen Domains erreicht. Wenn die MX-Records für diese Domain eh zu Exchange Online verweisen, dann könnten Sie auf eine explizite Einrichtung verzichten. Ich würde es dennoch tun, um z.B. TLS vorzuschreiben und insbesondere das Client-Zertifikat anzugeben, mit dem sich der Edge-Server bei Exchange Online ausweist.

6

Inbound Tenant 2 

 Dieser Connector ist nun wichtig, denn Exchange Online würde die Mail anhand der Empfängerdomain schon dem richtigen Tenant zuweisen aber der Absender ist entweder aus ihrem primären Tenant oder häufiger noch eine externe Domain. Der Rewrite macht eine DKIM-Signatur ungültig und ihr eigener Rewrite-Service ist sicher nicht im SPF-Eintrag aller Absenderdomains enthalten. Hier müssen Sie nachsteuern, damit externe Mails nicht als Spam abgewiesen oder in der EOP Quarantäne landen, z.B.: mit EXO Enhanced Filtering oder ARC mit Exchange Online

Das Rewriteing ist von Microsoft recht gut dokumentiert. Wenn ich alle Absender einer Domain ausgehend umschreiben will, dann reichen folgende Einstellungen:

# Rewrite Agenten aktivieren. Ich beschränke mich beim obigen Beispile auf ausgehend.
Enable-TransportAgent "Address Rewriting Outbound Agent"  
# Enable-TransportAgent "Address Rewriting Inbound Agent"

# Komplette Domain umschreiben
New-AddressRewriteEntry `
   -Name "SenderDomainRewrite2sharedDomain" `
   -InternalAddress "uclabor.de" `
   -ExternalAddress "msxfaq.de" `
   -OutboundOnly $true

Damit werden alle Mails durch den Edge Server Richtung Internet umgeschrieben. Sie können Sie natürlich auch mehrere Einträge für weitere Domains anlegen.

Der Edge Server prüft nicht, ob die Ergebnisadresse im anderen Tenant auch definiert und mit einer Weiterleitung versehen ist.

Transportregeln

Da selbst bei perfekter Konfiguration immer noch jeder Exchange Online Tenant ihren Rewrite-Service erreichen kann, sollten sie z.B. Felder wie X-OriginatorOrg in einer Transport-Regel nutzen, z.B.:

# Schutz gegen Missbrauch durch andere Tenants 
WENN Absender <> Tenant2-Domain
DANN Drop Message

Im obigen Beispiel sollten ja nur Mail des eigenen Tenants den Rewrite-Service nutzen. Sonst hat in diesem Beispiel niemand den Edge-Server zu nutzen.

Aber auch eingehend in den Tenant2 können Sie z.B. mit Transportregeln arbeiten. Sie kennen zwar nicht den Absender aber vielleicht könnte der Administrator von Tenant1 einen "geheimen Header" addieren, den sie im Tenant2 dann auswerten kann, z.B.

# Regeln im Tenant1
WENN Empfängerdomain = "uclabor.mail.onmicrosoft.com"
DANN Addiere Header: X-SMTPSHARING= "tenant1"

Im Tenant2 könnte Sie dann addieren:

# Regeln im Tenant1
WENN Header: X-SMTPSHARING= "tenant1"
DANN Setze SCL = -1

Leider gibt es in den Transportregeln keine Möglichkeit z.B. den Namen des Inbound Connectors oder das ARC-Ergebnis auszuwerten um z. B. sicherzustellen, dass die Mail wirklich von Exchange Online gekommen ist. Ehe sie daher das Feld X-OriginatorOrg auswerten, müssen sie irgendwie sicher sein, dass die Mail durch ihren primären Tenant geroutet wurde.

Rewriting mit Postfix, EXIM, SendMail etc.

Sie müssen natürlich nicht zwingend einen Exchange Edge Server nutzen. Wenn Sie den Service als VM irgendwo hosten wollen, kosten Windows VMs oft mehr als Linux-VMs und auch der Exchange Edge Server ist ja zusätzlich zu lizenzieren. "Rewrite"-Aktionen bieten z.B. auch Postfix, Exim, SendMail und andere Mailserver. Die Herausforderung ist dabei aber identisch zum Exchange Edge Server:

  • Stellen sie irgendwie sicher, dass der RewriteService ausgehend nur von ihrem Tenant erreicht werden kann
    Nicht dass andere Tenants irgendwie mal ihren Relay-Service per Smarthost "finden" oder er gar ein offenes Relay für das Internet ist
  • Machen Sie in "richtiges Rewrite"
    Es reicht nicht den Absender in der "from"-Zeile zu ändern. Denken Sie auch an weitere Empfänger, die den internen Namen von Tenant2 nutzen aber nach extern anders aussehen sollen. Vielleicht wollen Sie sogar im Mail-Body zitierte Inhalte von früher umschreiben.

Nur weil sie z.B. eine Open Source Mailserver als Relay auf einer Open Source Plattform einsetzen, sind Lizenzkosten natürlich ein eher kleiner Teil der Betriebskosten

Exchange Edge und EXO als Relay

Bisher habe ich immer die Konfiguration beschrieben, dass der Rewrite-Service die ausgehenden Mails direkt per MX-Record in die Welt sendet. Wenn Firmen bislang nativ auf Exchange Online und Exchange Online Protection gesetzt haben, dann gibt es erst einmal keinen anderen Server, den man als Relay nutzen könnte. Nur Firmen, die einen 3rd Party, z.B. NoSpamProxy als Spamfilter oder S/MIME-Gateway davor nutzen, könnte ausgehende Mails an diese System senden, die sich dann auch um DKIM kümmern könnten oder sogar die Rewrite-Funktion selbst übernehmen.

Wäre es aber nicht auch möglich, die von Tenant2 versendeten Mails nach dem Rewrite einfach über Tenant1 zu routen? Dann könnte Tenant1 die Mails auch DKIM-signieren und die Mails wären auch im Messagetracking sichtbar. Das Bild würde dann wie folgt aussehen

 

 

Der Exchange Online Tenant1 wäre dann ein "Outbound Relay". Damit dies funktioniert, muss Exchange Online Tenant1 die an ihn gesendeten Mails des Rewrite-Service als "intern" erkennen. Dazu müssen Sie im Tenant1 einen "Inbound Organization Connector" anlegen. Damit dieser Connector auch genutzt wird, müssen Sie eine von zwei Bedingungen erfüllen.

  • Rewrite-Service kommt mit einem Client TLS Zertifikat mit einer Domain von Tenant1
    Das funktioniert sehr zuverlässig, auch unabhängig von IP-Adressen und wird vom Exchange Edge Server auch unterstützt.
  • Der Connector triggert auf eine Source-IP und die Domain des Absenders gehört zu Tenant1
    Achtung: Diese Konfiguration ist möglich, aber funktioniert nicht ohne Mithilfe des Microsoft Support. Wenn Sie so einen Connector einrichten oder aktivieren wollen, dann könnten Sie folgende Fehlermeldung sehen:

    Auch einen bestehenden inaktiven Connector können Sie nicht aktivieren, wenn sie eine "Source-IP-Adresse" als Kriterium verwenden.

Insofern ist ein OnPremises-Connector basierend auf der Source-IP keine einfache Möglichkeit mehr diese Mails anzunehmen, sondern Sie müssen schon eine SMTP-Verbindung mit einem Client-Zertifikat aus ihrer Domain aufbauen, wenn Sie Exchange Online als Relay verwenden wollen. Microsoft hat die Regeln diesbezüglich verschärft.


Quelle: Inbound connectors from on-premises organizations FAQ
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/inbound-connector-faq

Und selbst dann ist es natürlich weiterhin erforderlich, dass die Absender in Exchange Online auch "bekannt" sind. Ansonsten werden Sie weiterhin als "Extern" angesehen. Sie müssen in unserem Beispiel die Absender aus Tenant2 als Objekte in der GAL angelegt haben.

Bedenken Sie dabei aber auch die Exchange Online Limits hinsichtlich der Anzahl an externen Mails. Wenn viele Anwender in Tenant2 sind aber alle über die Domain von Tenant1 senden während in Tenant1 noch keine Lizenzen für diese Benutzer gekauft wurden, dann könnten Sie an die TERRL - Tenant External Recipient Rate Limit stoßen.

Wenn Sie weitere Details zu dieser Konfiguration benötigen, finden Sie diese auf den folgenden Seiten:

Rewrite und Routing ohne Exchange Online

Nur zur Vollständigkeit möchte ich noch die Konfiguration skizzieren, die einen zentralen Routingservice vor beide Tenants schaltet. Damit können Sie z.B. sehr flexibel die Mails aus dem Internet zu dem ein oder anderen Tenant routen und benötigen auch keine Kontakte im jeweils anderen Tenant. Sogar die "Shared Domain" muss nicht mal in einem der Tenants registriert sein, was insbesondere bei Firmen mit weiteren fremden Mailsystemen ein Grund sein kann.

 

Aber der Weg ist auch nicht gerade einfach, denn zum einen können Sie weder DKIM noch den Spamschutz von Exchange Online nutzen, sondern müssen diese Funktion alle auf dem vorgelagerten System bereitstellen. Zudem brauchen Sie irgendwie einen Verzeichnisabgleich, damit alle gültigen Empfänger aus den verschiedenen Tenants auf dem vorgelagerten System sowohl mit der "Shared-Domain" als auch ihren realen Adressen bekannt sind.

Sie können Sie auch ohne Kontakte in den jeweiligen Tenants auskommen. Das ist unschön für die Anwender, die natürlich dann die anderen Empfänger nicht in der GAL sehen und nicht in Verteilern aufgenommen werden können. Aber auch Administratoren müssen die "Shared Domain" dann vom Status "Authoritative" auf "Internal Relay" umstellen, damit Mails an Benutzer im anderen Tenant geroutet werden können.

Um einen korrekten Verzeichnisabgleich, z.B. mit Cross-Tenant Sync o.ä,kommen sie nicht wirklich herum.

Keine Checkliste/How to

Auf vielen Seiten des MSXFAQ beschreibe ich eine Beispielkonfiguration, teilweile in Form einer Checkliste mit den entsprechenden PowerShell-Befehlen und Erläuterungen zu deren Funktionsweise und Auswirkungen. Beim SMTP-Domainsharing zwischen zwei oder vielleicht sogar mehr Tenants habe ich mir das verkniffen, denn es gibt keine einfache für alle passende Konfiguration.

Alle Vorab-Meetings mit Kunden haben durchweg mehr als vier Stunden gedauert, weil wir immer erst die aktuelle Situation und Konfiguration erfassen und verstehen, die Wünsche und Ziele festlegen und dann die Varianten mit ihren individuellen Vorteilen und Nachteilen vorstellen und bewerten mussten. Es geht auch nicht nur im eine Koexistenz sondern meist ist dies nur die Vorarbeit zu einer späteren Migration. Das hat direkte Auswirklungen auf die Platzhalter der anderen Domains, ob diese als "MailUser", "MailGuestuser", MailContact" oder sogar gar nicht angelegt werden.

Wenn Sie als Firma vor so einer Aufgabenstellung stehen, dann könnte eine Zusammenarbeit mit Net at Work interessant sein. Ich freue mich auf ihren Anruf.

Weitere Links