Warum landen Mails von vertrauenswürdigen Absendern im Junk-Ordner? Ursachen finden und Ausnahmen richtig setzen in Microsoft 365

Wie EOP/Defender Entscheidungen trifft: vom Eingang bis zur Zustellung

Exchange Online Protection (EOP) und Defender for Office 365 bewerten eingehende Nachrichten in einer gestuften Pipeline, bevor sie überhaupt das Benutzerpostfach erreichen. Die Kette beginnt bei der Verbindungsaufnahme und der IP-Reputation des sendenden Systems, führt über Authentifizierungsprüfungen (SPF, DKIM, DMARC, Composite Authentication) zu Inhalts- und Phishing-Analysen und endet in Richtlinienaktionen wie Zustellung in den Posteingang, Zustellung in den Junk-E-Mail-Ordner, Umleitung in die Quarantäne oder vollständiger Blockierung. Jede Stufe kann ein finales Verdict fällen, das nachgelagerte Komponenten nicht mehr aufheben.

Technisch betrachtet verarbeiten mehrere spezialisierte Engines dieselbe Nachricht, teilweise parallel: Verbindungsschutz und IP-Reputation, Anti-Spam-Filter, Anti-Phishing-Module, Spoof-Intelligenz, Bulk-/Marketing-Erkennung, Malware- und Sandbox-Analyse sowie Mandantenregeln (Transportregeln, Ausnahmelisten, Advanced Delivery). Trifft eine dieser Instanzen eine harte Einschätzung wie „High confidence phish“ oder „Malware“, folgt eine Schutzaktion mit hoher Priorität. Clientseitige Einstellungen wie Safe-Sender-Listen oder Posteingangsregeln werden erst berücksichtigt, wenn die Nachricht serverseitig zugelassen und in ein Postfach zugestellt wurde.

Das bedeutet konkret: Selbst wenn ein Absender im Unternehmen bekannt ist oder Anwender ihn lokal als „sicher“ markiert haben, kann die Nachricht bereits auf Transportebene als Spam, Phishing oder Spoof klassifiziert und in Quarantäne bzw. den Junk-Ordner verschoben werden. Diese Priorisierung ist bewusst streng ausgelegt, um Bedrohungen wie Account-Kompromittierungen, gezieltes Spear-Phishing, Business E-Mail Compromise (BEC) oder neuartige Kampagnen bereits vor der Benutzeroberfläche abzufangen.

Für die Praxis ist wichtig zu verstehen, dass einzelne Stufen unabhängig voneinander ansprechen können. Eine Mail kann beispielsweise aufgrund einer sauberen Authentifizierung SPF/DKIM/DMARC bestehen, trotzdem aber wegen verdächtiger URLs oder typischer Phishing-Muster mit einem hohen SCL bewertet werden. Umgekehrt kann eine technisch fehlerhafte Authentifizierung zur Verschärfung führen, obwohl der eigentliche Inhalt neutral wirkt. Nur die Kombination aller Signale erklärt das endgültige Verhalten.

• Verbindungsfilter: Prüfung der sendenden IP, HELO-/SMTP-Anomalien, Block-/Allow-Listen, RBL-Hits.
• Authentifizierung: SPF, DKIM, DMARC, Alignment-Prüfungen und Composite Authentication (compauth).
• Anti-Spam/Anti-Phishing: SCL/PCL, Spoof- und Impersonation-Erkennung, heuristische Inhaltsanalysen.
• Bulk-/Marketing-Erkennung: BCL (Bulk Complaint Level) und Erkennung kommerzieller, massenhaft versendeter Muster.
• Malware-/Sandbox-Prüfungen: Signaturbasierte Erkennung, Heuristik und dynamische Analyse in Safe Attachments.
• Nachgelagerte Aktionen: Quarantäne, Junk-Zustellung, Löschung, Verschärfung durch ZAP (Zero-Hour Auto Purge) und Richtlinienauswertungen.

Diese Kette wirkt auf alle Empfängertypen gleichermaßen: Benutzerpostfächer, geteilte Postfächer, Verteilergruppen, M365-Gruppen und auch Weiterleitungsziele. Eine Ausnahme, die lediglich ein einzelnes Postfach berücksichtigt, löst daher strukturelle Probleme nicht, wenn dieselbe Nachricht an mehrere Empfänger oder Gruppen adressiert wird.

