M365 Exchange Online | Gateway-Bypass schließen

Dein MX-Record zeigt auf ein vorgeschaltetes Secure Email Gateway, das Gateway filtert sauber, und trotzdem landet eine Mail von ceo@deinefirma.de mit gefälschter Rechnung im Postfach der Buchhaltung. Im Header taucht das Gateway gar nicht auf. Der Absender hat den MX-Record ignoriert und direkt bei Exchange Online Protection (EOP) eingeliefert.

Exchange Online verhält sich dabei wie dokumentiert. Jeder Tenant hat einen öffentlich auflösbaren Endpunkt nach dem Muster deinefirma-de.mail.protection.outlook.com. Der Name lässt sich aus der Domain ableiten, und der Endpunkt nimmt per Default Mails für alle akzeptierten Domänen an, egal wohin dein MX zeigt. Microsoft formuliert das im Exchange Team Blog trocken: Wer eine komplexe Mail-Route mit Drittanbieter einführt, muss den direkten Weg selbst schließen.

Der IST-Zustand in vielen Tenants mit zentralem Mailflow sieht deshalb so aus: Das Gateway ist die erste Verteidigungslinie, aber nur für Absender, die sich an DNS halten. Das SOLL ist ein Tenant, der eingehende Mail ausschließlich über einen authentifizierten Partner-Connector annimmt, anonyme Einlieferungen mit eigener Absenderdomäne zusätzlich abweist und hinter dem Gateway trotzdem die echte Absender-IP für SPF, DKIM und DMARC sieht.

Microsoft unterscheidet seit dem Beitrag „Direct Send vs sending directly to an Exchange Online tenant“ vom August 2025 zwei Szenarien, und die Unterscheidung bestimmt die Reihenfolge der Maßnahmen.

Direct Send meint anonyme Mails, deren Envelope-Absender (P1 Mail From) eine deiner akzeptierten Domänen trägt. Gedacht ist das für Multifunktionsgeräte und Fachanwendungen, die ohne Anmeldung an interne Postfächer schicken. Dagegen hilft der Schalter RejectDirectSend.

Direkteinlieferung meint jede Mail, die am Gateway vorbei an den EOP-Endpunkt geht, auch mit fremder Absenderdomäne. RejectDirectSend greift hier nicht, weil die Einstellung nur die eigene Domäne im Envelope prüft. Microsoft beantwortet die Frage, ob der Schalter einen Tenant auf den Drittanbieter festnageln kann, im FAQ ausdrücklich mit Nein. Das erledigt allein ein Partner-Connector mit Bindung an Zertifikat oder IP.

Daraus folgt die Reihenfolge dieser Anleitung: erst inventarisieren, dann den Connector abriegeln, danach Direct Send abschalten, und erst dann Filterung und Authentifizierung feinjustieren.

Bevor du irgendetwas blockierst, brauchst du eine Liste aller Systeme, die heute legitim direkt einliefern. Drucker, Scanner, ERP, Monitoring, Newsletter-Plattformen. Jedes dieser Systeme bricht in dem Moment weg, in dem du den Connector abriegelst oder Direct Send ablehnst.

Seit Oktober 2026 ist dafür der Change Optics Report allgemein verfügbar (Message Center MC1526668). Er zeigt im Szenario DRS eine Stichprobe empfangener Direct-Send-Nachrichten mit Absender und Nachrichteneigenschaften.

Die Stichprobe ersetzt keine Vollständigkeit. Für einen vollständigen Blick auf alle Mails, die ohne Connector eingegangen sind, nutzt du die historische Nachrichtenablaufverfolgung (bis 90 Tage):

Mit Defender for Office 365 Plan 2 geht es schneller per Advanced Hunting. Die Abfrage lehnt sich an das Beispiel aus dem Exchange Team Blog an:

Zeigt dein MX bereits auf das Gateway, aber es existiert noch kein Partner-Connector dafür, taucht in beiden Auswertungen auch der reguläre Gateway-Verkehr auf. Den filterst du über die Gateway-IPs heraus. Was übrig bleibt, ist deine Liste der Direkteinlieferer.

Sichere vor jeder Änderung den Ist-Stand, damit ein Rollback eine Sache von Minuten bleibt:

Der Partner-Connector schließt die Lücke, die das Gateway offen lässt. Microsoft beschreibt ihn in Schritt 4 der Learn-Seite zum Mailflow mit Drittanbieter-Diensten: ein Inbound-Connector vom Typ Partner, gebunden an das TLS-Zertifikat des Gateways (bevorzugt) oder an dessen IP-Adressen, plus RestrictDomainsToCertificate oder RestrictDomainsToIPAddresses auf $true. EOP lehnt danach jede Mail an deine Domänen ab, die nicht über diese Verbindung kommt.

Die Zertifikatsbindung übersteht IP-Wechsel beim Anbieter und ist deshalb die bessere Wahl. Den Zertifikatsnamen liefert die Dokumentation deines Gateway-Anbieters.

Im Exchange Admin Center legst du denselben Connector über den Assistenten an: Verbindung von Partnerorganisation zu Office 365, dann die Authentifizierung über den Zertifikatsnamen oder die IP-Liste wählen.

Drei Punkte entscheiden, ob der Connector hält, was er verspricht.

Die IP-Liste muss vollständig sein, inklusive Disaster-Recovery-Regionen des Anbieters. Fehlt ein Rechenzentrum, lehnt EOP genau dessen Zustellungen mit 550 5.7.51 TenantInboundAttribution; There is a partner connector configured that matched the message's recipient domain ab. Weil EOP die Verbindung schon beim SMTP-Dialog abweist, suchst du diese Fehler im Zustellprotokoll des Gateways.

RestrictDomainsTo* wirkt nur auf Partner-Connectoren. Hast du für dasselbe Gateway bereits einen Connector vom Typ OnPremises, brauchst du den Partner-Connector trotzdem. Laut Microsoft laufen beide parallel ohne Konflikt.

Die Geräte aus deiner Bestandsaufnahme brauchen einen eigenen Weg. Entweder liefern sie künftig über das Gateway oder per authentifizierter SMTP-Übermittlung ein, oder du nimmst ihre festen IPs in einen weiteren, eng gefassten Connector auf.

Mit RejectDirectSend weist EOP anonyme Mails ab, deren Envelope-Absender eine akzeptierte Domäne trägt und die keinem Connector zugeordnet sind. Die Einstellung war ab April 2025 in der Preview, für September 2025 kündigte Microsoft die allgemeine Verfügbarkeit an (MC1093237). Auf bestehenden Tenants steht sie auf $false.

Die Änderung braucht laut Microsoft bis zu 30 Minuten, bis sie im ganzen Dienst greift. Abgewiesene Absender erhalten 550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources.

Zwei Einschränkungen solltest du kennen, bevor du dich darauf verlässt.

Die Ablehnung passiert auf Protokollebene. Microsoft stellt in den Kommentaren zum Ankündigungsbeitrag klar, dass solche Mails in der Nachrichtenablaufverfolgung nicht auftauchen. Ein Monitoring auf 5.7.68 im Message Trace läuft deshalb ins Leere.

Die Prüfung schaut ausschließlich auf die Domäne im Envelope. ReliaQuest hat am 3. September 2026 gezeigt, was daraus folgt: Ein leerer Envelope-Absender (MAIL FROM:<>) liefert keine Domäne zum Vergleichen, die Mail wird angenommen, und im sichtbaren From-Header steht trotzdem eine interne Adresse. ReliaQuest wertet das ausdrücklich als Grenze des Funktionsumfangs, nicht als Sicherheitslücke. Im selben Test hat ein IP-gebundener Inbound-Connector jeden Versuch geblockt, mit und ohne leeren Envelope, weil er auf die Quelle prüft statt auf ein Absenderfeld. Deshalb steht der Connector in dieser Anleitung vor dem Direct-Send-Schalter.

Microsoft hat angekündigt, RejectDirectSend für neue Tenants standardmäßig zu aktivieren und dort nicht mehr abschaltbar zu machen. Ein verbindlicher Termin im Message Center war bei Redaktionsschluss nicht auffindbar. Für bestehende Tenants ändert die Ankündigung ohnehin nichts.

Ein falsch gepflegter Connector öffnet die Tür wieder, ohne dass es jemand merkt. Eine Transportregel, die alles abfängt, was nicht von freigegebenen IPs kommt, macht solche Fehler sichtbar. Microsoft empfiehlt im Exchange Team Blog eine Regel mit Quarantäne statt Ablehnung, Priorität 0 und gestoppter Regelverarbeitung. Die Ausnahme über den Header X-MS-Exchange-Organization-AuthAs mit dem Wert Internal verhindert, dass authentifizierter interner Verkehr und Hybrid-Mails in der Quarantäne landen.

