Mailfluss zwischen Microsoft 365 und On-Prem: MX, Konnektoren und die Rolle der Firewall

Der Mailfluss im Exchange Hybrid ist ein Staffellauf: Internet, Exchange Online, Konnektoren, On-Prem-Server — und mittendrin steht die Firewall und entscheidet mit, ob der Stab ankommt. Die Kurzantwort für Eilige: Der MX zeigt im Standard-Setup auf Exchange Online, die Cloud filtert und reicht per Konnektor an On-Prem weiter; die XGS braucht dafür genau zwei SMTP-Regeln — eine DNAT auf Port 25, beschränkt auf Microsofts Quellnetze, und eine ausgehende 25er-Freigabe exklusiv für den Exchange-Server. Dazu kommt die Disziplin, in diesem Pfad nichts kaputtzuoptimieren: keine doppelte SMTP-Filterung, kein Antasten von STARTTLS. Und weil der Mailfluss heute untrennbar an der Absender-Reputation hängt, gehören SPF, DKIM und DMARC ins selbe Bild — im Hybrid mit ein paar Fallen, die Mails im Spam-Ordner enden lassen. Dieser Artikel liefert das Gesamtbild: Szenarien, Firewall-Anforderungen samt Portmatrix, die DNS-Einträge, die Diagnose-Systematik und die Härtung, mit der nur noch Exchange Online einliefern darf.

Mailfluss-Szenarien im Hybrid: zentral vs. dezentral

Bevor Regeln entstehen, gehört die Architekturfrage geklärt: Wo laufen die Mails lang? Der Standard und die Empfehlung für die große Mehrheit: Der MX-Eintrag zeigt auf Exchange Online. Eingehend nimmt damit Exchange Online Protection jede Mail zuerst entgegen — Spam-, Malware- und Phishing-Filterung passieren in der Cloud, und nur bereits gefilterte Post wandert über den Hybrid-Konnektor zu den On-Prem-Postfächern. Ausgehend gilt spiegelbildlich: Der On-Prem-Server versendet über Exchange Online als Smarthost in die Welt. Die Vorteile liegen auf der Hand: eine einzige Absender-Reputation (die von Microsoft gepflegte), DKIM-Signatur auf allem, was das Haus verlässt, ein schlanker SPF-Eintrag — und die Migration wird einfacher, weil sich am Mailfluss nichts mehr ändert, wenn Postfächer in die Cloud wandern.

Daneben existieren zwei begründungspflichtige Abweichungen. Abweichung eins: der dezentrale Direktversand, bei dem On-Prem selbst in die Welt sendet — der Preis sind eine eigene IP-Reputation, die gepflegt werden will, ein um die eigene IP erweiterter SPF-Eintrag und der Verzicht auf DKIM für diese Mails, denn der On-Prem-Exchange signiert von Haus aus nicht. Abweichung zwei: der zentrale Mailfluss (Centralized Mail Transport), bei dem umgekehrt sogar die Cloud-Postfächer über On-Prem versenden — sinnvoll ausschließlich dann, wenn ein lokales Gateway zwingend in den Pfad muss, etwa eine Signatur-Appliance, ein Verschlüsselungs-Gateway oder eine Archivierungspflicht am eigenen Ausgang. Die Skizze stellt die drei Wege nebeneinander; der Merksatz darunter gilt für den ganzen Artikel: Der Standard heißt »raus über die Cloud«, und die beiden anderen Wege brauchen einen Grund, den man aufschreiben kann.

Skizze 1: Der Standard (alles über EXO), der Sonderweg (Direktversand mit Reputations-Preis) und der Compliance-Fall (zentraler Mailfluss) — nur einer davon ist begründungsfrei.

Firewall-Anforderungen im Hybrid-Mailfluss: Ports, Quell-IPs, TLS

