M365 Exchange Online | Direct Send blocken

Der MX-Record zeigt auf dein Secure Email Gateway, die Filterung läuft dort, und trotzdem landen Nachrichten im Postfach, die das Gateway nie gesehen haben. Oft fällt das erst auf, wenn eine gefälschte Mail von der eigenen Geschäftsführungsadresse durchkommt. Ursache ist kein Fehler im Gateway, sondern ein offener zweiter Weg in den Tenant.

Jeder Microsoft-365-Tenant hat einen öffentlich auflösbaren Endpunkt der Form deinedomain-de.mail.protection.outlook.com. Dieser Endpunkt nimmt Verbindungen aus dem Internet an, unabhängig davon, wohin dein MX-Record zeigt. Der MX-Record ist nur ein DNS-Hinweis für gutwillige Absender. Wer den Endpunkt kennt, verbindet sich direkt und umgeht damit jede vorgeschaltete Filterung.

Microsoft nennt das Verfahren Direct Send. Gedacht ist es für Drucker, Scanner und Altanwendungen, die ohne Authentifizierung Mails an interne Postfächer zustellen. Genau dieser Mechanismus lässt aber auch einen Angreifer anonym unter einer deiner akzeptierten Domänen zustellen. Was du dagegen brauchst, sind vier Ebenen: der Tenant-Schalter gegen Direct Send, ein eng gebundener Inbound Connector, eine Transportregel als Auffangnetz und eine saubere Absenderauthentifizierung.

Für die Umsetzung brauchst du die Rolle Organisationskonfiguration (für Set-OrganizationConfig), Exchange-Administrator für Connectors und Regeln sowie Sicherheitsadministrator für die Defender-Richtlinien. Hol dir die Rollen zeitlich begrenzt über PIM, statt sie dauerhaft zu tragen.

Vor der ersten Änderung sammelst du: alle öffentlichen IP-Adressen des Gateways inklusive Ausweichrechenzentren, den Zertifikatsnamen, mit dem sich das Gateway gegenüber EOP ausweist, alle akzeptierten Domänen sowie den aktuellen Stand von SPF, DKIM und DMARC je Versanddomäne.

Diese Datei ist dein Rollback-Anker. Ohne sie diskutierst du im Störungsfall aus dem Gedächtnis.

Der stärkste einzelne Schalter ist RejectDirectSend in der Organisationskonfiguration. Ist er aktiv, lehnt EOP jede anonyme Nachricht ab, deren P1-Absender (Envelope Mail From) zu einer deiner akzeptierten Domänen gehört, sofern sie nicht über einen Connector authentifiziert eingeliefert wurde. Der Absender bekommt:

Die Einstellung wirkt auch auf Subdomänen einer akzeptierten Domäne, wenn dort MatchSubDomains aktiv ist. In GCC High, DoD und den USNat- sowie USSec-Umgebungen steht sie nicht zur Verfügung.

Bevor du schaltest, brauchst du die Liste der legitimen Direct-Send-Quellen. Drucker, ERP, Monitoring, Ticketsystem und Marketing-Plattformen liefern häufig unauthentifiziert unter deiner Domäne ein und brechen ab, sobald der Schalter steht. Die SPF-Records deiner Domänen sind ein Anhaltspunkt, der eigentliche Nachweis steht im Change Optics Report im Exchange Admin Center. Der Bericht zeigt Nachrichten, die von der Umstellung betroffen wären, und ist damit die belastbarere Quelle als jede Vermutung.

Für jede legitime Quelle legst du vorher einen eigenen Partner-Connector an. Erst danach schaltest du um:

Die Änderung braucht bis zu 30 Minuten, bis sie auf allen EOP-Servern greift. Wer sofort testet, misst den alten Zustand. In neuen Tenants will Microsoft die Ablehnung künftig als Standard setzen und dort auch das Abschalten unterbinden. Für bestehende Tenants bleibt der Wert auf False, bis du ihn selbst änderst.