Header lesen: SCL und AntiSpamReport zeigen die Ursache

Die verlässlichste Methode, die „entscheidende“ Komponente für eine Junk- oder Quarantäne-Einstufung zu identifizieren, ist der Blick in die vollständigen Kopfzeilen der betroffenen Nachricht. Erst dort werden alle technischen Signale sichtbar, die im normalen Outlook-Frontend verborgen bleiben. Der Zugriff erfolgt je nach Client leicht unterschiedlich.

• Outlook im Web: Nachricht öffnen > Weitere Aktionen (… ) > Nachrichtenquelle anzeigen.
• Outlook für Windows (klassisch): Nachricht öffnen > Datei > Eigenschaften > Feld Internetkopfzeilen.
• Neue Outlook-App / Outlook für Mac: Nachricht markieren > Kontextmenü > Nachrichtenquelle anzeigen (Bezeichnung kann je nach Version leicht abweichen).

Wichtige Felder sind unter anderem Authentication-Results (SPF/DKIM/DMARC/compauth), X-MS-Exchange-Organization-SCL (Spam Confidence Level) sowie die konsolidierten Berichte in X-Microsoft-Antispam bzw. X-Forefront-Antispam-Report mit Hinweisen wie BCL, PCL, SFV und CAT. Diese Felder zeigen, ob die Junk-Einstufung aus Inhalts- und Phishinganalyse, Bulk-Kategorisierung, Spoof-Intelligenz, IP-Reputation, DMARC-Richtlinien oder einem expliziten Allow/Block resultiert.

In der Praxis lohnt es sich, Header immer systematisch zu lesen und die wichtigsten Felder zu notieren. So lässt sich schnell erkennen, ob ein Problem generalisiert (z. B. falsche SPF-Konfiguration des Absenders) oder nur in Kombination mit bestimmten Empfängern, Transportregeln oder Mandantenrichtlinien auftritt. Gleichzeitig hilft die Dokumentation bei der späteren Kommunikation mit Security-Teams oder dem Absender selbst.

Praxis: Ein SCL von 5 oder höher erklärt in der Regel die Zustellung in den Junk-E-Mail-Ordner oder eine Quarantäne-Aktion. Ein hoher PCL-Wert weist auf eine Phishing-Bewertung hin, ein hoher BCL-Wert auf eine Massenmail- oder Marketing-Kategorisierung. Bei spf=fail und/oder dmarc=fail ist Spoof-Intelligenz ein naheliegender Kandidat. Diese Spuren genügen üblicherweise, um die auslösende Stufe zu identifizieren und gezielt anzusetzen – etwa durch Korrektur der Absenderkonfiguration, Anpassung der Anti-Spam-Richtlinie oder Einführung einer kontrollierten Ausnahme.

Erfahrene Administratoren ergänzen die Header-Analyse häufig durch einen Blick in die Nachrichtenablaufverfolgung (Message Trace) im Exchange Admin Center oder im Defender-Portal. Die dort gezeigten Events und Verdicts („Spam“, „Phish“, „Bulk“, „Malware“, „Transport Rule“) bestätigen die Header-Einschätzung und helfen, Einzelfälle von systematischen Problemen zu unterscheiden.

Warum Outlook-Safe-Sender nicht reichen

Safe-Sender-Listen in Outlook oder im Postfach sind mailboxlokale Präferenzen. Sie greifen erst, wenn der Server die Nachricht grundsätzlich akzeptiert und dem Postfach zugeordnet hat. Greifen serverseitige Aktionen wie Quarantäne, Löschung oder die Umleitung in den Junk-E-Mail-Ordner bereits im Transportweg, verpufft der Safe-Sender-Eintrag, weil die Nachricht den Client nie unter regulären Bedingungen erreicht.