Die Aufgabenliste der XGS ist erfreulich kurz — die Kunst liegt in der Präzision. Eingehend braucht es eine DNAT-Regel: Port 25 von außen auf den Exchange-Server, mit der entscheidenden Einschränkung der Quelle auf Microsofts dokumentierte Exchange-Online-Netze (dazu gleich mehr im Härtungskapitel). Ausgehend braucht der Exchange-Server Port 25 zum EXO-Smarthost — und zwar exklusiv er: Kein anderer Host im Netz hat auf Port 25 nach draußen etwas verloren, denn genau über diesen Weg verschickt jeder infizierte Client sein Botnet-Spam-Kontingent. Dazu kommt Port 443 ausgehend für OAuth und die Hybrid-Dienste — die 443-Gegenrichtung, also EWS-Publishing samt Zertifikatskette, ist Terrain des Publishing-Artikels [LINK: B4] und wird hier nicht wiederholt. Bleibt der wichtigste Punkt auf der Liste, und der ist ein Unterlassungsgebot: Der Konnektor-Pfad verträgt keine Zwischenstation, die am SMTP-Dialog herumbastelt.

Warum das Unterlassungsgebot so wichtig ist: Exchange Online erzwingt auf dem Konnektor TLS und identifiziert deinen On-Prem-Server über den Namen im TLS-Zertifikat — der Hybrid-Assistent hinterlegt genau diesen Namen im Konnektor. Alles, was den TLS-Aufbau stört, bricht deshalb den Mailfluss: eine SMTP-Inhaltsprüfung, die sich in den Dialog einklinkt, ein Scanner, der das STARTTLS-Kommando herausfiltert, oder schlicht ein Zertifikatstausch, nach dem der Name nicht mehr zum Konnektor passt. Die XGS-Rolle in diesem Pfad ist die des disziplinierten Türstehers: Quelle prüfen, durchreichen, protokollieren — nicht mitreden. Die Portmatrix fasst alle Flüsse zusammen, das Staffellauf-Diagramm zeigt sie im Zusammenhang.

Skizze 2: Der Staffellauf in beide Richtungen — die XGS als Türsteher eingehend (nur EXO-Quellen) und Ausgangskontrolle ausgehend (nur der Exchange).

SPF, DKIM, DMARC im Hybrid-Kontext

Ohne saubere Absender-Authentifizierung ist der schönste Mailfluss nichts wert — die Empfängerseite sortiert dann munter in den Spam-Ordner. Die drei Mechanismen kurz einsortiert: SPF deklariert per DNS, welche Server für deine Domain senden dürfen; DKIM signiert ausgehende Mails kryptographisch, sodass der Empfänger Absender und Unversehrtheit prüfen kann; und DMARC legt fest, was mit Mails passieren soll, die beide Prüfungen reißen — und liefert per Report-Adresse die Rückmeldung, wer da draußen alles in deinem Namen sendet. Im Hybrid mit Standard-Mailfluss ist die Konfiguration angenehm schlank, weil alles Ausgehende über Exchange Online läuft: Der SPF-Eintrag braucht nur Microsofts Include, DKIM wird im Microsoft-365-Portal aktiviert und per zwei CNAME-Einträgen delegiert, und DMARC startet im Beobachtungsmodus, bevor die Zügel angezogen werden.

Die Hybrid-Fallen lauern bei den Abweichungen: Wer On-Prem direkt versenden lässt, muss die eigene IP in den SPF-Eintrag aufnehmen — sonst scheitert die Prüfung, und die Mails landen im Spam; und selbst mit korrektem SPF fehlt diesen Mails die DKIM-Signatur, was bei strenger werdenden Empfängern (Stichwort Anforderungen der großen Freemail-Anbieter) zunehmend Punkte kostet. Der zweite Klassiker sind die vergessenen Nebenversender: der Kopierer, der Scans direkt per SMTP verschickt, das ERP mit eigenem Mailversand, der Newsletter-Dienstleister — jeder davon braucht seinen Platz im SPF-Gefüge oder besser einen Weg über einen authentifizierten Relay-Punkt. Genau solche Schattenversender fördert übrigens der DMARC-Report zutage, weshalb der Beobachtungsmodus kein Durchgangsstadium zum Abhaken ist, sondern ein Erkenntniswerkzeug. Die Tabelle liefert die konkreten Einträge.

Typische Fehlerbilder und ihre Diagnose