RejectDirectSend greift nur bei Nachrichten, deren Absenderdomäne dir gehört. Eine gefälschte Mail von einer fremden Domäne, direkt an den EOP-Endpunkt geliefert, läuft weiter durch. Diese Lücke schließt der Partner-Connector mit den Parametern RestrictDomainsToCertificate oder RestrictDomainsToIPAddresses. Sie erklären gegenüber EOP: Post für meine Domänen nehme ich nur von dieser Quelle an.

Jede andere Quelle bekommt:

Die Zertifikatsbindung ist robuster, weil sie IP-Wechsel des Anbieters überlebt und kryptografisch prüfbar ist. Sie setzt voraus, dass dein Gateway ein passendes öffentliches Zertifikat vorweist. Die IP-Bindung ist schneller eingerichtet und erzeugt dafür Pflegeaufwand, sobald der Anbieter Adressbereiche ändert.

Beide Parameter wirken ausschließlich auf Connectors vom Typ Partner. Existiert bereits ein OnPremises-Connector für dieselbe IP oder dasselbe Zertifikat, ersetzt der ihn nicht. Beide Connectors dürfen parallel bestehen.

Der Connector schützt gegen die direkte Einlieferung. Eine Transportregel darüber fängt Konfigurationsfehler ab und liefert im Nachrichtenprotokoll eine saubere Spur, wer wann versucht hat, am Gateway vorbeizuliefern.

Eine Ausnahme über den Header X-MS-Exchange-Organization-AuthAs mit dem Wert Internal brauchst du hier nicht. Die Bedingung FromScope NotInOrganization greift ohnehin nur bei nicht authentifizierten externen Absendern, und Exchange stempelt diese Header selbst. Wer sie zusätzlich als Ausnahme führt, baut eine Bedingung ein, die im besten Fall wirkungslos ist.

Betreibst du Hybrid mit lokalen Exchange-Servern, prüfe vorher im Testmodus, ob deren Nachrichten als organisationsintern gewertet werden. Falls nicht, gehören ihre öffentlichen IP-Adressen in die Ausnahmeliste.

Die ersten drei Schritte sichern den Transportweg. Fälschungen, die korrekt über das Gateway laufen, weil ein Angreifer eine fremde Domäne missbraucht, fängst du nur über Authentifizierungsprüfungen.

SPF gehört auf Hard Fail (-all) mit ausschließlich deinen Versandquellen. DKIM aktivierst du für jede Versanddomäne im Defender-Portal. Bei DMARC ist p=quarantine das Minimum und p=reject das Ziel, ausgewertet über einen Reporting-Dienst, sonst bleiben die RUA-Daten ungelesen.

In der Anti-Phishing-Richtlinie setzt du Spoof Intelligence aktiv, DMARC-Richtlinie berücksichtigen aktiv (sonst wirkt dein p=reject gegen dich gerichtete Fälschungen nicht), die Aktion für nicht authentifizierte Absender auf Quarantäne und den Identitätswechselschutz explizit auf Geschäftsführung, Finanzbuchhaltung und Personalabteilung. In der Anti-Spam-Richtlinie senkst du die BCL-Schwelle auf 6 oder darunter und verzichtest auf Zulassungslisten, weil sie die häufigste Ursache für durchgelassene Fälschungen sind.

Weil das Gateway die ursprüngliche Absender-IP überschreibt, prüft EOP SPF gegen die Gateway-IP. Das Ergebnis ist immer ein Pass, unabhängig davon, wer die Nachricht ursprünglich verschickt hat. Enhanced Filtering (auch Skip Listing) weist EOP an, in der Received-Kette weiter zurückzugehen und die echte Quell-IP zu bewerten.

Du findest die Konfiguration im Defender-Portal unter https://security.microsoft.com/skiplisting. Dort wählst du deinen Connector, setzt Diese IP-Adressen überspringen und trägst alle öffentlichen Adressen des Gateways ein, inklusive Zwischenstationen. Starte mit einer kleinen Empfängergruppe und weite erst danach auf die Organisation aus.

Zwei Nebenwirkungen sind einzuplanen. Transportregeln, die den SCL-Wert für diesen Connector auf -1 setzen, musst du danach deaktivieren, das schreibt Microsoft ausdrücklich vor. Und deine Regel aus Schritt 3 arbeitet mit einer IP-Ausnahme: Sobald EOP die ursprüngliche Absender-IP bewertet, kann die Ausnahme auf die Gateway-IPs ins Leere laufen. Prüfe diese Kombination im Auditmodus, bevor du erzwingst.