• Server vor Client: Quarantäne, Löschung und Junk-Zustellung durch EOP/Defender-Policies passieren vor jeder Client-Regel oder Safe-Sender-Auswertung.
• Kein Override bei hohem Risiko: Weder Safe-Sender noch Posteingangsregeln heben Malware-Erkennung, High-Confidence-Phish-Verdikte oder ZAP-Aktionen auf.
• Identitätsbindung: Safe-Sender matchen primär die sichtbare Header-From-Adresse. Weichen Envelope-From (MAIL FROM), Return-Path oder die DKIM-signierende Domäne deutlich ab, dominieren serverseitige Prüfungen.
• Per-Mailbox begrenzt: Einträge gelten nur für das jeweilige Benutzerpostfach und helfen nicht für Verteiler, geteilte Postfächer oder andere Empfänger im Mandanten.
• Synchronisationslücken: Nur serverseitig gespeicherte Safe-Listen wirken konsistent. Ältere oder rein clientseitig gepflegte Listen ohne Synchronisation in die Mailbox-Einstellungen haben keinerlei Einfluss auf EOP.

Historisch gab es Konfigurationen, in denen Outlook-Safe-Sender per Synchronisation mit dem Exchange-Postfach abgeglichen wurden. Für die moderne EOP-/Defender-Architektur bleibt der Effekt dennoch begrenzt, weil die Schutzentscheidungen bewusst früh im Transportweg fallen. Ein Missverständnis entsteht häufig, wenn Anwender unterstellen, Safe-Sender sei eine Art globale Allow-Liste – tatsächlich handelt es sich nur um eine Präferenz für das Verhalten gegenüber bereits zugestellten Mails.

Konsequenz für Administratoren: Erlaubnisse müssen auf Serverebene modelliert werden – also in Anti-Spam- und Anti-Phishing-Policies, über dedizierte Ausnahmen wie Tenant Allow/Block List, Spoof-Intelligence-Einträge oder präzise Nachrichtenflussregeln. Nur dann wirken sie früh genug im Transportpfad, um die eigentliche Klassifikation zu beeinflussen.

Für die Kommunikation mit Anwendern lohnt sich eine klare Botschaft: Safe-Sender ist ein Komfortwerkzeug, kein Sicherheitsmechanismus. Die Abwehr von Phishing und Malware bleibt immer vorrangig und kann aus gutem Grund nicht durch individuelle Benutzerpräferenzen übersteuert werden.

Schneller Diagnosepfad bei Junk-Verdacht

Für wiederkehrende Fälle, in denen „legitime“ Nachrichten im Junk-E-Mail-Ordner landen, hilft ein standardisierter Diagnosepfad. Ziel ist, die verantwortliche Engine innerhalb weniger Minuten einzugrenzen und die passende Gegenmaßnahme auf Serverebene zu planen – statt reflexartig Safe-Sender-Einträge zu verteilen.

1) Kopfzeilen prüfen: SCL, PCL/BCL, SFV/CAT und Authentication-Results notieren. 2) Zuordnung: Hoher SCL → Inhalts-/Spamfilter; hoher PCL → Anti-Phish; hoher BCL → Bulk-/Marketing-Erkennung; Authentifizierung fehlgeschlagen → Spoof-/DMARC-Richtlinie oder fehlende Senderkonfiguration. 3) Zustellaktion verifizieren: In der angewendeten Anti-Spam- und Anti-Phish-Policy die Aktionen für „Spam“, „High confidence spam/phish“ und „Bulk“ vergleichen. 4) Überschneidungen ausschließen: Prüfen, ob Transportregeln SCL stempeln oder Sicherheitsprodukte von Drittanbietern Header modifizieren. 5) Gegenmaßnahme immer serverseitig planen, nicht über Outlook-Safe-Sender.

• Mindestens drei betroffene Originalmails sammeln, um Ausreißer von Mustern zu trennen.
• Headersätze vergleichen: Wiederkehrende Werte bei SCL, BCL, PCL, SFV und Authentication-Results identifizieren.
• In Defender/Exchange die verwendete Richtlinie (Anti-Spam, Anti-Phish, Transportregel) prüfen und mit den Headerwerten abgleichen.
• Falls ein Drittanbieter-Gateway beteiligt ist, den dortigen Spam-/Phish-Score und eventuelle Header-Manipulationen (z. B. SCL-Vorstempelung) nachvollziehen.
• Erst nach eindeutiger Zuordnung eine gezielte Ausnahme oder Richtlinienanpassung vornehmen – und deren Wirkung anhand neuer Header kontrollieren.

