Die Tenant Allow Block List ersetzt Transportregeln mit SCL -1

In vielen Tenants, die ich betreue, stoße ich auf Transportregeln, die Mails mit SCL -1 annehmen und damit sämtliche Schutzmechanismen von Defender for Office 365 aushebeln. Meist hat das historische Gründe: Ein wichtiger Partner konnte auf einmal nicht mehr zustellen, der Vertrieb hatte Ärger mit Anhängen, oder neue Domains mussten dringend freigegeben werden. Was anfangs nach einer schnellen Lösung aussieht, entwickelt sich mit der Zeit zum Albtraum für jeden Admin. Mit SCL -1 landet die Mail nämlich garantiert im Posteingang, ganz gleich, wie verdächtig sie ist. Auch Malware, Phishing und Spoofing kommen dann ungehindert durch.

Regeln mit SCL -1 schalten sämtliche Filter ab

Die berüchtigte Bypass-Regel mit SCL -1 (über „Mail flow rules“ → „Set the spam confidence level (SCL) to -1“) nimmt Mails komplett von der Filterung aus. Malware- und Phishing-Scans, Quarantäne, ZAP oder sichere Links greifen schlicht nicht mehr. Mit kontrollierbarer Sicherheit hat das für mich nichts zu tun. Wer sich darauf verlässt, macht gezielte Angriffe leicht und weiß irgendwann nicht mehr, welche Absender oder Inhalte auf diesem Weg durchgewunken werden. Vor allem bei Domain- und Absenderfreigaben für Partner und interne Systeme erlebe ich in der Praxis immer öfter, dass einzelne Benutzer oder Gruppen versehentlich (oder absichtlich) aus den zentralen Schutzmaßnahmen herausfallen.

Mein Praxistipp: Transportregeln mit SCL -1 sollten sofort aufgespürt und entfernt werden. Im Zweifel genügt es, sie testweise auf SCL 0 oder 1 zu stellen und zu beobachten, welche legitimen Mails tatsächlich geblockt werden. Erst danach gezielt nachjustieren – aber nie pauschal alles durchwinken.

Die Tenant Allow Block List bündelt alle Ausnahmen an einer Stelle

Genau für solche Fälle hat Microsoft die Tenant Allow Block List geschaffen. Mit ihr lassen sich Domains, E-Mail-Adressen, URLs und sogar Dateien zentral und auditierbar erlauben oder blockieren. Man erreicht sie über das Defender-Portal → E-Mail & Zusammenarbeit → Richtlinien & Regeln → Bedrohungsrichtlinien → Tenant Allow/Block Lists. Dort verwaltet man Absenderadressen (auch für Spoofing-Szenarien), ganze Domains, Links (URLs) und Dateihashes. Sehr angenehm finde ich, dass viele Allow-Einträge inzwischen automatisch entstehen, sobald eine verdächtige E-Mail als „Nicht-Spam“ gemeldet und von Microsoft analysiert wurde. Diese Einträge sind immer befristet und verschwinden nach einiger Zeit von selbst. Vergessene oder missbräuchliche Freigaben werden dadurch spürbar seltener.

Eingehende Mails durchlaufen zuerst die Block- und die Allow-Liste

Das Diagramm zeigt vereinfacht, wie eingehende E-Mails gegen die Allow/Block-Listen geprüft werden, bevor die übrigen Filter ansetzen:

flowchart TD
    Eingang["E-Mail-Eingang"] --> BlockCheck["Block-Liste prüfen"]
    BlockCheck -->|"Treffer"| Abgelehnt["Ablehnen"]
    BlockCheck -->|"Kein Treffer"| AllowCheck["Allow-Liste prüfen"]
    AllowCheck -->|"Treffer"| Erlaubt["Zustellen (gefiltert, aber bevorzugt)"]
    AllowCheck -->|"Kein Treffer"| Filter["Standardfilter (Spam, Phishing, Malware)"]
    Filter --> Ergebnis["Zustellen oder blockieren"]