Wenn Hybrid-Mails ausbleiben, entscheidet die Systematik über Minuten oder Stunden — und die Systematik beginnt mit der goldenen Regel: immer am wartenden Ende ansetzen, denn die Queue des Absenders protokolliert präzise, woran die Übergabe scheitert, während man am Empfänger nur raten kann. Richtung eins, Cloud zu On-Prem: Der Message Trace im Exchange-Online-Admin-Center zeigt jeden Zustellversuch samt Fehlercode. Ein Timeout heißt: Port 25 kommt nicht an — DNAT-Regel prüfen, Quell-IP-Gruppe aktuell?, blockt der Provider? Ein TLS-Fehler in der 4xx-Klasse heißt: Zertifikatsproblem — abgelaufen, Name passt nicht mehr zum Konnektor (der Klassiker nach dem Zertifikatstausch, siehe Praxis-Kasten), Kette unvollständig, oder eine Zwischenstation zerlegt STARTTLS. Und eine 5xx-Ablehnung heißt: Die Verbindung steht, aber der Exchange selbst lehnt ab — Receive Connector, erlaubte Netze, Empfängerprüfung.

Richtung zwei, On-Prem zu Cloud: Auf dem Exchange verrät Get-Queue samt LastError, woran der Send Connector scheitert — die drei Klassiker sind die DNS-Auflösung des EXO-Smarthosts (in Umgebungen mit getrennter interner und externer Namensauflösung ein Dauerkandidat, die Feinheiten dazu stehen im Split-DNS-Artikel [LINK: B10]), die blockierte ausgehende 25er-Verbindung (darf wirklich der Exchange raus — und ist es auch der Exchange, der es versucht?) und der scheiternde TLS-Handshake. Der Entscheidungsbaum fasst beide Richtungen zusammen. Und für die Fälle jenseits des Totalausfalls — Mails kommen an, aber verspätet oder im Spam — führt der Weg über den Message Trace (wo lag die Wartezeit?) beziehungsweise die Kopfzeilen der Mail, in denen SPF-, DKIM- und DMARC-Ergebnis schwarz auf weiß stehen. Wer diese Prüfpfade einmal verinnerlicht hat, diagnostiziert die allermeisten Mailfluss-Störungen ohne einen einzigen Support-Anruf.

Skizze 3: Zwei Richtungen, zwei Werkzeuge — Message Trace für Cloud→On-Prem, Get-Queue für die Gegenrichtung. Der Fehlercode zeigt fast immer direkt auf die Ursache.

Härtung: nur EXO darf einliefern

Zum Abschluss die Härtung, die aus dem Standard-Setup ein sauberes macht — in drei Schichten. Schicht eins ist die Firewall: Die eingehende DNAT-Regel für Port 25 bekommt als Quelle eine IP-Hostgruppe mit Microsofts dokumentierten Exchange-Online-Netzen; alles andere auf Port 25 wird verworfen und protokolliert. Damit existiert für das Internet schlicht kein direkter Weg mehr zu deinem Mailserver — jeder Zusteller muss durch die Cloud-Filterung, und die alte Spammer-Abkürzung am Türsteher vorbei ist zu. Schicht zwei ist der Exchange selbst: Der Receive Connector für den Hybrid-Verkehr wird über seine erlaubten Remote-IP-Bereiche ebenfalls auf die EXO-Netze eingegrenzt — Verteidigung in der Tiefe, falls an der Firewall je eine Regel verrutscht. Schicht drei ist die Ausgangsseite: Port 25 nach draußen exklusiv für den Exchange-Server, alle übrigen Quellen verwerfen und loggen — die unspektakulärste Anti-Botnet-Maßnahme der Welt, und eine der wirksamsten für die eigene IP-Reputation.

Bleibt die Pflegefrage, denn die Härtung ist nur so gut wie ihre IP-Liste: Microsofts Netzbereiche ändern sich — selten, aber sie tun es. Die Quelle der Wahrheit ist der offizielle Endpunkt-Webservice, dessen Versionsstand sich automatisiert überwachen lässt; der Faktenkasten fasst die Betriebsroutine zusammen. Und wer die geloggten Treffer der Verwerfen-Regeln nicht nur sammeln, sondern auswerten will — etwa den plötzlich Port-25-plappernden Buchhaltungs-PC als Frühwarnung ernst nehmen —, findet die Anbindung der XGS-Logs an ein SIEM im Sentinel-Artikel [LINK: B8].

FAQ — häufige Fragen zum Hybrid-Mailfluss durch die Firewall

Welche Ports braucht Exchange Hybrid durch die Firewall?