Unternehmen profitieren, wenn dieser Diagnosepfad als interner Standard beschrieben und im IT-Service verankert wird. So vermeiden Teams spontane, schwer nachvollziehbare Ausnahmen und behalten die Kontrolle über die Sicherheitslage ihres Mandanten.

SCL im Kontext: Schwellen, Wirkung, Ausnahmen

Der Spam Confidence Level (SCL) im Header X-MS-Exchange-Organization-SCL bleibt der schnellste Indikator für die Zustellentscheidung von Exchange Online Protection. Typische Werte bedeuten: -1 = Filter-Bypass (z. B. interne Zustellung, definierte Ausnahmen), 0–1 = kein Spam, 2–4 = leicht verdächtig, aber meist noch Zustellung in den Posteingang, 5–6 = Spam (Standardaktion: Junk), 8–9 = High Confidence Spam (häufig Quarantäne oder Junk gemäß Richtlinie). Steht SCL niedrig, aber die Mail landete dennoch im Junk-Ordner, deutet das auf clientseitige Regeln oder nachgelagerte Maßnahmen wie Zero-Hour Auto Purge (ZAP) hin; ein SCL ≥ 5 verweist auf eine serverseitige EOP-/Defender-Entscheidung.

Wichtig ist die Unterscheidung zwischen explizit gesetzten SCL-Werten durch Microsofts Filter und von Administratoren vorgenommenen Stempelungen per Transportregel. Letztere sind im Header oft durch zusätzliche Felder oder durch den Kontext erkennbar, etwa wenn bestimmte interne Prozesse pauschal mit SCL -1 versehen werden. Solche Regeln erhöhen die Verantwortung des Betreibers, weil sie den eingebauten Schutz partiell aushebeln können.

In streng regulierten Umgebungen empfiehlt es sich, interne Richtlinien zu definieren, ab welchem SCL-Wert welche Aktionen akzeptabel sind. So kann beispielsweise festgelegt werden, dass SCL 5–6 Mails in den Junk-Ordner verschiebt, während SCL 8–9 grundsätzlich in der Quarantäne landen müssen. Diese Klarheit erleichtert die Argumentation gegenüber Fachbereichen, wenn bestimmte Nachrichten bewusst nicht im Posteingang erscheinen sollen.

AntiSpamReport und SpamDiagnostic lesen

EOP/Defender schreiben Detailinformationen in die Header X-Forefront-Antispam-Report und X-Microsoft-Antispam. Besonders wichtig ist das Feld SFV (Spam Filter Verdict) mit typischen Werten NSPM (nicht Spam), SPM (Spam), SKI (Skip: intern), SKA (Skip: Allow), SKS (Skip: Safe Sender). Diese Werte zeigen, ob der eigentliche Spamfilter aktiv entschieden oder einen Bypass angewendet hat.

SpamDiagnosticOutput und SpamDiagnosticMetadata beschreiben interne Auslöser, etwa Phishing-Indikatoren, URL-Reputation, Anomalien im Header-Aufbau oder bekannte Kampagnenmuster. Auch wenn die Werte nicht vollständig dokumentiert sind, lässt sich anhand typischer Schlagworte (z. B. Phish, Bulk, URL, Spoof) gut erkennen, welcher Teil des Filterstacks die Entscheidung beeinflusst hat. So unterscheiden Administratoren sauber zwischen Inhalts-/Phishing-Erkennung, Spoofing und einer reinen Massenmail-Bewertung.

Der BCL (Bulk Complaint Level, 0–9) bewertet den Massencharakter einer Nachricht. Je höher der Wert, desto stärker spricht die Engine von einer Marketing- oder Bulk-Mail. Liegt der BCL über dem in der Anti-Spam-Richtlinie gesetzten Bulk-Schwellenwert, wird die Nachricht entsprechend der Bulk-Aktion behandelt – häufig Zustellung in den Junk-Ordner, selbst wenn SPF, DKIM und DMARC korrekt konfiguriert sind. Gerade Newsletter und legitime Serienmails sind hiervon betroffen.