Abbildung: E-Mail-Prüfung mit Tenant Allow Block List und Filtern.

In Unternehmen mit wechselnden Partnern oder eigenen SaaS-Systemen bekommt man so dokumentierte Freigaben, die sich jederzeit nachvollziehen lassen. Gleichzeitig müssen Admins nicht befürchten, versehentlich legitime Kommunikation zu blockieren. Eines sollte man dabei im Hinterkopf behalten: Ein Eintrag in der Allow-Liste umgeht zwar einige Filter, aber nie alle. Schadcode etwa wird weiterhin blockiert.

Spoof Intelligence liefert befristete Freigaben direkt in die Liste

Für die Tenant Allow Block List spricht außerdem die Anbindung an Spoof Intelligence. Microsoft analysiert laufend, welche Kombinationen aus Absender und Domain vermutlich gefälscht sind und welche von legitimen Partnern stammen. Tritt eine neue Spoofing-Konstellation auf, meldet das Portal sie unter „Spoofed senders“. Als Admin entscheidet man dann gezielt, ob man für diesen Einzelfall eine Ausnahme zulässt. Solche Freigaben sind standardmäßig befristet und tauchen samt Ablaufdatum direkt in der Liste auf. Einmalige Sonderfälle wie Test-Mails von Partnern oder Migrationstools bleiben so nicht dauerhaft als Ausnahmeregel in der Infrastruktur hängen.

Die Listen gehören mindestens einmal im Quartal auf den Prüfstand

In meinen Projekten rate ich dazu, die Allow/Block-Listen mindestens quartalsweise durchzugehen. Das gilt für Dauerbrenner wie Partnerdomains und Absender aus alten Migrationen, aber genauso für automatisch erzeugte Allow-Einträge nach Admin-Submissions. Gerade diese braucht häufig niemand mehr, weil sich die Lage längst geändert hat. Im Defender-Portal ist bei jedem Eintrag zu sehen, wer ihn angelegt hat, auf welchem Weg er entstanden ist (manuell oder über eine Submission) und wann er abläuft.

Wer auf Nummer sicher gehen will, richtet ein regelmäßiges Reporting über die Listen und ihre Auswirkungen auf den Mailflow ein. Eine native Exportmöglichkeit gibt es derzeit (August 2026) leider nicht. Es bleibt also nur die manuelle Durchsicht oder ein Skript über das PowerShell-Modul für Security & Compliance. Dafür braucht man die Rolle „Security Administrator“ oder „Security Reader“.

Ein kurzer PowerShell-Befehl zeigt alle Einträge auf einen Blick

# PowerShell 7, Module: ExchangeOnlineManagement (Connect-ExchangeOnline erforderlich)
Get-TenantAllowBlockListItems -ListType All | ft ListType, Entry, ExpirationDate, CreatedBy

So hat man in kurzer Zeit einen Überblick und findet gezielt Einträge, die bald ablaufen oder deren Herkunft zweifelhaft ist.

Ausnahmen gehören in die Allow/Block List und nicht in Transportregeln

Wer heute noch mit Transportregeln und SCL -1 arbeitet, riskiert weit mehr als ein paar False Positives. Für kontrollierte und nachvollziehbare Ausnahmen im Mailflow ist die Tenant Allow Block List das richtige Werkzeug. Weil jede Freigabe sichtbar ist, ein Ablaufdatum trägt und mit Spoof Intelligence zusammenspielt, erreicht man viel Sicherheit mit wenig Aufwand. Transportregeln mit SCL -1 sollten aus meiner Sicht endgültig verschwinden. Wer umstellt, behält den Überblick, steht in Sachen Compliance besser da und kann dem Incident-Management deutlich gelassener entgegensehen.

Mehr zu sicheren Mailflows und zur Absicherung von E-Mail-Umgebungen findet ihr im Beitrag SPF, DKIM & DMARC für Exchange Online: DNS richtig einrichten und in Microsofts Dokumentation dazu, wie die Allow/Block List funktioniert und verwaltet wird.