Exchange Hybrid Mailflow – wenn Mails nach der Migration nicht mehr ankommen

Die letzten Postfächer sind nach Microsoft 365 migriert – und dann kommen Mails nicht mehr an. Mal nur von extern, mal nur zwischen Cloud und lokalem Exchange, mal sporadisch. In den meisten Fällen liegt die Ursache nicht in Exchange Online selbst, sondern in der Verbindung zwischen den beiden Welten: Connectors, Zertifikate, Accepted Domains und Empfängerobjekte. Dieser Artikel zeigt, wo Sie suchen und wie Sie die typischen Fälle beheben.

Wie Mailflow im Hybrid-Setup funktioniert

In einer Exchange-Hybrid-Umgebung existieren lokale Postfächer und Exchange-Online-Postfächer parallel unter derselben Domain. Der Hybrid Configuration Wizard (HCW) richtet dafür vier Bausteine ein:

• Inbound Connector in Exchange Online (Typ OnPremises): nimmt Mails vom lokalen Exchange entgegen und erkennt sie – meist anhand des Zertifikats – als organisationsintern.
• Outbound Connector in Exchange Online: stellt Mails an lokale Empfänger per TLS an Ihre lokalen Server (SmartHosts) zu.
• Send Connector lokal («Outbound to Office 365»): sendet Mails an die Routing-Domain tenant.mail.onmicrosoft.com nach Exchange Online.
• Receive Connector lokal (in der Regel «Default Frontend»): nimmt Mails aus Exchange Online per TLS entgegen.

Dazu kommen die Empfängerobjekte: Ein in die Cloud migriertes Postfach ist lokal eine Remote Mailbox mit einer RemoteRoutingAddress auf @tenant.mail.onmicrosoft.com. Ein lokales Postfach erscheint in Exchange Online als Mail User. Stimmt einer dieser Bausteine nicht, landet die Mail im falschen System – oder nirgends.

Die häufigsten Ursachen

1. Zertifikat erneuert, Connectors nicht nachgezogen

Der HCW bindet die Connectors an ein Zertifikat. Wird es erneuert – mit neuem Aussteller oder anderem Subject –, passt der TlsSenderCertificateName im Inbound Connector oder der TlsCertificateName am lokalen Send Connector nicht mehr. Exchange Online erkennt die Mails dann nicht mehr als intern oder die TLS-Verbindung scheitert. Das ist einer der häufigsten Gründe, warum ein lange stabiles Setup plötzlich bricht.

2. Zu viele oder verbastelte Connectors

Nach einigen Versuchen existieren oft mehrere Connectors. Bei Outbound Connectors entscheidet keine Priorität, sondern der Geltungsbereich: RecipientDomains, IsTransportRuleScoped (nur über eine Transportregel aktiv) und RouteAllMessagesViaOnPremises (zentraler Mailtransport). Ein zweiter Connector mit überlappendem Scope oder ein vergessener, transportregelgebundener Connector führt zu falschem Routing.

3. Accepted Domains inkonsistent

Die gemeinsame Domain ist in Exchange Online und lokal üblicherweise Authoritative. Internal Relay brauchen Sie nur, wenn es Empfänger gibt, die nicht synchronisiert sind, etwa Postfächer auf einem Drittsystem. Existiert ein Empfänger in Exchange Online nicht als Objekt und die Domain ist dort Authoritative, gibt es eine Unzustellbarkeitsmeldung mit 550 5.1.10.

4. Empfängerobjekte fehlen oder zeigen falsch

Typisch sind migrierte Benutzer ohne Remote-Mailbox-Objekt, eine falsche RemoteRoutingAddress, eine fehlende Proxyadresse auf @tenant.mail.onmicrosoft.com oder Postfächer, die lokal neu angelegt statt per Enable-RemoteMailbox erstellt wurden. Ebenfalls klassisch: Ein Benutzer hat in beiden Systemen ein Postfach, weil die Lizenz vor der Migration zugewiesen wurde.

5. Firewall, Gateway oder Ports

Port 25 eingehend ist oft nur für bestimmte IP-Bereiche offen. Diese Bereiche ändern sich, und eine veraltete Firewall-Liste blockiert Exchange Online selektiv. Ein Mail-Gateway, das TLS terminiert, zerstört zudem die zertifikatsbasierte Erkennung der Connectors.