Für Absender, die wiederholt fälschlich als Bulk klassifiziert werden, lohnt sich eine enge Abstimmung: Anpassung der Versandfrequenz, klarere Abmeldemöglichkeiten, konsistente Absenderdomänen und saubere Authentifizierung senken den BCL-Wert oft deutlich. In Ausnahmefällen kann eine serverseitige Allow-Konfiguration sinnvoll sein, sollte aber immer bewusst gegen das Risiko einer Aufweichung der Bulk-Erkennung abgewogen werden.

Authentication-Results und ARC korrekt einordnen

Im Header Authentication-Results finden sich mindestens die Felder spf=pass/fail, dkim=pass/fail, dmarc=pass/fail sowie das Microsoft-Signal compauth=pass/softpass/fail (Composite Authentication). compauth=fail in Kombination mit dmarc=fail oder fehlenden Signaturen weist häufig auf Spoofing oder eine problematische Absenderkonfiguration hin und führt zu einer schärferen Phish-/Spam-Bewertung mit erhöhtem SCL.

Bei Weiterleitungen scheitert SPF technisch zwangsläufig, weil der Weiterleitungsserver die ursprüngliche Absender-IP nicht kontrolliert. Hier kommt ARC (Authenticated Received Chain) ins Spiel: ARC-Seal enthält das Feld cv=pass|fail|none, das die Vertrauenswürdigkeit der Authentifizierungskette beschreibt. Ein cv=pass mit plausiblen ARC-Authentication-Results kann SPF-Fails entwerten und verhindert unnötige Spam-Einstufungen bei legitimen Weiterleitern, sofern der Mandant ARC korrekt auswertet.

In der Praxis sollten Administratoren bei Problemen mit Weiterleitern prüfen, ob diese ARC unterstützen und ob die eigenen Richtlinien ARC als Vertrauenssignal berücksichtigen. Andernfalls drohen false positives bei Newslettern, Mailinglisten oder externen Gateways, die Nachrichten weiterreichen. Wo ARC nicht verfügbar ist, helfen gezielte Ausnahmen, etwa für bestimmte Weiterleitungs-IP-Adressen oder Domänen, in Kombination mit TLS- und Authentifizierungsanforderungen.

Schneller Arbeitsablauf: Verursacher identifizieren

• Header extrahieren und SCL prüfen. SCL ≥ 5 = serverseitige Einstufung; SCL -1 = Bypass/Ausnahme; SCL 0–1 = keine serverseitige Spam-Einstufung.
• In X-Microsoft-Antispam/X-Forefront-Antispam-Report das Feld SFV lesen: SPM = Spam, NSPM = kein Spam, SK* = Filter übersprungen (intern, Allow, Safe Sender).
• Authentication-Results prüfen: compauth, dmarc, dkim, spf. Bei compauth=fail ist meist der Anti-Spoofing-/Phish-Stack der Auslöser.
• ARC bewerten: cv=pass kann SPF-Fails legitimer Weiterleitungen neutralisieren; cv=fail erklärt harte Einstufungen trotz korrektem Inhalt.
• BCL mit der in der Anti-Spam-Richtlinie konfigurierten Bulk-Schwelle vergleichen, um Massensendungen vom Inhalts-/Phish-Stack abzugrenzen.
• SpamDiagnosticOutput/-Metadata lesen, um die konkrete Komponente (Phish, URL-Reputation, Anomalie, Bulk) zuzuordnen.

Wer diesen Ablauf konsequent befolgt, reduziert die Analysezeit pro Fall deutlich. Viele Mandantenprobleme lassen sich auf wenige, immer wiederkehrende Muster zurückführen – etwa eine zu aggressive Bulk-Konfiguration, fehlendes DMARC-Alignment bei Dienstleistern oder großzügig eingesetzte Transportregeln mit SCL -1. Eine dokumentierte Zuordnung erleichtert auch spätere Audits und dient als Argumentationsgrundlage gegenüber Compliance und Revision.

Praxisleitfaden: typische Header-Muster und Zuordnung