In ExceptIfSenderIpRanges gehören die Gateway-IPs, die IPs deiner lokalen Exchange-Server bei Hybrid und die festen Quellen aus der Bestandsaufnahme. Der Modus Audit protokolliert nur. Lass die Regel so mindestens eine Woche laufen und prüf die Treffer im Bericht zu Nachrichtenflussregeln.

Rechne mit Treffern aus Microsoft-eigenen Diensten. In den Kommentaren zum Microsoft-Beitrag berichten Admins von Teams- und Kalendereinladungen, die über Microsoft-IPv6-Adressen am Connector vorbei eingehen. Solche Fälle klärst du im Audit-Modus, bevor du mit Set-TransportRule -Mode Enforce scharf schaltest.

Nach Schritt 1 kommt jede Mail mit der IP des Gateways bei EOP an. EOP prüft SPF dann gegen das Gateway, nicht gegen den ursprünglichen Absender. Ohne Korrektur arbeiten Spoof-Intelligence und DMARC-Auswertung mit falschen Daten. Microsoft bezeichnet Enhanced Filtering for Connectors (Skip Listing) für dieses Szenario als dringend empfohlen.

Die Funktion sagt EOP, welche Hops in der Received-Kette übersprungen werden sollen, damit die echte Quell-IP bewertet wird. Teste zuerst mit wenigen Empfängern:

Beim Pilot gilt eine Falle: Das Skip Listing greift nur, wenn alle Empfänger einer Mail in der Liste stehen, und nur für die exakt eingetragenen Adressen inklusive Proxy-Adressen. IPv6-Adressen lassen sich laut Learn derzeit nur per PowerShell eintragen.

Nach dem Aktivieren schaltest du Transportregeln ab, die für Gateway-Mails SCL -1 setzen. Microsoft verlangt das ausdrücklich, weil sie die Filterung aushebeln, die du gerade repariert hast. Prüf anschließend im Audit-Bericht, ob die Ausnahme der Regel aus Schritt 3 weiter greift.

Für Hybrid-Umgebungen gibt es eine harte Grenze. Bei linearer Route (Internet > Gateway > lokales Exchange > Microsoft 365) darfst du die lokalen Server in die Skip-Liste aufnehmen. Bei nicht linearer Route, in der Mails von Microsoft 365 zum lokalen Exchange und zurück laufen, unterstützt Microsoft das nicht, weil EOP die zurückkehrenden Mails erneut bewertet und als Spam einstufen kann.

Der Transportweg ist jetzt dicht. Spoofing, das korrekt durch das Gateway läuft, fängst du nur über Authentifizierung ab.

Beim SPF-Record weicht die Praxis oft von Microsofts Vorgabe ab. Läuft ausgehende Mail direkt aus Microsoft 365 ins Internet, reicht v=spf1 include:spf.protection.outlook.com -all. Das Gateway gehört nur dann in den Record, wenn es auch ausgehend sendet. Eingangs-IPs haben im SPF deiner Domäne nichts zu suchen.

DKIM aktivierst du für jede Absenderdomäne im Defender-Portal. Für DMARC startest du mit p=quarantine und Berichtsadresse, wertest die Aggregatberichte aus und gehst auf p=reject, sobald keine legitime Quelle mehr durchfällt:

In der Anti-Phishing-Richtlinie aktivierst du Spoof Intelligence und die Option „Honor DMARC record policy when the message is detected as spoof“, damit EOP die DMARC-Richtlinie des Absenders bei p=reject und p=quarantine auch umsetzt. Den Identitätswechselschutz richtest du auf Geschäftsführung, Buchhaltung und Personalabteilung aus. Diese granulare Einstellung setzt Defender for Office 365 Plan 1 voraus.

Zulassungslisten für Absender oder ganze Domänen sind der häufigste Grund, warum ein sauber gebauter Schutz trotzdem Phishing durchlässt. ReliaQuest nennt sie in der Analyse zum Null-Sender-Bypass ebenfalls als Risiko. Räum sie im selben Zug auf.

Die Tests laufen von einem externen Host, auf dem ausgehender Port 25 offen ist. In vielen Firmen- und Heimnetzen ist er gesperrt, ein kleiner VPS ist dafür praktischer. swaks erlaubt im Gegensatz zu Send-MailMessage auch einen leeren Envelope-Absender.