6. Vergessene Transportregeln

Lokale Transportregeln aus der Migrationszeit – Umleitungen, Moderation, Disclaimer – oder eine Regel in Exchange Online, die auf einen bestimmten Connector routet, werden gerne übersehen.

Diagnose: systematisch statt nach Gefühl

Schritt 1: Message Trace in Exchange Online

Im Exchange Admin Center unter Mailfluss → Nachrichtenablaufverfolgung sehen Sie, ob eine Mail zugestellt, abgelehnt oder zurückgehalten wurde und über welchen Connector sie lief. Per PowerShell geht es schneller:

Get-MessageTraceV2 -SenderAddress "test@example.ch" -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date) |
  Select-Object Received, SenderAddress, RecipientAddress, Status

In älteren Versionen des Exchange-Online-Moduls heisst das Cmdlet Get-MessageTrace.

Schritt 2: Message Tracking und Queues lokal

In der Exchange Management Shell sehen Sie, was der lokale Server mit der Mail gemacht hat:

Get-MessageTrackingLog -Sender "test@example.ch" -Start (Get-Date).AddHours(-2) -ResultSize Unlimited |
  Select-Object Timestamp, EventId, Source, ConnectorId, Recipients, RecipientStatus
Get-Queue | Where-Object { $_.MessageCount -gt 0 } |
  Select-Object Identity, DeliveryType, Status, MessageCount, NextHopDomain, LastError

Kommt die Mail lokal nie an, liegt das Problem davor. Wird sie empfangen, aber nicht weitergesendet, ist es ein Routing- oder Connector-Problem. Eine gefüllte Queue Richtung tenant.mail.onmicrosoft.com mit einem LastError zu TLS oder Verbindung zeigt direkt auf Send Connector, Zertifikat oder Firewall.

Schritt 3: Connectors und Zertifikate prüfen

In Exchange Online:

Get-InboundConnector | Format-List Name, Enabled, ConnectorType, SenderIPAddresses, TlsSenderCertificateName, RequireTls
Get-OutboundConnector | Format-List Name, Enabled, ConnectorType, SmartHosts, RecipientDomains, TlsSettings, TlsDomain, IsTransportRuleScoped, RouteAllMessagesViaOnPremises

Auf dem lokalen Exchange:

Get-SendConnector | Format-List Name, Enabled, AddressSpaces, TlsCertificateName, TlsDomain, RequireTLS
Get-ReceiveConnector | Where-Object { $_.Name -like "Default Frontend*" } |
  Format-List Identity, TlsCertificateName, TlsDomainCapabilities, AuthMechanism
Get-ExchangeCertificate | Format-List Thumbprint, Subject, Issuer, NotAfter, Services

Vergleichen Sie Subject und Aussteller des aktuell gültigen Zertifikats mit den Werten in den Connectors. Abweichungen sind ein starker Hinweis.

Schritt 4: Header und Fehlercodes auswerten

Exportieren Sie den vollständigen Header einer betroffenen Mail und analysieren Sie ihn mit dem Message Header Analyzer im Microsoft Remote Connectivity Analyzer. Er zeigt, welche Server die Mail angefasst haben und wo sie abgewiesen wurde. Bei intern zugestellten Mails verrät X-MS-Exchange-Organization-AuthAs, ob Exchange Online die Mail als intern (Internal) oder als anonym eingestuft hat – Letzteres deutet auf ein Zertifikats- oder Connector-Problem.

Lösungen für die typischen Fälle

Fall 1: Mails vom lokalen Exchange kommen in Exchange Online nicht oder als «extern» an

Ursache: Der Inbound Connector erkennt den lokalen Server nicht mehr, meist nach einem Zertifikatswechsel.

1. Prüfen Sie, ob TlsSenderCertificateName im Inbound Connector zum Subject oder SAN des aktuellen Zertifikats passt.
2. Prüfen Sie lokal, ob der Send Connector das aktuelle Zertifikat verwendet, und korrigieren Sie es bei Bedarf:

   $cert = Get-ExchangeCertificate -Thumbprint "<THUMBPRINT>"
   $tlsName = "<I>$($cert.Issuer)<S>$($cert.Subject)"
   Set-SendConnector -Identity "Outbound to Office 365 - <GUID>" -TlsCertificateName $tlsName