Entscheidend ist stets die Kombination der Signale: Ein hoher BCL bei gleichzeitigem NSPM weist eher auf eine massenhaft versendete, aber inhaltlich neutrale Aussendung hin, während SPM plus compauth=fail klar in Richtung Spoofing oder Phishing zeigt. Ein SCL von -1 zusammen mit SFV:SKA bestätigt eine serverseitige Allow-Regel – clientseitige Safe-Sender-Listen hingegen erzeugen keinen SCL-Bypass.

Wer diese Muster regelmäßig dokumentiert, baut über die Zeit ein internes Nachschlagewerk auf. Dadurch sinkt die Abhängigkeit von Trial-and-Error-Konfigurationen, und Ausnahmen lassen sich mit deutlich mehr Augenmaß und Nachvollziehbarkeit einführen oder wieder entfernen.

Safe-Sender auf Tenant-Ebene: Tenant Allow/Block List richtig verwenden

Die zuverlässigste serverseitige Ausnahme für vertrauenswürdige Absender auf Mandantenebene ist die Tenant Allow/Block List (TABL) im Microsoft 365 Defender-Portal. Sie greift früh im Transportpfad, noch bevor individuelle Postfacheinstellungen oder Outlook-Regeln zum Tragen kommen, und gilt tenantweit für alle Empfänger.

Vorgehen (Stand 2025): security.microsoft.com > E-Mail & Zusammenarbeit > Richtlinien & Regeln > Bedrohungsrichtlinien > Tenant Allow/Block List > Domains & Adressen > Zulassen > Eintrag hinzufügen.

• Typ wählen: Domäne (z. B. partner.example.com) oder E-Mail-Adresse (z. B. rechnung@dienstleister.de). Optional Subdomänen einschließen.
• Gültigkeit festlegen: Dauerhaft oder Ablaufdatum setzen (Standard sind häufig 30 Tage; für dauerhafte Partnerschaften bewusst anpassen).
• Begründung und Notiz dokumentieren (z. B. Ticketnummer, Ansprechpartner, Zweck), um Revisionssicherheit und Nachvollziehbarkeit sicherzustellen.

Die Wirkung: TABL-Allows setzen sich in vielen Fällen gegen die Standardentscheidungen von Anti-Spam- und Anti-Phishing-Erkennungen durch. Sie umgehen jedoch niemals Malware-Erkennung, Safe Attachments (Sandbox-Analyse) oder Safe Links. Ebenso bleiben DLP-Richtlinien, Transportregeln und Compliance-Vorgaben wirksam. Ausnahmen über TABL sind deshalb wirksam, aber nicht vollständig „gefährlich“ – sie verlangen trotzdem ein bewusstes Risikomanagement.

Empfehlenswert ist, TABL-Allows auf wenige, gut geprüfte Partner zu beschränken und sie regelmäßig zu überprüfen. Für breit gestreute Newsletter oder unscharf definierte Absender ist TABL ungeeignet, weil sie den globalen Schutz des Mandanten zu stark aufweicht.

Spoof-Intelligence gezielt einsetzen statt ganze Domänen zu erlauben

Legitime Drittanbieter versenden häufig im Namen der eigenen Domäne eines Kunden, etwa für Newsletter, ERP-Benachrichtigungen oder Support-Tickets. Wenn DMARC-Alignment fehlt oder falsch konfiguriert ist, löst dies Spoofing-Detektionen aus. Statt die gesamte Domäne pauschal zu erlauben – was auch Angreifern helfen kann – bietet sich eine gezielte Nutzung der Spoof-Intelligence an.

Vorgehen: security.microsoft.com > E-Mail & Zusammenarbeit > Richtlinien & Regeln > Bedrohungsrichtlinien > Tenant Allow/Block List > Spoofing > Zulassen > Eintrag hinzufügen. Dort die gespoofte Domäne bzw. den Benutzer und die sendende Infrastruktur (Domäne oder IP des Dienstes) eintragen. Auf diese Weise erlauben Sie nur die legitime Kombination aus „From-Domäne“ und sendender Plattform – nicht jeden beliebigen Absender, der diese Domäne missbraucht.