Alle drei Versuche müssen mit einem 5xx-Code abgewiesen werden. Welcher Code kommt, 5.7.51 vom Connector oder 5.7.68 von Direct Send, hängt davon ab, welche Prüfung zuerst greift. Für den Test zählt nur die Ablehnung. Kommt Test 3 durch, ist der Connector nicht korrekt gebunden.

Danach schickst du eine Mail von einem externen Postfach über den regulären MX und prüfst die Zustellung mit der neuen Nachrichtenablaufverfolgung. Die alten Cmdlets Get-MessageTrace und Get-MessageTraceDetail sind seit September 2025 abgekündigt:

Die Quell-IP der Zustellung muss eine Gateway-IP sein. Für die Gegenprobe filterst du mit -FromIP gezielt auf eine Adresse außerhalb deiner Gateway-Liste: Nach dem Rollout darf diese Abfrage keine zugestellten Mails mehr liefern. Beachte, dass Get-MessageTraceV2 pro Abfrage höchstens zehn Tage abdeckt. Im Header der zugestellten Mail belegen X-MS-Exchange-SkipListedInternetSender und X-MS-Exchange-ExternalOriginalInternetSender, dass Enhanced Filtering arbeitet und die echte Quelle erkannt hat.

Weil abgewiesene Verbindungen nicht im Tenant protokolliert werden, überwachst du die Mails, die trotzdem durchkommen. Die Abfrage aus der Vorbereitung liefert nach dem Rollout im Idealfall nur noch einzelne Treffer. Jeder neue Eintrag ist ein Hinweis auf eine Lücke.

Für das Muster aus der ReliaQuest-Analyse eignet sich eine eigene Abfrage. Leere Envelope-Absender sind für Unzustellbarkeitsberichte legitim, verdächtig wird erst die Kombination mit einer internen Domäne im From-Header:

Ergänze das um die DMARC-Aggregatberichte und eine Warnungsrichtlinie auf Treffer der Transportregel aus Schritt 3.

Fällt nach der Umstellung ein geschäftskritischer Absender aus, nimmst du die Schritte in umgekehrter Reihenfolge zurück:

Besser als ein vollständiger Rollback ist meist ein zusätzlicher, eng gefasster Connector für den vergessenen Absender. Damit bleibt der Rest der Absicherung aktiv.

Der Schalter RejectDirectSend gilt in vielen Anleitungen als zentrale Maßnahme gegen Gateway-Bypass. Er deckt aber genau einen Fall ab, anonyme Mails mit deiner eigenen Domäne im Envelope, und der Null-Sender-Trick zeigt, wie eng diese Abdeckung ist. Den Bypass schließt der Partner-Connector mit Bindung an Zertifikat oder IP. Microsoft empfiehlt ihn für Drittanbieter-Gateways seit Jahren auf Learn, und er prüft das einzige Merkmal, das ein Angreifer nicht frei wählen kann: die Quelle der Verbindung.

Die Reihenfolge entscheidet über den Erfolg. Wer zuerst sperrt und dann inventarisiert, erfährt über den Helpdesk, welcher Scanner noch direkt einliefert. Der Change Optics Report und die historische Nachrichtenablaufverfolgung machen das vorher sichtbar. Die Transportregel im Audit-Modus zeigt dir ein zweites Mal, was hängen bleiben würde, bevor irgendetwas abgewiesen wird.

Enhanced Filtering wird oft als optionales Feintuning behandelt. Das ist ein Fehler mit Folgen: Ohne Skip Listing bewertet EOP jede Mail so, als käme sie vom Gateway, und deine DMARC-Richtlinie auf p=reject greift gegen gespoofte Absender nur eingeschränkt. Wer ein Gateway vorschaltet und Enhanced Filtering nicht konfiguriert, bezahlt zwei Filterschichten und bekommt eine davon nur halb.

Ein Restrisiko bleibt beim Gateway selbst. Spoofing, das korrekt durch die Gateway-Infrastruktur läuft, fängst du nur über SPF, DKIM, DMARC und eine Anti-Phishing-Richtlinie ohne Zulassungslisten ab. Der Transportweg ist nach dieser Anleitung dicht, die Authentifizierung musst du trotzdem pflegen.

Plane für die Umstellung mindestens zwei Wochen ein: eine Woche Audit, ein paar Tage Beobachtung nach der Connector-Härtung, dann Direct Send und die scharfe Regel. Jeder Schritt lässt sich einzeln zurücknehmen.