Hybrid-Mailfluss: Routing zwischen Exchange Online und On-Premises

Hybrid-Mailfluss ist der SMTP-Weg zwischen einer lokalen Exchange-Organisation und Exchange Online. Er sorgt dafür, dass Postfächer auf beiden Seiten dieselbe SMTP-Domain verwenden können und Nachrichten trotzdem am richtigen Ort ankommen. Der Hybrid Configuration Wizard richtet dafür Connectoren und TLS-Parameter ein (Transport routing in Exchange hybrid deployments, Hybrid Configuration Wizard).

Der Mailfluss ist nur ein Teil von Exchange Hybrid. Verzeichnissynchronisation, Frei/Gebucht, OAuth und Mailboxverschiebungen verwenden andere Wege. Dieser Artikel bleibt deshalb bewusst bei einer einzigen Frage: Welche SMTP-Hops durchläuft eine konkrete Nachricht, und welche Entscheidung fällt an jedem Hop?

Der Protokollstack ist dabei überschaubar: DNS benennt die öffentlich erreichbaren Ziele, SMTP über TCP 25 transportiert die Nachricht, TLS schützt und identifiziert die Verbindung, und Exchange-Connectoren legen fest, welche Gegenstelle für welche Domain verwendet wird. Empfängerobjekte liefern die Routingadresse; Message Trace und lokale Trackinglogs zeigen anschliessend, was jede Organisation mit der Nachricht getan hat (Transport routing in Exchange hybrid deployments, Hybrid deployment prerequisites).

Das Grundmodell: zwei Exchange-Organisationen, ein Adressraum

Eine Hybridumgebung besitzt mindestens zwei Transportorganisationen. Die lokale Exchange-Organisation kennt lokale Postfächer und Remote-Mailboxobjekte. Exchange Online kennt Cloudpostfächer und synchronisierte Repräsentationen lokaler Empfänger. Beide Seiten können dieselbe primäre Domain wie example.com verwenden (Exchange hybrid deployments).

Damit eine Nachricht nicht am falschen Ort endet, braucht jede Seite einen Hinweis auf den tatsächlichen Empfängerstandort. Für ein Cloudpostfach enthält das lokale Remote-Mailboxobjekt eine Remote-Routingadresse in der Koexistenzdomain, typischerweise tenant.mail.onmicrosoft.com. Umgekehrt kennt Exchange Online synchronisierte lokale Empfänger als mailfähige Objekte (Enable-RemoteMailbox).

Der normale Ablauf ist damit einfach:

1. Die erste Exchange-Organisation nimmt die Nachricht an.
2. Sie löst den Empfänger in ihrem Verzeichnis auf.
3. Das Empfängerobjekt zeigt, ob das Postfach lokal oder auf der anderen Seite liegt.
4. Der passende Hybridconnector sendet per SMTP/TLS an die andere Organisation.
5. Dort wird der Empfänger erneut aufgelöst und die Nachricht zugestellt.

Experten prüfen zusätzlich, ob Transportregeln die Route verändern, ob ein Gateway eingeschoben ist und welche Domain- oder Connectorpriorität den gewählten Next Hop erklärt.

Die Standardroute ohne zentralen Internettransport

Im üblichen dezentralen Modell sendet jede Seite ihre Internetmail selbst. Ein lokales Postfach verwendet die lokale Exchange-Transportorganisation für ausgehende Internetmail. Ein Cloudpostfach sendet über Exchange Online Protection. Nur Nachrichten zwischen lokalen und Cloudpostfächern durchlaufen die Hybridconnectoren (Transport routing in Exchange hybrid deployments).

Eingehende Internetmail folgt dem veröffentlichten MX. Zeigt der MX auf Exchange Online, nimmt EOP die Nachricht zuerst an. Für ein Cloudpostfach stellt Exchange Online lokal zu; für einen synchronisierten lokalen Empfänger verwendet es den Hybrid-Outbound-Connector. Zeigt der MX dagegen auf die lokale Umgebung oder ein vorgeschaltetes Gateway, findet die erste Empfängerentscheidung dort statt.