Lokale Hybrid-Server gehören nicht auf die Skip-Liste, wenn dein MX auf EOP zeigt. Microsoft unterstützt das in diesem Szenario nicht.

Für den Direct-Send-Test brauchst du ein externes System mit offenem Port 25. Send-MailMessage ist von Microsoft als veraltet markiert und für solche Tests unbrauchbar, weil es keine sichere Verbindung garantiert. Nimm stattdessen swaks oder einen vergleichbaren SMTP-Client:

Erwartet wird 550 5.7.68. Wiederholst du den Test mit einer fremden Absenderdomäne, etwa einer Freemail-Adresse, muss 550 5.7.51 kommen, weil dann der Partner-Connector greift.

Den Gegentest lieferst du über eine echte externe Nachricht durch das Gateway. Für die Auswertung nutzt du Get-MessageTraceV2, weil Get-MessageTrace seit dem 1. September 2025 abgekündigt ist. Das neue Cmdlet setzt Version 3.7.0 des Exchange-Online-Moduls voraus, liefert bis zu 90 Tage Historie und maximal 10 Tage je Abfrage.

Im Header einer zugestellten Nachricht prüfst du drei Dinge: Die Received-Kette zeigt das Gateway als letzten Hop vor EOP, Authentication-Results-Original weist SPF gegen die echte Absender-IP aus statt gegen die Gateway-IP, und X-MS-Exchange-SkipListedInternetSender ist gesetzt. Fehlt der letzte Header, arbeitet Enhanced Filtering nicht.

Für die laufende Überwachung filterst du im Nachrichtenprotokoll auf fehlgeschlagene Zustellungen mit den Codes 5.7.68 und 5.7.51. Jeder Treffer ist ein abgewehrter Umgehungsversuch. Im Advanced Hunting lässt sich das gleiche Bild breiter ziehen:

Bricht ein geschäftskritischer Mailfluss, drehst du in umgekehrter Reihenfolge zurück:

Der Gateway-Bypass ist kein Produktfehler, sondern eine Standardeinstellung, die aus einer Zeit stammt, in der ein öffentlich erreichbarer SMTP-Endpunkt unkritisch schien. Wer heute ein Gateway betreibt und den Tenant nicht zusätzlich härtet, hat eine Filterkette gebaut, die sich mit einer einzigen SMTP-Verbindung umgehen lässt. Der Aufwand für die Absicherung liegt bei überschaubaren zwei bis drei Stunden Konfiguration, der eigentliche Aufwand steckt in der Bestandsaufnahme davor.

Genau dort liegt auch das Betriebsrisiko. RejectDirectSend trifft jede Anwendung, die unauthentifiziert unter deiner Domäne einliefert, und diese Anwendungen sind selten dokumentiert. Der Change Optics Report im Exchange Admin Center nimmt dir hier das Raten ab und sollte am Anfang jedes Projekts stehen, nicht am Ende. Wer stattdessen aus dem SPF-Record ableitet, findet die Quellen, die jemand einmal eingetragen hat, und übersieht die, die nie dokumentiert wurden.

Für die Reihenfolge hat sich bewährt: erst Bestandsaufnahme und Connectors für legitime Quellen, dann die Transportregel im Auditmodus, dann RejectDirectSend, dann die Bindung des Inbound Connectors und zuletzt Enhanced Filtering. So bleibt jede Änderung einzeln nachweisbar, und du weißt im Störungsfall, welcher Schritt sie ausgelöst hat.

Aus Compliance-Sicht ist die Kette dankbar dokumentierbar. Für ein ISO-27001-Audit oder eine NIS2-Bewertung kannst du technische Maßnahme, Prüfnachweis (Testergebnis mit NDR-Code) und laufende Kontrolle (Auswertung der 5.7.68- und 5.7.51-Treffer) an einem Ort belegen. Das ist mehr, als die meisten Organisationen zum Thema Spoofing vorweisen können.