3. Senden Sie eine Testmail und verfolgen Sie sie in beiden Systemen.

Fall 2: Mails aus Exchange Online an lokale Empfänger kommen nicht an

Ursache: Der Outbound Connector erreicht die lokalen Server nicht, die TLS-Prüfung scheitert oder der Empfänger existiert in Exchange Online nicht als Mail User.

1. Prüfen Sie SmartHosts, TlsSettings und TlsDomain des Outbound Connectors. Der Name in TlsDomain muss im Zertifikat des lokalen Servers stehen.
2. Testen Sie den Connector direkt aus Exchange Online:

   Validate-OutboundConnector -Identity "Outbound to <GUID>" -Recipients "user@example.ch"

3. Stellen Sie sicher, dass die Firewall Port 25 aus den aktuellen Exchange-Online-IP-Bereichen zulässt. Get-HybridMailflowDatacenterIPs in Exchange Online listet die für Hybrid-Mailflow genutzten Adressen.
4. Prüfen Sie, ob der Empfänger in Exchange Online als Mail User synchronisiert ist.

Fall 3: Mails an migrierte Benutzer bleiben lokal hängen oder bouncen

Ursache: Das Remote-Mailbox-Objekt fehlt oder zeigt auf die falsche Adresse.

Get-RemoteMailbox -Identity "user@example.ch" | Format-List RemoteRoutingAddress, EmailAddresses
Set-RemoteMailbox -Identity "user@example.ch" -RemoteRoutingAddress "user@tenant.mail.onmicrosoft.com"

Existiert lokal statt einer Remote Mailbox noch ein echtes Postfach, stellt der lokale Exchange die Mail dort zu – der Benutzer sieht sie in der Cloud nie.

Fall 4: Lokaler Exchange lehnt Mails aus Exchange Online ab

Ursache: Der Receive Connector akzeptiert Exchange Online nicht als vertrauenswürdige Quelle, typischerweise mit 5.7.1 oder TLS-Fehlern im Message Trace.

Der vom HCW konfigurierte Receive Connector braucht ein gültiges TlsCertificateName und in TlsDomainCapabilities den Eintrag mail.protection.outlook.com:AcceptCloudServicesMail:

Set-ReceiveConnector -Identity "EX01\Default Frontend EX01" -TlsDomainCapabilities "mail.protection.outlook.com:AcceptCloudServicesMail"

Wann es kompliziert wird

Gateways im Mailflow

Sitzt ein Mail-Gateway oder eine Verschlüsselungslösung zwischen lokalem Exchange und Exchange Online, muss es die Verbindung unverändert durchreichen. Terminiert das Gateway TLS mit eigenem Zertifikat oder schreibt es Header um, funktioniert die zertifikatsbasierte Erkennung nicht mehr, und DKIM-Signaturen können brechen. In solchen Setups muss der Pfad jeder Mailrichtung dokumentiert und einzeln getestet werden.

Mehrere Domains und zentraler Mailtransport

Mit mehreren Domains, unterschiedlichem Routing pro Domain oder aktivem zentralem Mailtransport (RouteAllMessagesViaOnPremises) steigt die Zahl der möglichen Wege. Konflikte zwischen Transportregeln und Connector-Scopes sind dann schwer zu sehen. Hier hilft eine einfache Tabelle: Absender, Empfänger, erwarteter Weg, tatsächlicher Weg laut Trace.

Autodiscover

Autodiscover beeinflusst den Mailflow nicht, wird aber oft gleichzeitig zum Thema. Solange lokale Exchange-Server in Betrieb sind, zeigt Autodiscover in der Regel auf diese; sie leiten Clients für Cloud-Postfächer weiter. Wer Autodiscover während der Mailflow-Fehlersuche umstellt, schafft sich ein zweites Problem.

Fazit: Die Reihenfolge macht den Unterschied

Hybrid-Mailflow-Probleme wirken chaotisch, folgen aber fast immer denselben Mustern. Wer in einer festen Reihenfolge prüft, findet die Ursache meist schnell – und vermeidet, durch hektisches Umkonfigurieren neue Fehler einzubauen.

Nils Lappenbusch

Founder & Technology Architect, Lappenbusch

Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.

Kontakt aufnehmen