In vielen Tenants, die ich betreue, gehört die externe Weiterleitung in Exchange Online zu den am häufigsten unterschätzten Risiken für Datenabfluss. Nach einer Kontoübernahme nutzen Angreifer kaum eine Methode so gern, um Mails dauerhaft nach außen zu schleusen. Das geschieht meist so unauffällig, dass es niemand bemerkt, bis es richtig wehtut. Seit Microsoft die automatische Weiterleitung standardmäßig blockiert, gibt es zwar weniger offene Lücken. Sicher ist man aber erst, wenn man die verschiedenen Stellschrauben und Ausnahmen kennt und regelmäßig prüft.

Drei Stellen entscheiden über die externe Weiterleitung

Am wirksamsten steuert man die externe Weiterleitung über die Einstellung „Automatische Weiterleitung“ in der Outbound-Spamfilterrichtlinie von Microsoft Defender for Office 365. Sie liegt im Microsoft-Defender-Portal unter Email & Collaboration → Policies & rules → Threat policies → Anti-spam policies (Hintergrund). Zur Auswahl stehen „Automatic - System-controlled“ (Standard, also blockiert), „On“ (erlaubt) und „Off“ (explizit blockiert). In allen neuen Tenants und in den meisten bestehenden Umgebungen ist „Automatic - System-controlled“ eingestellt, Weiterleitungen nach extern sind damit gesperrt.

Wenig Beachtung finden dagegen die Remote Domains. In Exchange Online lässt sich für jede akzeptierte Domäne unter Mail flow → Remote domains festlegen, ob Weiterleitungen an diese Domäne erlaubt sind (Dokumentation). Deaktiviert man dort die Option „Allow automatic forwarding“, ist jede automatische Weiterleitung an diese Domäne unterbunden, und zwar unabhängig von der Spam-Policy. Als dritte Ebene kommen Transportregeln (Mail flow rules) hinzu. Mit ihnen lassen sich etwa bestimmte Schlüsselwörter oder Absender gezielt blockieren oder Ausnahmen zulassen. Für das Zusammenspiel gilt eine klare Regel: Die restriktivste Einstellung gewinnt, und eine explizite Erlaubnis muss auf allen Ebenen durchgängig gesetzt sein.

Gerade in hybriden Umgebungen oder nach Migrationen erlebe ich immer wieder, dass zu großzügige Remote-Domain-Einstellungen oder Transportregeln die Outbound-Policy unterlaufen, mal mit Absicht, mal aus Versehen. Dafür habe ich einen Tipp aus der Praxis.

Wer für einzelne Nutzer gezielt eine Ausnahme braucht, legt am besten eine eigene Outbound-Spam-Policy an, bindet sie an eine Benutzergruppe und erlaubt die Weiterleitung nur dort explizit. Die Einstellungen für Remote Domains und Transportregeln sollte man trotzdem sorgfältig prüfen.

Das Diagramm zeigt das Zusammenspiel der Einstellungen

Die folgende Übersicht stellt dar, wie die einzelnen Einstellungen für die externe Weiterleitung ineinandergreifen. Wichtig dabei ist, dass bereits die restriktivste Einstellung auf irgendeiner Ebene die Weiterleitung blockiert.

flowchart TD
    UserRule["Benutzer-Inboxregel"] --> Outbound["Outbound-Spam-Policy"]
    Outbound --> RemoteDomain["Remote Domain Policy"]
    RemoteDomain --> Transport["Transportregel"]
    Transport --> Ziel["Externe Zustellung"]

Abbildung: Zusammenspiel der Einstellungen zur externen Weiterleitung in Exchange Online

Eine eigene Outbound-Policy erlaubt Ausnahmen am saubersten

Häufig werde ich gefragt, wie man einzelnen Postfächern oder Gruppen dennoch eine Weiterleitung nach extern gestatten kann, etwa für Partner, Support-Dienstleister oder eigene Testadressen. Am saubersten gelingt das mit einer eigenen Outbound-Policy. Dazu legt man im Defender-Portal unter Email & Collaboration → Policies & rules → Threat policies → Anti-spam policies eine neue Richtlinie an, die ausdrücklich für die gewünschten Nutzer oder Gruppen gilt, und stellt dort „Automatic forwarding“ auf „On“. Ein häufiger Fehler: Die Policy muss in der Rangfolge über der Standardrichtlinie stehen, sonst greift sie nicht. Ausnahmen über Remote Domains oder Transportregeln sind dagegen schwerer zu kontrollieren und deutlich unübersichtlicher.

PowerShell findet bestehende Weiterleitungen am schnellsten

Ob Postfächer bereits weitergeleitet werden, prüft man am schnellsten mit Exchange Online PowerShell. Für Postfächer mit ForwardingSmtpAddress oder aktivierter Weiterleitung im selben Tenant haben sich zwei Abfragen bewährt:

# Postfächer mit externer Weiterleitung
Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingSmtpAddress -ne $null }

# Postfächer mit "DeliverToMailboxAndForward" (interne/externe Weiterleitung)
Get-Mailbox -ResultSize Unlimited | Where-Object { $_.DeliverToMailboxAndForward -eq $true }

# Inboxregeln mit externer Weiterleitung finden
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    Get-InboxRule -Mailbox $_.UserPrincipalName | Where-Object { $_.ForwardTo -or $_.RedirectTo }
}

Die Befehle laufen in der Exchange Online PowerShell, dafür braucht man mindestens die Exchange-Online-Administratorrolle. Vor allem die Inbox-Regeln sollte man regelmäßig durchsehen und unerwünschte Einträge konsequent löschen.

In vielen Projekten ist mir zudem aufgefallen, wie oft Angreifer ausgerechnet Shared Mailboxes für Weiterleitungen missbrauchen, weil MFA dort selten verpflichtend ist. Wie man Freigaben absichert, beschreibe ich im Beitrag zu sicheren Shared Mailboxes in Exchange Online.

Zwei Berichte zeigen aktuelle Weiterleitungen auf einen Blick

Im Exchange Admin Center liefert der Bericht unter Mail flow → Message trace → Auto-forwarded messages report eine übersichtliche Aufstellung, welche Mails gerade automatisch weitergeleitet werden und an wen. Für Audits oder bei einem konkreten Verdacht ist das ein schneller Einstieg. Ergänzend bietet das Defender-Portal unter Reports eine Übersicht zum ausgehenden Mailverkehr, in der ungewöhnliche Volumina oder Zieladressen auffallen (Mehr dazu).

Keine Ausnahme sollte ohne Gegenkontrolle bleiben

Zum Glück lässt sich die externe Weiterleitung in Exchange Online heute fein abgestuft und nachvollziehbar steuern, sofern man die wichtigsten Stellschrauben kennt und regelmäßig überprüft. Im Alltag schleichen sich trotzdem oft Ausnahmen ein, die niemand dokumentiert, oder alte Regeln bleiben aktiv, obwohl sie längst keiner mehr braucht. Belastbar wird das Setup erst mit einer festen Kontrollroutine und mehreren Schutzmechanismen statt eines einzigen. Spätestens nach Vorfällen wie AiTM-Phishing-Kampagnen, bei denen Angreifer gezielt neue Regeln anlegen, lohnt sich ein regelmäßiger Blick auf bestehende Weiterleitungen und Inbox-Regeln. Dann bleibt der Tenant auch auf Dauer geschützt.