Dieses Modell hält Internetpfade kurz, führt aber zu mehreren möglichen Egress-IPs und Filterorten. SPF, DKIM, DMARC, Allowlisting und Partnerregeln müssen beide Ausgangswege berücksichtigen. Das ist kein Fehler des Hybridmodells, sondern eine Folge verteilter Zustellung.

Centralized Mail Transport bewusst einordnen

Centralized Mail Transport, CMT, ändert genau diesen ausgehenden Weg. Nachrichten aus Exchange-Online-Postfächern an das Internet werden zuerst zur lokalen Exchange-Organisation gesendet. Erst dort verlassen sie die Organisation. Die lokale Seite kann dadurch zentrale Transportregeln, Appliances oder feste Egress-IPs weiterverwenden (Transport routing in Exchange hybrid deployments).

Der Vorteil ist eine gemeinsame Ausgangskontrolle. Der Preis sind zusätzliche Hops und Abhängigkeiten. Fällt der lokale Transport oder seine Internetanbindung aus, betrifft das nun auch ausgehende Cloudmail. Latenz, Queueort, Egress-IP und der Ort der letzten Filterung ändern sich.

Für fortgeschrittene Admins lautet die Entscheidung daher nicht «CMT an oder aus», sondern: Welche konkrete Richtlinie verlangt den lokalen Hop, welche Kapazität muss er tragen und wie wird bei einem Ausfall geroutet? Experten dokumentieren zusätzlich Schleifenschutz, TLS-Anforderungen, Connectorpriorität und den Nachweis, dass wirklich jede beabsichtigte Nachricht den zentralen Weg nimmt.

Damit ist das Thema CMT abgeschlossen. Authentisierung von Outlook-Clients oder Hybrid Modern Authentication gehört nicht hierher, weil sie keinen SMTP-Hop auswählt.

Wie Connectoren die Gegenstelle erkennen

Nachdem die Route gewählt ist, muss jede Seite der Gegenstelle vertrauen können. Der Hybrid Configuration Wizard erstellt lokale Send-/Receive-Connectoren und passende Inbound-/Outbound-Connectoren in Exchange Online. Der Transport läuft über SMTP auf TCP 25 und verwendet TLS (Hybrid deployment prerequisites, Hybrid mail flow).

Der lokale Send Connector bestimmt Ziel und TLS-Anforderungen für die Koexistenzdomain. Der Cloud-Outbound-Connector beschreibt die lokale Organisation als Ziel. In Gegenrichtung akzeptieren Receive beziehungsweise Inbound Connector den Verkehr anhand dokumentierter Bedingungen, darunter Zertifikatsidentität und Herkunft.

Das Zertifikat erfüllt dabei eine konkrete Aufgabe: Es weist den SMTP-Endpunkt im TLS-Handshake aus. Subject beziehungsweise Subject Alternative Name, Connectorparameter, präsentierte Zertifikatskette und tatsächlicher Hostname müssen zusammenpassen. Ein im Zertifikatsspeicher vorhandenes gültiges Zertifikat reicht nicht, wenn der Transportdienst ein anderes präsentiert.

Experten prüfen deshalb beide Richtungen getrennt. Richtung A kann funktionieren, während Richtung B wegen eines anderen Connectors, DNS-Ziels oder Zertifikatsnamens scheitert.

Empfängerrouting und geteilte Domains

Ein funktionierender Connector sagt noch nicht, welche Nachrichten ihn verwenden. Diese Entscheidung beginnt beim Empfängerobjekt. Eine lokale Remote Mailbox verweist zur Cloud. Ein synchronisiertes lokales Postfachobjekt in Exchange Online verweist zurück zur lokalen Organisation.

Accepted Domains bestimmen zusätzlich, ob eine Organisation für alle Empfänger einer Domain zuständig ist oder unbekannte Empfänger weiterleiten darf. In geteilten Domains ist eine Internal-Relay-Konfiguration nur dann sicher, wenn der nächste Hop unbekannte Empfänger korrekt kennt oder ablehnt (Accepted domains in Exchange Online, Accepted domains in Exchange Server).