Parallel sollten Sie prüfen, ob der Dienst SPF und DKIM für Ihre Domäne unterstützt. Sobald ein sauberes DMARC-Alignment hergestellt ist, kann die Spoof-Erlaubnis entfallen. So bleiben Ausnahmen temporär und das langfristige Sicherheitsniveau hoch.

In vielen Organisationen hat es sich bewährt, Spoof-Allows mit einer internen Freigabe zu koppeln: Ohne Nachweis über den Dienstleistervertrag und die technische Dokumentation des Versandanbieters erfolgt keine Eintragung. Das reduziert das Risiko, dass „aus Bequemlichkeit“ großflächige Ausnahmen geschaffen werden, die später niemand mehr zuordnet.

Nachrichtenflussregeln: präzise Ausnahmen per SCL -1 und Header-Bedingungen

Wenn Sie den Schutz für bestimmte Szenarien sehr granular steuern müssen, bieten sich Nachrichtenflussregeln (Exchange Transport Rules, ETR) im Exchange Admin Center an. Sie können Bedingungen auf Basis von Header-Feldern, Absendern, IP-Adressen, TLS-Status oder benutzerdefinierten Markern definieren und gezielt auf die Spamvertrauensstufe (SCL) einwirken.

• Neue Regel erstellen: Bedingung wie „Nachrichtenkopf Authentication-Results enthält dkim=pass header.d=beispiel.de“ oder „Absender-IP entspricht Liste vertrauenswürdiger Systeme“.
• Aktion definieren: „Spamvertrauensstufe (SCL) auf -1 festlegen“, um den Spamfilter zu umgehen (Malware- und ATP-Schutz bleibt aktiv).
• Optional: Geltungsbereich einschränken – nur für bestimmte Empfänger, nur über definierte Connectoren, nur bei erzwungenem TLS oder für bestimmte interne Organisationseinheiten.
• Regelpriorität hoch setzen, Audit-Logging aktivieren und den Änderungsgrund im Kommentar dokumentieren (z. B. Ticketnummer, Freigabevermerk).

Wichtig: SCL -1 verhindert Junk-Zustellung, stoppt aber keine Malware-Erkennung oder andere Richtlinienaktionen. Gerade deswegen eignen sich Transportregeln gut, um z. B. sauber authentifizierte Systemmails (Monitoring, ERP, Ticketsysteme) von der Spamklassifikation auszunehmen, ohne die eigentliche Bedrohungserkennung zu deaktivieren.

Für Impersonation-Fälle sollten Sie zusätzlich in der Anti-Phishing-Richtlinie „Vertraute Absender und Domänen“ pflegen. Nur so verhindern Sie, dass die Imitationsprüfung bekannte Partner- oder Managementadressen trotz gültiger Authentifizierung als Risiko markiert. Die Kombination aus Transportregel (SCL -1) und Anti-Phish-Whitelist erfordert besondere Sorgfalt und ein klares Change-Management.

Advanced Delivery: Phishing-Simulationen und SecOps-Postfächer sicher zustellen

Für Trainings- und Analyse-Szenarien – etwa Phishing-Simulationen oder dedizierte Security-Postfächer – reicht eine klassische Allow-Liste oft nicht aus oder wäre sicherheitlich nicht vertretbar. Hier bietet Advanced Delivery im Defender-Portal definierte Ausnahmepfade, die sehr gezielt für bestimmte Quellen und Ziele gelten.

• Pfad: security.microsoft.com > E-Mail & Zusammenarbeit > Richtlinien & Regeln > Bedrohungsrichtlinien > Advanced Delivery.
• Phishing-Simulation: Sende-IP(s), Absenderdomäne(n)/MAIL FROM und verwendete Simulations-URLs eintragen. Nur die konfigurierten Kombinationen werden durchgelassen, die übrigen Schutzmechanismen bleiben für alle anderen Quellen aktiv.
• SecOps-Postfächer: Zielpostfächer definieren und die autorisierten Quellen (IPs/Domänen) hinterlegen, die dorthin auch verdächtige Inhalte liefern dürfen – etwa eingereichte Phishing-Beispiele oder Rohdaten für forensische Analysen.