Die Kernliste ist kurz: eingehend Port 25 (SMTP) per DNAT auf den Exchange-Server für den Konnektor-Mailfluss — quellbeschränkt auf Microsofts Exchange-Online-Netze — sowie eingehend Port 443 auf die veröffentlichten Web-Pfade (EWS, Autodiscover), was über die WAF läuft und im Publishing-Artikel behandelt ist. Ausgehend braucht der Exchange-Server Port 25 zum EXO-Smarthost und Port 443 zu den Microsoft-Endpunkten für OAuth und die Hybrid-Dienste. Das war's — mehr Löcher braucht der Hybrid nicht, und jede weitere 25er-Freigabe (insbesondere die historische »von überall«) gehört auf den Prüfstand. Faustregel für die Regelpflege: Jede Zeile der Portmatrix in diesem Artikel entspricht genau einer Firewall-Regel — hat dein Regelwerk mehr SMTP-Zeilen als die Matrix, ist mindestens eine davon ein Kandidat fürs Aufräumen.

Wie beschränke ich Einlieferung auf Exchange Online?

In zwei Schichten, die dieselbe IP-Liste verwenden. Schicht eins, die Firewall: Auf der XGS eine IP-Hostgruppe »EXO-SMTP« mit Microsofts dokumentierten Exchange-Online-Netzen anlegen (Quelle: der offizielle Endpunkt-Webservice) und diese Gruppe als Quellbedingung in die eingehende 25er-DNAT-Regel setzen; eine Verwerfen-Regel mit Logging fängt den Rest. Schicht zwei, der Exchange: Den Receive Connector für den Hybrid-Verkehr über seine erlaubten Remote-IP-Bereiche auf dieselben Netze eingrenzen — so bleibt die Beschränkung selbst dann wirksam, wenn an der Firewall einmal eine Regel verrutscht. Der Effekt ist erheblich: Jede eingehende Mail muss zwangsläufig durch die Cloud-Filterung, Direktzustellung an der Abwehr vorbei ist unmöglich, und der Server ist für Spammer-Scans schlicht nicht mehr ansprechbar. Zur Pflege gehört ein Versions-Alarm auf den Endpunkt-Webservice plus Quartals-Abgleich — und als Frühwarnung für eine veraltete Liste dienen Timeouts einzelner Microsoft-Netze im Message Trace.

Warum landen Hybrid-Mails im Spam?

Fast immer ist die Absender-Authentifizierung schuld, und der Blick in die Kopfzeilen der betroffenen Mail liefert den Beweis — dort stehen SPF-, DKIM- und DMARC-Ergebnis im Klartext. Verdächtiger Nummer eins ist der On-Prem-Direktversand: Sendet dein Server unter eigener IP, ohne dass diese im SPF-Eintrag steht, scheitert die Prüfung — und selbst mit korrektem SPF fehlt diesen Mails die DKIM-Signatur, was bei zunehmend strengen Empfängern Zustellbarkeit kostet. Die sauberste Abhilfe: ausgehend über Exchange Online routen, dann stimmen SPF und DKIM automatisch. Verdächtiger Nummer zwei sind Schattenversender — Kopierer, ERP, Newsletter-Tools —, die unter deiner Domain senden, ohne im SPF-Gefüge aufzutauchen; die fördert ein DMARC-Report im Beobachtungsmodus zuverlässig zutage. Und Nummer drei bei Direktversand: eine belastete IP-Reputation, prüfbar über die einschlägigen Blocklisten-Checks.

Muss die Firewall ausgehenden Port 25 erlauben?

Ja — aber für genau einen Host: den Exchange-Server, der seine Post an den EXO-Smarthost übergibt (und im Direktversand-Szenario in die Welt). Für alle anderen Systeme im Netz lautet die Antwort ein entschiedenes Nein mit Protokollierung: Eine Verwerfen-Regel für Port 25 aus dem LAN, mit aktiviertem Logging, ist die simpelste und wirksamste Anti-Botnet-Maßnahme im ganzen Regelwerk — jeder infizierte Client, der sein Spam-Kontingent direkt zustellen will, läuft dagegen, und jeder geloggte Treffer ist eine kostenlose Frühwarnung, dass auf dem betreffenden Gerät etwas nicht stimmt. Der Nebeneffekt schützt bares Geld: Ohne diese Regel genügt ein einziger verseuchter PC, um die öffentliche IP der Firma auf Blocklisten zu befördern — und dann leidet ausgerechnet der legitime Mailversand. Sonderfälle wie Multifunktionsgeräte, die scannen und mailen wollen, gehören nicht in eine Ausnahme, sondern an einen authentifizierten Relay-Weg über den Exchange oder Port 587.