Ein veraltetes Remote-Mailboxobjekt kann deshalb trotz gesundem TLS zu Fehlrouting führen. Umgekehrt hilft eine korrekte Target Address nicht, wenn der Cloudconnector deaktiviert ist. Die Diagnose verbindet Objekt und Transport, statt nur eine Seite zu betrachten.

Für Experten werden Weiterleitungen, Mailkontakte, Verteilerexpansion und Transportregeln wichtig. Sie können die ursprüngliche Empfängeradresse ändern oder zusätzliche Empfänger erzeugen. Jede resultierende Nachricht erhält ihren eigenen Routingentscheid.

Mail-Gateways vor oder hinter Exchange Online

Viele Organisationen ergänzen Hybrid um ein Secure Email Gateway oder eine Cloudfilterplattform. Dadurch kommt mindestens ein weiterer SMTP-Hop hinzu. Der Pfad muss für eingehende und ausgehende Nachrichten separat gezeichnet werden (Manage mail flow using a third-party cloud service).

Steht das Gateway vor Exchange Online, zeigt der MX zum Gateway. EOP sieht dann zunächst dessen Quell-IP. Enhanced Filtering for Connectors kann die ursprüngliche Absenderinformation in die Microsoft-Filterbewertung einbeziehen, wenn Connector und übersprungene IPs korrekt konfiguriert sind (Enhanced Filtering for Connectors).

Ausgehend muss feststehen, ob Exchange Online direkt, über das Gateway oder bei CMT zuerst lokal und danach über das Gateway sendet. Mehrere erlaubte Wege können Richtlinien umgehen und erzeugen unterschiedliche DKIM-Signaturen, Egress-IPs und Protokolle.

Die Expertenkontrolle ist ein erlaubter Pfadgraph: Jeder Pfeil nennt Initiator, Ziel, Port, TLS-Prüfung, zulässige Domains, Filteraufgabe, Queuebesitzer und Protokollquelle. Ein Gatewayname ohne diese Angaben ist noch keine Architektur.

Eine Nachricht Ende zu Ende verfolgen

Die Fehlersuche beginnt mit einer Testnachricht, deren Absender, Empfänger und Zeitpunkt bekannt sind. Zuerst wird der öffentliche Weg geprüft, dann die Ereignisse jeder beteiligten Exchange-Seite.

Resolve-DnsName -Type MX example.com
Test-NetConnection mail.example.com -Port 25

dig MX example.com
nc -vz mail.example.com 25

Resolve-DnsName und dig zeigen das veröffentlichte MX-Ziel. Test-NetConnection und nc prüfen, ob TCP 25 vom Messpunkt erreichbar ist. Das beweist noch keine erfolgreiche TLS- oder Connectorprüfung.

Danach folgt der SMTP-Handshake. Auf beiden Adminplattformen kann OpenSSL verwendet werden.