Advanced Delivery gilt ausschließlich für die angegebenen Szenarien. Safe Links und Safe Attachments bleiben aktiv, Malware wird weiterhin blockiert. Damit lässt sich ein realistisches Bild von Phishing-Simulationen erzeugen, ohne produktive Schutzmechanismen für alle Nutzer zu schwächen.

Vor dem Einsatz sollte klar dokumentiert werden, welche Teams Advanced-Delivery-Szenarien betreiben, welche Ziele verfolgt werden und wie lange die Konfiguration aktiv bleibt. Nach Abschluss von Kampagnen empfiehlt es sich, nicht mehr benötigte Einträge zu entfernen, um die Angriffsfläche klein zu halten.

Typische Fallen vermeiden

• Outlook-Safe-Sender wirken nicht serverseitig. Ausnahmen müssen in TABL, Anti-Spam-/Anti-Phish-Policies oder Transportregeln modelliert werden.
• Falsche Domäne erlaubt: Entscheidend ist oft die P1-Identität (MAIL FROM/Return-Path) oder die gespoofte P2-From-Domäne. Vor einem Allow-Eintrag Header sorgfältig analysieren.
• Wildcard-Erwartung: Teil-Wildcards sind nicht zulässig; Subdomänen müssen bei Bedarf explizit aktiviert werden.
• Ablaufdatum übersehen: Standard-Allows verfallen häufig automatisch. Für dauerhafte Partner explizit „unbefristet“ setzen oder Wiedervorlagen über das interne Change-Management abbilden.
• Regelüberschneidungen: SCL -1 kann von Malware-/ATP-Entscheidungen überstimmt werden. Erwartungsmanagement gegenüber Fachbereichen und klare Dokumentation sind Pflicht.
• Impersonation greift trotz Allow: Kritische Absender zusätzlich in der Anti-Phishing-Richtlinie unter „Vertraute Absender und Domänen“ hinterlegen.
• Drittanbieter-Gateway: SPF, DKIM und DMARC auf der Quelle korrekt konfigurieren und Connectoren (TLS, Zertifikat, IP-Bindung) sauber absichern – statt großflächiger IP-Allows.

Gerade in hybriden Umgebungen oder bei historisch gewachsenen Gateways lohnt ein einmaliger Architektur-Review. Viele „spontane“ Ausnahmen aus vergangen Jahren sind heute nicht mehr nötig, verschleiern aber Ursachen und erhöhen die Angriffsfläche des Mandanten.

Best Practices für stabile Ausnahmen

• „Auth first“: SPF, DKIM und DMARC-Alignment priorisieren. Ausnahmen dienen nur als Ergänzung und möglichst temporär, nicht als Ersatz für saubere Absenderkonfigurationen.
• Least Privilege: Ausnahmen so eng wie möglich fassen – lieber ein Spoof-Paar oder eine DKIM-gebundene ETR-Regel statt eine komplette Domäne pauschal freizugeben.
• Lifecycle pflegen: Ablaufdaten, Eigentümer, fachlicher Grund und betroffene Empfänger dokumentieren und in regelmäßigen Abständen überprüfen.
• Monitoring etablieren: Transportprotokolle, Quarantäne und Header-Signale (SCL, X-Forefront-Antispam-Report, Authentication-Results) nach Änderungen gezielt beobachten.
• Change Control: Kritische Änderungen an TABL, ETRs, Advanced-Delivery-Konfigurationen nur mit Vier-Augen-Prinzip und Ticketreferenz durchführen.
• Dokumentierte Playbooks: Für wiederkehrende Szenarien (z. B. neuer Newsletter-Dienstleister, neues Ticketsystem, neuer Phishing-Simulationsanbieter) standardisierte Vorgehensweisen definieren.

Auf diese Weise entsteht eine robuste Balance: EOP und Defender for Office 365 bleiben als zentrale Schutzschicht wirksam, während berechtigte Kommunikationskanäle kontrolliert freigeschaltet werden. Junk-Einstufungen legitimer Absender lassen sich so systematisch reduzieren, ohne die Sicherheit des Mandanten zu kompromittieren.