Wie prüfe ich den Konnektor-TLS-Handshake?

Von beiden Enden, mit Bordmitteln. Richtung Cloud zu On-Prem: Der Message Trace in Exchange Online zeigt bei TLS-Problemen den konkreten Fehler des Zustellversuchs. Die Prüfkette dahinter: Ist das Zertifikat gültig? Entspricht der Antragstellername exakt dem im Konnektor hinterlegten (nach jedem Zertifikatstausch die erste Frage!)? Ist die Kette samt Zwischenzertifikat vollständig — von extern verifizierbar mit einem TLS-Prüfwerkzeug gegen Port 25, das auch zeigt, ob STARTTLS sauber angeboten wird? Richtung On-Prem zu Cloud: Get-Queue liefert im LastError die Gegenprobe. Und wenn STARTTLS im Angebot des Servers fehlt, obwohl es konfiguriert ist: Dann sitzt fast sicher eine Zwischenstation im Pfad, die am SMTP-Dialog herumfiltert — der Blick gehört dann auf Firewall-Regeln und etwaige Mail-Prüffunktionen im Weg.

Was ändert sich bei zentralem Mailfluss?

Beim Centralized Mail Transport dreht sich die ausgehende Richtung um: Auch Mails aus Cloud-Postfächern verlassen die Organisation über deinen On-Prem-Server — Exchange Online reicht sie per Konnektor zurück, On-Prem versendet ins Internet. Für die Firewall heißt das: Der ausgehende 25er-Verkehr geht jetzt in die Welt statt nur zum Smarthost, das Volumen steigt spürbar, und die Verfügbarkeitslogik verschärft sich — steht dein Server oder deine Leitung, steht der komplette Firmen-Mailausgang, auch der der Cloud-Nutzer. Dazu kommen die Reputationspflichten des Direktversands: eigene IP im SPF, gepflegte Absender-Reputation, DKIM-Frage beim lokalen Gateway. Deshalb die klare Einordnung: CMT ist ein Compliance-Werkzeug — gerechtfertigt, wenn eine lokale Pflicht-Instanz im Ausgangspfad steht (Signatur-Appliance, Verschlüsselungs-Gateway, Archivierung), andernfalls ein Umweg, der Verfügbarkeitsrisiko ohne Gegenwert einkauft. Wer den Grund nicht aufschreiben kann, bleibt beim Standard.

Fazit: Zwei Regeln, eine IP-Liste, null Bastelei im Pfad

Der Hybrid-Mailfluss ist unspektakulärer, als sein Ruf vermuten lässt — wenn die Architektur stimmt: MX auf Exchange Online, Filterung in der Cloud, und die XGS als disziplinierter Streckenposten mit genau zwei SMTP-Regeln: eingehend 25 nur aus Microsofts Netzen, ausgehend 25 nur für den Exchange. Dazu die Unterlassungsdisziplin (keine zweite Filterstufe, kein Antasten von STARTTLS), die gepflegte EXO-IP-Gruppe mit Versions-Alarm, und auf der DNS-Seite das Dreigestirn aus schlankem SPF, aktiviertem DKIM und einem DMARC, der vom Beobachten schrittweise zum Durchgreifen wächst. Wer dann noch die Diagnose-Systematik verinnerlicht — immer am wartenden Ende ansetzen, der Fehlercode zeigt die Ursache —, hat einen Mailfluss, der jahrelang einfach läuft. Und sollte er doch einmal stocken, weißt du jetzt, in welcher Warteschlange die Wahrheit steht.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Die 443-Seite desselben Duetts — EWS-Publishing, Zertifikatsketten und die Free/Busy-Falle — steht im Exchange-Publishing-Artikel [LINK: B4]. Warum die Namensauflösung im Hybrid ein eigenes Kapitel verdient, von Autodiscover bis zum Smarthost, klärt der Split-DNS-Artikel [LINK: B10]. Und wie aus den geloggten 25er-Verwerfern echte Frühwarnungen im SIEM werden, zeigt [LINK: B8].