openssl s_client -starttls smtp -connect mail.example.com:25 `
  -servername mail.example.com -showcerts

openssl s_client -starttls smtp -connect mail.example.com:25 \
  -servername mail.example.com -showcerts

openssl s_client zeigt Zertifikatskette, Namen und TLS-Aushandlung. Für einen vollständigen autorisierten Testdialog eignet sich swaks. Produktionsnachrichten werden nicht mit frei erfundenen Absendern getestet; Testidentität und erwartete Route werden vorab festgelegt.

In Exchange Online liefert Get-MessageTraceV2 die Cloudereignisse. Lokal zeigt Get-MessageTrackingLog die Verarbeitung auf Exchange-Servern, und Get-Queue zeigt wartende Next Hops. Zeitstempel werden in eine gemeinsame Zeitzone gebracht; Internet Message ID und Network Message ID helfen, die Abschnitte zu verbinden (Message Trace FAQ, Message tracking).

Typische Fehlerbilder ohne Themensprünge

Ein TLS-Fehler wird zuerst als Transportproblem behandelt: Welcher Host wurde verbunden, welches Zertifikat präsentierte er und welche Connectorbedingung erwartete die Gegenseite? Empfängersynchronisation ist erst relevant, wenn die Nachricht nach erfolgreicher Annahme falsch geroutet wird.

Ein NDR für unbekannten Empfänger führt dagegen zuerst zum Empfängerobjekt und zum Accepted-Domain-Typ. Erst wenn das Objekt korrekt ist, wird geprüft, ob die gewählte Route es auf die richtige Seite transportiert.

Eine wartende Queue verlangt Next Hop, Retryzeit und LastError. Der offene Port des Zielhosts hilft nur als nächster Test. Ein Loop zeigt sich in wiederholten Received-Headern, Hops oder Trackingereignissen und entsteht meist, wenn beide Seiten unbekannte Empfänger aneinander weiterreichen (RFC 5321: Trace information and loop detection).

Eine nur in eine Richtung funktionierende Verbindung ist kein Widerspruch. Die Gegenrichtungen verwenden unterschiedliche Sender, Connectoren und Zertifikatsprüfungen. Sie werden getrennt aufgenommen und getestet.

Sicherheit, Betrieb und Änderungen

Hybrid-SMTP öffnet einen bewusst erlaubten Transportweg. Dieser Weg sollte auf dokumentierte Quell- und Zielsysteme, Zertifikate und Domains begrenzt sein. Offene Relays, zu breite IP-Bereiche oder Connectoren, die jede Nachricht als vertrauenswürdig einstufen, widersprechen diesem Modell.

Zertifikatswechsel werden wie Routingänderungen geplant. Vor Ablauf werden neues Zertifikat, Dienstzuweisung, präsentierte Kette und Connectorerwartung auf beiden Seiten geprüft. Danach folgen Testnachrichten in beide Richtungen und ein kontrollierter Rollbackplan.

Für den laufenden Betrieb werden mindestens Hybridconnectoren, Zertifikatsablauf, Queuewachstum, Message-Trace-Fehler, DNS-Ziele und Gatewaygesundheit überwacht. Bei Centralized Mail Transport kommt die Kapazität des lokalen Ausgangspfads hinzu.

Backup und Wiederaufbau des Mailwegs

SMTP-Nachrichten liegen während einer Störung in Queues der jeweils verantwortlichen Systeme. Ein Konfigurationsbackup stellt diese wartenden Nachrichten nicht wieder her. Deshalb werden Konfiguration und Transportzustand getrennt betrachtet.

Zum Wiederaufbau gehören Connectorparameter beider Seiten, Accepted und Remote Domains, Transportregeln, öffentliche DNS-Einträge, Zertifikate mit privaten Schlüsseln, Gatewaykonfiguration und die HCW-Auswahl. Secrets werden geschützt gespeichert; lesbare Exporte dokumentieren Struktur und Abhängigkeiten.

Nach einem Wiederaufbau wird nicht nur ein Port getestet. Eine markierte Nachricht läuft in jeder Richtung durch den erwarteten Pfad. Message Trace, lokale Trackinglogs, Gatewayprotokolle und Zielpostfach bestätigen jeden Hop. Erst diese Ende-zu-Ende-Abnahme zeigt, dass Routing und Filterung wieder stimmen.

Technische Entwicklung und Trade-offs

Der Hybrid Configuration Wizard automatisierte über mehrere Exchange-Generationen die Verbindung zu Exchange Online. Transport blieb dabei SMTP/TLS, während Cloudconnectoren, unterstützte Zertifikate und Routingoptionen weiterentwickelt wurden (Hybrid Configuration Wizard).

Direkter Internettransport hält Wege kurz und nutzt die jeweilige Plattform dort, wo das Postfach liegt. Centralized Mail Transport bündelt Kontrolle, macht Cloudmail aber vom lokalen Ausgang abhängig. Ein Drittgateway ergänzt spezialisierte Filterung oder Verschlüsselung, erhöht jedoch die Zahl der Hops und Protokollquellen. Die richtige Wahl folgt aus einer nachweisbaren Anforderung, nicht aus dem Wunsch, dass im Diagramm alles durch denselben Kasten läuft.