Falsch konfiguriertes E-Mail-Routing: Microsofts Warnung vor internem Spoofing (Januar 2026)

⚡TL;DR

• Microsoft hat im Januar 2026 aufgedeckt, dass MX-Konfigurationen, die auf Drittanbieter-Dienste zeigen (Anti-Spam-Gateways, Archivierungslösungen), einen blinden Fleck erzeugen, den Angreifer zum Spoofen interner Domains ausnutzen
• Die Tycoon2FA-Plattform verursachte in einem einzigen Monat (Oktober 2025) 13 Millionen von Defender blockierte Phishing-E-Mails, indem sie diesen Vektor in Kombination mit AiTM-Angriffen ausnutzte
• Das Trio SPF ~all + fehlendes DKIM + DMARC p=none lässt 100 % der Spoofing-Versuche über indirektes MX-Routing durch
• Die forensische Analyse der E-Mail-Header enthüllt den genauen Mechanismus: unerwartete Sprünge in der Received-Kette, spf=softfail, dkim=none, dmarc=fail action=none
• Der 5-Schritte-Korrekturplan: progressives DMARC bis p=reject, SPF -all, DKIM aktiviert, Drittanbieter-Konnektoren auditiert, direktes MX zu Microsoft 365

Im Januar 2026 hat das Team von Microsoft Defender for Office 365 eine Warnung veröffentlicht, die Sicherheitsteams aufschreckte: Tausende Organisationen, die Microsoft 365 nutzen, waren anfällig für internes Identitäts-Spoofing, nicht wegen eines Softwarefehlers, sondern wegen ihrer eigenen DNS-Konfiguration. Der Mechanismus ist einfach und verheerend. Wenn der MX-Eintrag einer Domain auf einen Drittanbieter-Dienst zeigt (Anti-Spam-Gateway, Archivierungslösung, Filter-Relay) statt direkt auf Microsoft 365, durchlaufen eingehende E-Mails einen Vermittler, der die Authentifizierungsergebnisse von SPF, DKIM und DMARC nicht korrekt neu berechnet. Angreifer haben das verstanden und nutzen diese Schwachstelle im großen Stil aus.

Das ist kein theoretisches Szenario. Microsoft hat dokumentiert, dass die Phishing-as-a-Service-Plattform Tycoon2FA allein im Oktober 2025 13 Millionen bösartige E-Mails verursachte, die von Defender blockiert wurden. Diese E-Mails nutzten indirektes MX-Routing in Kombination mit Adversary-in-the-Middle-Techniken (AiTM), um Zugangsdaten und Session-Cookies zu stehlen, selbst bei Nutzern mit Multi-Faktor-Authentifizierung. Die Köder imitierten Passwort-Zurücksetzungen, HR-Nachrichten und Benachrichtigungen über geteilte Dokumente, gesendet von der internen Adresse des Opfers an sich selbst.

Dieser Artikel beschreibt den technischen Mechanismus hinter diesem Angriff, die forensische E-Mail-Header-Analyse zu seiner Erkennung, eine Fünf-Minuten-DNS-Diagnose, um festzustellen, ob deine Domain anfällig ist, und einen vollständigen Korrekturplan.

Der Kontext: Was enthüllt Microsofts Warnung vom Januar 2026?

Ein Routing-Problem, kein Protokoll-Problem

Microsofts Warnung betrifft keine Schwachstelle in SPF, DKIM oder DMARC selbst. Diese Protokolle funktionieren genau wie vorgesehen. Das Problem liegt in der E-Mail-Routing-Architektur.

In einer Standardkonfiguration zeigt der MX-Eintrag einer Domain direkt auf die Exchange Online Protection (EOP) Server von Microsoft 365:

captaindns.com.  IN  MX  10  captaindns-com.mail.protection.outlook.com.

Mit dieser Konfiguration empfängt Microsoft 365 E-Mails direkt vom Absender. Es prüft SPF, indem es die Quell-IP gegen den SPF-Eintrag der Envelope-Domain verifiziert. Es validiert die DKIM-Signatur. Es wendet die DMARC-Richtlinie an. Jede Prüfung findet im korrekten Kontext statt.

Aber Tausende Organisationen haben einen MX-Eintrag, der auf einen Drittanbieter-Dienst zeigt:

captaindns.com.  IN  MX  10  mx.filtrage-tiers.com.

Der Drittanbieter-Dienst empfängt die E-Mail, führt seine Verarbeitung durch (Anti-Spam, Archivierung, Inhaltsanalyse) und leitet die Nachricht dann an Microsoft 365 weiter. Das Problem: Wenn Microsoft 365 die Nachricht empfängt, gehört die Quell-IP zum Drittanbieter-Dienst, nicht zum ursprünglichen Absender. Der Authentifizierungskontext hat sich geändert.

Der Angriffsmechanismus im Detail

Der Angreifer nutzt diese Kette folgendermaßen aus:

Schritt 1: Aufklärung. Der Angreifer fragt den MX-Eintrag der Zieldomain ab. Wenn der MX auf einen Drittanbieter-Dienst statt auf *.mail.protection.outlook.com zeigt, ist die Domain potenziell anfällig.

Schritt 2: Prüfung der Authentifizierungslage. Der Angreifer prüft drei DNS-Einträge:

• _dmarc.captaindns.com: Wenn die Richtlinie p=none ist, lösen DMARC-Fehler keine Aktion aus
• captaindns.com (SPF TXT): Wenn der Mechanismus ~all (Softfail) statt -all (Hardfail) ist, wird ein SPF-Fehler toleriert
• Gängige DKIM-Selektoren: Wenn kein DKIM-Schlüssel veröffentlicht ist, löst das Feld dkim=none nichts aus

Schritt 3: Versand der gefälschten E-Mail. Der Angreifer sendet eine E-Mail von einem Server, den er kontrolliert. Er setzt dieselbe Adresse in die Felder From und To: zum Beispiel buchhaltung@captaindns.com an buchhaltung@captaindns.com. Dieses "Self-Spoofing" erweckt den Eindruck, die Nachricht käme von einem internen Kollegen.

Schritt 4: Transit über den Drittanbieter-Dienst. Der MX der Domain leitet die E-Mail an den Drittanbieter-Dienst weiter. Dieser führt eine erste Filterstufe durch. Das Problem: Viele Drittanbieter-Dienste prüfen SPF/DKIM/DMARC überhaupt nicht, oder sie prüfen sie, propagieren die Ergebnisse aber nicht so, dass Microsoft 365 sie verwerten kann.

Schritt 5: Zustellung in Microsoft 365. Microsoft 365 empfängt die E-Mail von der IP des Drittanbieter-Dienstes. Ohne Enhanced Filtering for Connectors (EFC) sieht Exchange Online die IP des Drittanbieters, nicht die IP des Angreifers. SPF besteht (weil die IP des Drittanbieters im SPF des Drittanbieters ist) oder schlägt als Softfail fehl. DKIM fehlt. DMARC schlägt fehl, aber die Richtlinie p=none löst keine Blockierung aus. Die E-Mail landet im Posteingang.

Warum "Skip Authentication" der Bruchpunkt ist

Das grundlegende Problem ist die Konfiguration des eingehenden Konnektors in Exchange Online. Wenn eine Organisation einen Konnektor für den E-Mail-Empfang von einem Drittanbieter-Dienst konfiguriert (Barracuda, Mimecast, Proofpoint, Sophos), bietet der Konfigurationsassistent oft an, den Authentifizierungsergebnissen des Drittanbieters zu "vertrauen" oder die "Authentifizierung zu überspringen" für die IPs des Konnektors. In der Praxis aktivieren viele Administratoren diese Option, um False Positives zu vermeiden: Wenn der Drittanbieter bereits SPF/DKIM/DMARC geprüft hat, warum noch einmal prüfen?

Das Problem: Exchange Online verifiziert dann die Authentifizierung nicht mehr gegen die Originalquelle. Es konsumiert die vom Drittanbieter eingefügten Authentication-Results-Header oder, schlimmer noch, wertet SPF auf der Konnektor-IP (die des Drittanbieters) statt auf der IP des echten Absenders aus. Der im Posteingang sichtbare Authentication-Results-Header spiegelt die Ergebnisse des Drittanbieters wider, nicht die der tatsächlichen Quelle.

Microsoft hat Enhanced Filtering for Connectors (EFC) eingeführt, um dieses Problem zu beheben. EFC weist Exchange Online an, die Received-Kette nach oben zu durchlaufen, um die IP des ursprünglichen Absenders zu identifizieren, wobei die bekannten IPs des Drittanbieter-Dienstes übersprungen werden (die "Skip List"). Aber EFC ist standardmäßig nicht aktiviert. Organisationen, die EFC nicht konfiguriert haben oder es mit einer unvollständigen Skip List konfiguriert haben, bleiben anfällig.

Self-Spoofing: Die interne E-Mail, die keine ist

Der entscheidende Schlag dieses Angriffs ist das Self-Spoofing. Der Angreifer setzt dieselbe Domain in die Felder From und To: hr@captaindns.com sendet an max.mueller@captaindns.com. Für den Empfänger scheint die E-Mail von einem Kollegen zu stammen. Aber der Mechanismus ist noch heimtückischer: Viele Organisationen konfigurieren Exchange-Transportregeln, die "interne" E-Mails anders behandeln. Eine E-Mail, deren From-Domain eine interne Domain ist, erhält möglicherweise nicht den Banner "Diese E-Mail stammt von einem externen Absender", unterliegt möglicherweise nicht denselben Anti-Phishing-Filtern und wird ohne visuelle Warnung angezeigt. Der Angreifer nutzt nicht nur das menschliche Vertrauen aus, sondern auch die Sicherheitsausnahmen, die für interne Kommunikation konfiguriert wurden.

Die kritische Rolle des Drittanbieter-Dienstes

Das zentrale Problem ist, dass der Drittanbieter-Dienst als unfreiwilliger Authentifizierungs-"Wäscher" agiert. Wenn er die Nachricht an Microsoft 365 weiterleitet, ersetzt er den ursprünglichen Authentifizierungskontext:

• Die Quell-IP ändert sich. Microsoft 365 sieht die IP des Drittanbieter-Dienstes, nicht die des Angreifers. Die SPF-Prüfung erfolgt gegen die falsche IP.
• Die Authentication-Results-Header des Drittanbieters sind nicht vertrauenswürdig. Microsoft 365 hat keinen Grund, den vom Drittanbieter eingefügten Authentifizierungsergebnissen zu vertrauen.
• Der Return-Path kann umgeschrieben werden. Manche Drittanbieter-Dienste schreiben den SMTP-Envelope um und verwischen so die Spuren weiter.

Microsoft hat dokumentiert, dass selbst Drittanbieter-Dienste, die SPF/DKIM/DMARC korrekt prüfen und die richtigen Header einfügen, das Problem nicht lösen, wenn Microsoft 365 nicht weiß, dass es über die IP des Drittanbieters hinausschauen muss, um die IP des ursprünglichen Absenders zu finden.

Genau dieses Problem löst Enhanced Filtering for Connectors: Es ermöglicht Exchange Online, die IP des Drittanbieters in der Received-Kette zu "überspringen" und die Authentifizierung gegen die echte IP des Absenders auszuwerten.

Wie groß ist das Problem?

Indirektes MX-Routing ist keine Randkonfiguration. Laut den von Microsofts Sicherheitsteams veröffentlichten Daten nutzt ein erheblicher Anteil der Microsoft 365-Tenants einen Drittanbieter-Dienst vor Exchange Online. Die Gründe sind vielfältig und oft historisch bedingt:

• Migrationserbe: Viele Organisationen sind von einem On-Premises-Hosting zu Microsoft 365 migriert. Sie hatten bereits einen Drittanbieter-Anti-Spam-Dienst (Barracuda, Mimecast, Proofpoint, Sophos) und haben das bestehende Routing bei der Migration beibehalten.
• Regulatorische Anforderungen: Bestimmte Branchen (Finanzen, Gesundheitswesen, Verwaltung) schreiben eine E-Mail-Archivierung oder -Filterung durch einen zertifizierten Drittanbieter-Dienst vor. Indirektes MX-Routing ist der übliche technische Weg, um diese Anforderung zu erfüllen.
• Defense-in-Depth-Strategie: Manche Sicherheitsteams glauben, dass zwei Filterschichten übereinander (Drittanbieter + Defender) besseren Schutz bieten. Das stimmt für die Anti-Spam-Filterung, aber die Kosten in Bezug auf die Authentifizierung werden selten gemessen.
• Unkenntnis des Risikos: Vor der Warnung vom Januar 2026 war der Zusammenhang zwischen indirektem MX-Routing und geschwächter E-Mail-Authentifizierung nicht breit dokumentiert. Die meisten Bereitstellungsanleitungen der Drittanbieter-Dienste erwähnen die Auswirkungen auf SPF/DKIM/DMARC auf der Microsoft 365-Seite nicht.

Das Ergebnis: Organisationen, die in E-Mail-Sicherheit investieren (Kauf eines Premium-Anti-Spam-Dienstes, DMARC-Deployment), sind paradoxerweise anfälliger als solche, die ausschließlich Defender mit direktem MX nutzen.

Tycoon2FA: Die PhaaS-Plattform, die diese Schwachstelle ausnutzt

Ein schlüsselfertiger Phishing-Dienst

Tycoon2FA ist eine Phishing-as-a-Service-Plattform (PhaaS), die seit August 2023 aktiv ist und von Sekoia.io und dem Microsoft Threat Intelligence Center identifiziert und dokumentiert wurde. Sie funktioniert wie ein SaaS für Cyberkriminelle: Betreiber zahlen ein Abonnement (etwa 120 Dollar pro Monat über dedizierte Telegram-Kanäle) und erhalten eine komplette Phishing-Infrastruktur mit Dashboards, E-Mail-Vorlagen, geklonten Anmeldeseiten und automatisierter Credential-Erfassung. Die Einstiegshürde ist praktisch null: Keine technischen Kenntnisse sind erforderlich, das Kit liefert alles, von der Phishing-Domain bis zur Sammelseite.

Das Ausmaß der Operation ist massiv. Laut konsolidierten Schätzungen der Threat-Intelligence-Teams von Microsoft und Sekoia.io generiert Tycoon2FA über 30 Millionen Phishing-E-Mails pro Monat über alle Betreiber hinweg. Microsoft berichtete, im ersten Halbjahr 2025 62 % der Phishing-E-Mails, die auf seine Nutzer abzielten, blockiert zu haben, aber das verbleibende Volumen reicht aus, um Tausende Konten zu kompromittieren. Im März 2026 versuchte Europol, die Infrastruktur von Tycoon2FA in einer koordinierten Operation zu zerschlagen. Die Plattform war innerhalb von 48 Stunden wieder betriebsbereit, nachdem sie ihre Server in neue Jurisdiktionen migriert hatte.

Was Tycoon2FA von konventionellen Phishing-Kits unterscheidet, ist die Fähigkeit, Multi-Faktor-Authentifizierung (MFA) durch eine Adversary-in-the-Middle-Technik (AiTM) zu umgehen.

Der AiTM-Mechanismus im Detail

Die technische Funktionsweise basiert auf einem transparenten Reverse Proxy. Der entscheidende Punkt: MFA schützt nicht vor diesem Angriff, weil der Proxy nicht den zweiten Faktor selbst abfängt. Er fängt das Session-Cookie ab, das Microsoft 365 ausstellt, nachdem der Nutzer die gesamte Authentifizierungskette erfolgreich abgeschlossen hat, MFA eingeschlossen. Das Opfer authentifiziert sich normal, gegen die echte Microsoft-Infrastruktur, aber das Session-Token wird im Transit abgefangen.

Hier ist der vollständige Ablauf:

1. Das Opfer empfängt eine Phishing-E-Mail, die eine interne Domain über den oben beschriebenen MX-Routing-Mechanismus spooft.
2. Der Link in der E-Mail durchläuft eine Weiterleitungskette. Microsoft hat die Nutzung von Weiterleitungen über Google Maps (maps.google.com/url?q=...) dokumentiert, um Reputationsfilter zu umgehen. Die Technik ist wirkungsvoll: E-Mail-Filter prüfen die Link-Domain, sehen maps.google.com (eine vertrauenswürdige Domain mit maximaler Reputation) und lassen sie durch. Der q=-Parameter enthält die tatsächliche URL der Phishing-Seite, aber Filter dekodieren verschachtelte Weiterleitungen nicht systematisch. Die finale URL führt zu einer Phishing-Seite auf einer kurzlebigen Domain.
3. Die Phishing-Seite agiert als transparenter Proxy zur echten Microsoft 365-Anmeldeseite. Der Tycoon2FA-Server sitzt zwischen dem Browser des Opfers und login.microsoftonline.com. Visuell sieht das Opfer eine Anmeldeschnittstelle, die identisch mit der von Microsoft ist, mit dem Organisationslogo, den benutzerdefinierten Farben und dem Entra ID-Branding.
4. Das Opfer gibt Benutzername und Passwort ein. Der Proxy leitet die Zugangsdaten in Echtzeit an Microsoft 365 weiter. Microsoft validiert sie normal.
5. Microsoft 365 fordert den zweiten Faktor (MFA). Der Proxy leitet die MFA-Anforderung an das Opfer weiter. Das Opfer gibt seinen TOTP-Code ein oder bestätigt die Push-Benachrichtigung. Aus Microsofts Sicht ist die Authentifizierung legitim.
6. Der Proxy fängt das Session-Cookie ab. Sobald die Authentifizierung abgeschlossen ist, stellt Microsoft 365 ein Session-Cookie aus. Der Proxy fängt es ab, bevor er es an das Opfer weiterleitet. Das Opfer erhält ein gültiges Cookie und greift normal auf sein Postfach zu, ohne etwas zu ahnen.
7. Der Angreifer verwendet das gestohlene Session-Cookie, um von einem anderen Browser auf das Konto zuzugreifen, ohne MFA erneut durchlaufen zu müssen. Das Cookie ist für die Dauer der Sitzung gültig (oft 24 Stunden oder mehr, abhängig von der Organisationsrichtlinie). Der Angreifer kann E-Mails lesen, OneDrive-Dateien exfiltrieren, E-Mails im Namen des Opfers senden und sich lateral in der Organisation ausbreiten.

Von Microsoft dokumentierte Zahlen

Die von Microsoft in seinem Bulletin vom Januar 2026 veröffentlichten Daten zeigen das Ausmaß der Ausnutzung:

Metrik	Wert
Von Defender blockierte bösartige E-Mails (Oktober 2025)	13 Millionen
Hauptsächlich identifizierte PhaaS-Plattform	Tycoon2FA
MFA-Bypass-Technik	Adversary-in-the-Middle (AiTM)
URL-Verschleierungstechnik	Google Maps-Weiterleitungen
Hauptköder	Passwort-Zurücksetzung, HR-Nachrichten, geteilte Dokumente
Eingangsvektor	Indirektes MX-Routing + SPF ~all + DKIM fehlend + DMARC p=none

Diese 13 Millionen E-Mails betreffen nur die von Defender blockierten Nachrichten. Organisationen ohne Defender for Office 365 oder mit weniger strengen Filterkonfigurationen profitierten nicht von diesem Schutz.

Verwendete Köder

Die von Microsoft dokumentierten Tycoon2FA-Kampagnen nutzen Szenarien mit hoher wahrgenommener Dringlichkeit:

• Passwort-Zurücksetzung: "Dein Passwort läuft in 24 Stunden ab. Klicke hier, um es zu erneuern." Der Link führt zur AiTM-Seite.
• HR-Nachrichten: "Neues Dokument zur Unterschrift für deine Vertragsaktualisierung." Der Anhang oder Link leitet zur Phishing-Seite weiter.
• Geteilte Dokumente: "Marie Dupont hat eine Datei mit dir auf OneDrive geteilt." Die E-Mail imitiert eine legitime SharePoint-Benachrichtigung.
• Self-Spoofing: In den ausgeklügeltsten Fällen ist die From-Adresse identisch mit der To-Adresse. Das Opfer empfängt eine E-Mail, die scheinbar von ihm selbst oder einem Kollegen derselben Domain stammt.

Self-Spoofing ist besonders wirkungsvoll, weil Nutzer E-Mails von ihrer eigenen Domain vertrauen. Eine E-Mail von hr@captaindns.com, die ein Mitarbeiter von captaindns.com empfängt, löst keinen menschlichen Alarm aus.

Forensische Header-Analyse: Den Angriff erkennen

Wenn eine verdächtige E-Mail in einem Microsoft 365-Postfach ankommt, enthalten die Header die Beweise für das abnormale Routing. So liest du sie mit einem E-Mail-Header-Analyzer.

Beispiel-Header einer gespooften E-Mail

Hier ist ein realistisches anonymisiertes Beispiel von Headern einer Phishing-E-Mail, die indirektes MX-Routing ausnutzt. Alle Warnsignale sind gleichzeitig vorhanden:

Return-Path: <bounce@malicious-relay.net>
Received: from mail-protection.captaindns.com (10.0.0.5) by
 exchange01.captaindns.com (10.0.0.10) with SMTP; Thu, 9 Jan 2026 08:15:23 +0000
Received: from gateway.thirdparty-filter.com (203.0.113.50) by
 mail-protection.captaindns.com with ESMTPS; Thu, 9 Jan 2026 08:15:21 +0000
Received: from unknown (198.51.100.77) by
 gateway.thirdparty-filter.com with SMTP; Thu, 9 Jan 2026 08:15:19 +0000
Authentication-Results: mail-protection.captaindns.com;
 spf=softfail (sender IP is 198.51.100.77) smtp.mailfrom=captaindns.com;
 dkim=none (message not signed);
 dmarc=fail action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 5
From: Direction RH <rh@captaindns.com>
To: jean.dupont@captaindns.com
Subject: Document de politique RH à signer - Action requise

Analyse Zeile für Zeile

Return-Path: <bounce@malicious-relay.net>

Der Return-Path enthüllt die tatsächliche Bounce-Adresse. Die Domain malicious-relay.net hat keine Verbindung zu captaindns.com. Diese Diskrepanz zwischen Return-Path und dem angezeigten From (rh@captaindns.com) ist das erste Warnsignal. In einer legitimen E-Mail, die von Microsoft 365 gesendet wurde, enthält der Return-Path die Domain der Organisation oder eine Subdomain von protection.outlook.com. Hier erscheint die Infrastruktur des Angreifers.

Received-Kette (von unten nach oben lesen):

Received: from unknown (198.51.100.77) by
 gateway.thirdparty-filter.com with SMTP

Erster Sprung: Die E-Mail stammt von einer unbekannten IP (198.51.100.77), die vom Drittanbieter-Dienst als unknown identifiziert wird. Das ist der Server des Angreifers. Das Fehlen einer Reverse-DNS-Auflösung (kein verifizierter Hostname) ist ein starkes Signal: Legitime E-Mail-Server haben einen PTR-Record konfiguriert. Die Verwendung von einfachem SMTP (nicht ESMTPS) bestätigt, dass der Absender keine TLS-Verschlüsselung unterstützt, was für einen Unternehmensserver in 2026 ungewöhnlich ist.

Received: from gateway.thirdparty-filter.com (203.0.113.50) by
 mail-protection.captaindns.com with ESMTPS

Zweiter Sprung: Der Drittanbieter-Dienst (gateway.thirdparty-filter.com) leitet an Exchange Online weiter. Diese IP (203.0.113.50) ist die, die Microsoft 365 als Quelle sieht. Der Authentifizierungskontext wird gegen diese IP ausgewertet, nicht gegen 198.51.100.77. Der Drittanbieter-Dienst hat die Nachricht akzeptiert und weitergeleitet.

Received: from mail-protection.captaindns.com (10.0.0.5) by
 exchange01.captaindns.com (10.0.0.10) with SMTP

Dritter Sprung: Internes Microsoft 365-Routing zum Posteingang. Die IP-Adressen im Bereich 10.x.x.x bestätigen internes Routing. Dieser Sprung ist normal.

Authentication-Results: Das dreifache Scheitern

Das ist die aufschlussreichste Zeile mit drei gleichzeitigen Fehlschlägen:

• spf=softfail (sender IP is 198.51.100.77): Die echte Quell-IP (198.51.100.77, der Server des Angreifers) ist nicht im SPF-Eintrag von captaindns.com. Mit einem ~all-Mechanismus ist das ein Softfail, kein Reject. Softfail wird als Warnung behandelt, nicht als Blockierung.
• dkim=none (message not signed): Keine DKIM-Signatur ist vorhanden. Der Angreifer besitzt nicht den privaten DKIM-Schlüssel von captaindns.com und kann daher nicht signieren. Der Drittanbieter-Dienst hat ebenfalls keine Signatur hinzugefügt. Das Fehlen von DKIM entzieht DMARC seinen zweiten Alignment-Vektor.
• dmarc=fail action=none: DMARC schlägt fehl (weder SPF noch DKIM bestehen mit Domain-Alignment). Aber action=none bedeutet, dass die DMARC-Richtlinie der Domain p=none ist, also wird trotz des Fehlschlags keine Aktion ausgeführt. Die E-Mail wird normal zugestellt.

X-MS-Exchange-Organization-SCL: 5

Das Spam Confidence Level (SCL) liegt bei 5 auf einer Skala von 0 bis 9. Ein SCL von 5 zeigt ein moderates Verdachtsniveau an. Standardmäßig stellt Exchange Online Nachrichten mit einem SCL von 6 oder höher unter Quarantäne. Ein SCL von 5 liegt knapp unter der Standard-Blockierungsschwelle. Defender hat verdächtige Signale erkannt (Authentifizierungsfehler, inkonsistenter Return-Path), aber nicht genug, um mit der aktuellen Konfiguration kategorisch zu blockieren.

From und To auf derselben Domain: Self-Spoofing

Das From zeigt Direction RH <rh@captaindns.com> und das To ist jean.dupont@captaindns.com. Dieselbe Domain. In Outlook sieht der Nutzer eine E-Mail von "Direction RH" mit dem Foto und der Berufsbezeichnung, die mit rh@captaindns.com im Adressbuch verknüpft sind. Der Banner "Diese E-Mail stammt von einem externen Absender" kann fehlen, wenn die Organisation Ausnahmen für interne Domains konfiguriert hat.

Subject: Document de politique RH à signer - Action requise

Der Betreff kombiniert zwei psychologische Hebel: Autorität ("Direction RH", "politique RH") und Dringlichkeit ("Action requise"). Dieser Ködertyp ist von Microsoft als einer der wirksamsten in Tycoon2FA-Kampagnen dokumentiert.

Vergleich mit einer legitimen E-Mail

Zum Kontrast hier die Header einer legitimen E-Mail, die von derselben Organisation gesendet wurde:

Return-Path: <rh@captaindns.com>
Authentication-Results: mail-protection.captaindns.com;
 spf=pass (sender IP is 40.107.22.83) smtp.mailfrom=captaindns.com;
 dkim=pass (signature was verified) header.d=captaindns.com;
 dmarc=pass action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 1
From: Direction RH <rh@captaindns.com>
To: jean.dupont@captaindns.com

Die Unterschiede sind deutlich: Der Return-Path stimmt mit der From-Domain überein, SPF besteht mit einer Microsoft-IP (40.107.x.x), DKIM besteht mit einer verifizierten Signatur, DMARC besteht, und der SCL liegt bei 1 (hohes Vertrauen). Das ist das typische Profil einer legitimen E-Mail.

Was das Gesamtbild zeigt

In Kombination ergibt sich eine klare Diagnose:

1. Die E-Mail stammt nicht von der Infrastruktur von captaindns.com (Return-Path auf malicious-relay.net)
2. Sie wurde über einen Drittanbieter-Dienst geleitet, der das Spoofing nicht blockiert hat
3. Dreifaches Authentifizierungsversagen: SPF Softfail, DKIM fehlend, DMARC Fail ohne Konsequenz
4. Der moderate SCL zeigt, dass Defender Zweifel hatte, aber die aktuelle Konfiguration keine Blockierung ermöglicht
5. Self-Spoofing (dieselbe Domain in From und To) nutzt das Vertrauen in interne Kommunikation aus

Um diesen E-Mail-Typ systematisch zu erkennen, analysiere deine Header mit einem E-Mail-Header-Analyzer und suche nach diesen vier Markern: Received-Kette mit unerwartetem Sprung von einer unbekannten IP, spf=softfail, dkim=none und dmarc=fail action=none.

5-Minuten-Diagnose: Ist deine Domain anfällig?

Drei DNS-Befehle reichen aus, um deine Exposition zu bewerten. Öffne ein Terminal und führe die folgenden Prüfungen durch.

Prüfung 1: Wohin zeigt dein MX?

dig MX captaindns.com +short

Sicheres Ergebnis:

10 captaindns-com.mail.protection.outlook.com.

Der MX zeigt direkt auf Microsoft 365. E-Mails kommen ohne Vermittler an. Die Authentifizierung wird gegen die IP des ursprünglichen Absenders ausgewertet.

Risiko-Ergebnis:

10 mx.filtrage-tiers.com.
20 mx2.filtrage-tiers.com.

Der MX zeigt auf einen Drittanbieter-Dienst. Alle eingehenden E-Mails durchlaufen diesen Vermittler, bevor sie Microsoft 365 erreichen. Wenn Enhanced Filtering for Connectors nicht aktiviert ist, wird die Authentifizierung gegen die IP des Drittanbieters ausgewertet.

Gemischtes Ergebnis (Prüfung erforderlich):

10 mx.filtrage-tiers.com.
20 captaindns-com.mail.protection.outlook.com.

Der prioritäre MX ist der Drittanbieter-Dienst, aber Microsoft 365 ist als Backup eingetragen. Im Normalbetrieb fließt der gesamte Datenverkehr über den Drittanbieter. Das Risiko ist identisch mit dem vorherigen Szenario.

Prüfung 2: Wie lautet deine DMARC-Richtlinie?

dig TXT _dmarc.captaindns.com +short

Anfälliges Ergebnis:

"v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"

Die Richtlinie p=none bedeutet, dass DMARC-Fehler gemeldet werden, aber keine Aktion auf die E-Mails ausgeführt wird. In Kombination mit indirektem MX-Routing ist das ein offenes Tor.

Teilweise geschütztes Ergebnis:

"v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com"

Die Richtlinie p=quarantine verschiebt E-Mails mit DMARC-Fehler in den Spam, aber pct=50 bedeutet, dass nur die Hälfte der E-Mails dieser Richtlinie unterliegt. Die andere Hälfte wird behandelt, als wäre die Richtlinie p=none.

Geschütztes Ergebnis:

"v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"

Die Richtlinie p=reject weist empfangende Server an, E-Mails, die DMARC nicht bestehen, abzulehnen. Das ist der maximale Schutz.

Prüfung 3: Wie lautet dein SPF-Endmechanismus?

dig TXT captaindns.com +short | grep spf

Anfälliges Ergebnis:

"v=spf1 include:spf.protection.outlook.com ~all"

Der Mechanismus ~all (Softfail) zeigt an, dass nicht aufgelistete IPs wahrscheinlich nicht für diese Domain senden sollten, aber das Ergebnis ist ein Softfail, kein Reject. Empfangende Server können es ignorieren.

Geschütztes Ergebnis:

"v=spf1 include:spf.protection.outlook.com -all"

Der Mechanismus -all (Hardfail) zeigt an, dass jede nicht aufgelistete IP ausdrücklich nicht autorisiert ist. Empfangende Server, die SPF respektieren, werden diese E-Mails ablehnen.

Vulnerabilitätsmatrix

MX	DMARC	SPF	DKIM	Risikoniveau
Drittanbieter	p=none	~all	Fehlend	Kritisch
Drittanbieter	p=none	-all	Fehlend	Hoch
Drittanbieter	p=quarantine	~all	Fehlend	Hoch
Drittanbieter	p=quarantine	-all	Aktiv	Moderat
Drittanbieter	p=reject	-all	Aktiv	Niedrig (wenn EFC aktiviert)
Direkt M365	p=reject	-all	Aktiv	Minimal

Wenn sich deine Domain in den Zeilen "Kritisch" oder "Hoch" befindet, ist die Korrektur dringend. Weiter zum nächsten Abschnitt.

5-Schritte-Korrekturplan

Schritt 1: Progressives DMARC bis p=reject

Wechsle niemals direkt von p=none zu p=reject. Die schrittweise Steigerung vermeidet das Blockieren legitimer E-Mails, von denen du nichts wusstest (Newsletter, SaaS, CRM, die im Namen deiner Domain senden).

Phase 1: Monitoring (mindestens 2 Wochen)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com; fo=1"

Die Option fo=1 fordert einen forensischen Bericht für jeden einzelnen Fehlschlag (SPF oder DKIM), nicht nur wenn beide fehlschlagen. Analysiere die aggregierten Berichte (rua), um alle legitimen Versandquellen zu identifizieren.

Phase 2: Progressive Quarantäne (2 Wochen)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@captaindns.com"

Nur 10 % der E-Mails mit DMARC-Fehler werden unter Quarantäne gestellt. Überwache Berichte und Nutzerbeschwerden.

Phase 3: Vollständige Quarantäne (2 Wochen)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@captaindns.com"

100 % der Fehlschläge werden unter Quarantäne gestellt. Wenn keine False Positives gemeldet werden, gehe zur nächsten Phase.

Phase 4: Progressives Reject (1 Woche)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-reports@captaindns.com"

10 % der Fehlschläge werden abgelehnt, der Rest bleibt unter Quarantäne.

Phase 5: Vollständiges Reject

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"

Maximaler Schutz. Jede E-Mail, die DMARC nicht besteht, wird vom empfangenden Server abgelehnt.

Der gesamte Prozess dauert etwa 7 bis 9 Wochen. Kürze die Phasen nicht ab: Jede Beobachtungsperiode enthüllt Versandquellen, die du vergessen hattest. Ein SaaS-Rechnungsdienst, ein altes Marketing-Tool, ein Kontaktformular, das über einen nicht in deinem SPF konfigurierten ESP sendet.

Schritt 2: SPF Hardfail (-all)

Ersetze ~all durch -all in deinem SPF-Eintrag:

captaindns.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"

Prüfe vor der Änderung, dass alle deine legitimen Versandquellen im SPF-Eintrag enthalten sind. Ein Hardfail in Kombination mit einer vergessenen Quelle blockiert legitime E-Mails.

Wichtige Hinweise:

• Anzahl der DNS-Lookups: SPF erlaubt maximal 10 rekursive DNS-Lookups. Jedes include: zählt als ein Lookup, plus verschachtelte. Über 10 hinaus ist das Ergebnis ein permerror und die Auswertung schlägt fehl.
• Alle Quellen einbeziehen: Microsoft 365, Google Workspace, ESP (Mailgun, SendGrid, Amazon SES), CRM (HubSpot, Salesforce), Ticketing-Tools.
• Vor der Veröffentlichung testen: Nutze unser Tool zur DMARC-Prüfung, um deine Konfiguration vor dem Produktiveinsatz zu validieren.

Schritt 3: DKIM aktivieren

DKIM ist das fehlende Puzzleteil in den meisten anfälligen Konfigurationen. Ohne DKIM kann sich DMARC nur auf SPF für das Alignment stützen. Wenn SPF fehlschlägt (was bei indirektem Routing systematisch der Fall ist), schlägt auch DMARC fehl.

In Microsoft 365:

1. Gehe zum Defender-Portal (security.microsoft.com)
2. Navigiere zu Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings > DKIM
3. Wähle deine Domain aus
4. Aktiviere "Sign messages for this domain with DKIM signatures"
5. Microsoft generiert zwei CNAME-Einträge zur Veröffentlichung in deinem DNS:

selector1._domainkey.captaindns.com.  CNAME  selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com.
selector2._domainkey.captaindns.com.  CNAME  selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com.

6. Veröffentliche die CNAMEs, warte auf die DNS-Propagation (üblicherweise 15 bis 30 Minuten) und validiere dann im Defender-Portal.

Mit aktivem DKIM kann DMARC selbst bei fehlgeschlagenem SPF wegen indirektem Routing über DKIM-Alignment bestehen, vorausgesetzt der Drittanbieter-Dienst ändert weder den Nachrichtentext noch die signierten Header.

Schritt 4: Konnektoren auditieren und Enhanced Filtering aktivieren

Enhanced Filtering for Connectors (EFC) ist die technische Lösung, die Microsoft für Organisationen empfiehlt, die indirektes MX-Routing beibehalten müssen. EFC ermöglicht Exchange Online, "über die IP des Drittanbieter-Dienstes hinauszuschauen", um die IP des ursprünglichen Absenders in der Received-Kette zu finden.

Aktivierung in Exchange Online:

1. Gehe zum Exchange Admin Center (admin.exchange.microsoft.com)
2. Navigiere zu Mail flow > Connectors
3. Identifiziere den eingehenden Konnektor von deinem Drittanbieter-Dienst
4. Aktiviere in den Konnektor-Eigenschaften "Enhanced Filtering for Connectors"
5. Konfiguriere die IPs des Drittanbieter-Dienstes zum "Überspringen" (Skip Listing)

Sobald EFC aktiviert ist, durchläuft Exchange Online die Received-Kette nach oben, um die letzte externe IP vor dem Drittanbieter-Dienst zu finden. Die Auswertung von SPF, DKIM und DMARC erfolgt gegen diese IP und stellt den korrekten Authentifizierungskontext wieder her.

Wichtige Hinweise:

• Teste EFC im Audit-Modus, bevor du es produktiv anwendest
• Stelle sicher, dass die IPs des Drittanbieter-Dienstes in der Skip List aktuell sind
• Prüfe, ob der Drittanbieter-Dienst die Received-Header nicht so umschreibt, dass EFC die Quell-IP nicht mehr finden kann

Schritt 5: Direktes MX zu Microsoft 365 in Betracht ziehen

Die radikalste und effektivste Lösung ist die Eliminierung des Vermittlers. Wenn dein Drittanbieter-Dienst für Anti-Spam-Filterung genutzt wird, bietet Microsoft Defender for Office 365 (Plan 1 oder Plan 2) gleichwertige oder überlegene Fähigkeiten:

• Exchange Online Protection (EOP): In allen Microsoft 365-Lizenzen enthalten, bietet grundlegende Anti-Spam- und Anti-Malware-Filterung.
• Defender for Office 365 Plan 1: Fügt Safe Links (Echtzeit-URL-Umschreibung und -Analyse), Safe Attachments (Sandbox-Detonation) und Anti-Phishing hinzu.
• Defender for Office 365 Plan 2: Fügt Threat Explorer, Automated Investigation and Response (AIR), Attack Simulation Training und Threat Trackers hinzu.

Wenn der Drittanbieter-Dienst für Archivierung oder Compliance genutzt wird, funktionieren Archivierungslösungen auch nachgelagert (Journal Rules), ohne indirektes MX-Routing zu erfordern.

Um auf direktes MX umzustellen:

captaindns.com.  IN  MX  10  captaindns-com.mail.protection.outlook.com.

Entferne die alten MX-Einträge, die auf den Drittanbieter-Dienst zeigen. Aktualisiere bei Bedarf deinen SPF. Prüfe, ob deine Exchange Online-Konnektoren korrekt konfiguriert sind.

Über die E-Mail-Authentifizierung hinaus: Die MFA-Frage

Indirektes MX-Routing öffnet die Tür zum Phishing. Aber Microsofts Warnung erinnert daran, dass Tycoon2FA nicht nur Passwörter stiehlt. Die Plattform stiehlt authentifizierte Sitzungen und umgeht dabei MFA. Die Korrektur des E-Mail-Routings reicht daher nicht aus, wenn deine MFA anfällig für AiTM-Angriffe bleibt.

Warum klassisches MFA nicht mehr schützt

MFA basierend auf TOTP-Codes (Authenticator-Apps wie Microsoft Authenticator im Code-Modus, Google Authenticator) oder Push-Benachrichtigungen ist anfällig für AiTM-Proxys. Der Mechanismus ist strukturell bedingt: Der TOTP-Code ist ein geteiltes Geheimnis zwischen Nutzer und Server. Wenn sich ein Proxy dazwischen schaltet, fängt er den Code im Transit ab und spielt ihn sofort wieder ab. Push-Benachrichtigungen sind noch einfacher auszunutzen: Der Proxy löst die Authentifizierungsanfrage auf dem echten Server aus, der Nutzer bestätigt auf seinem Telefon, und der Proxy fängt das resultierende Session-Cookie ab.

Das bedeutet nicht, dass MFA nutzlos ist. Es schützt weiterhin gegen Credential Stuffing, Wörterbuchangriffe und Datenbanklecks. Aber gegen AiTM-Phishing braucht es eine Phishing-resistente Lösung.

FIDO2 und Passkeys: Die einzige Phishing-resistente Lösung

FIDO2-Schlüssel (YubiKey, Feitian, Google Titan) und Passkeys (implementiert in Windows Hello, Apple iCloud Keychain, Android) bieten nativen Phishing-Schutz. Der Mechanismus basiert auf Origin Binding:

1. Bei der Registrierung wird der FIDO2-Schlüssel oder Passkey an eine bestimmte Domain gebunden (zum Beispiel login.microsoftonline.com).
2. Bei der Authentifizierung prüft der Browser automatisch, ob die Domain der Seite mit der registrierten Domain übereinstimmt. Wenn die Seite ein Phishing-Proxy unter login-microsoftonline.attacker.com ist, verweigert der Browser das Senden der Zugangsdaten.
3. Kein geteiltes Geheimnis zum Abfangen. Die Authentifizierung verwendet einen Challenge-Response-Mechanismus basierend auf einem asymmetrischen Schlüsselpaar. Selbst wenn der Angreifer den Austausch abfängt, kann er ihn nicht wiederholen.

Ein AiTM-Proxy kann diesen Mechanismus nicht umgehen: Der Browser prüft die Origin auf einer Ebene, die der Proxy nicht fälschen kann. Deshalb treiben Microsoft, Google und Apple seit 2024 gemeinsam die Passkey-Adoption voran.

MFA Number Matching als Zwischenlösung

Wenn der FIDO2/Passkey-Rollout nicht sofort möglich ist, aktiviere mindestens Number Matching in Microsoft Authenticator. Statt eines einfachen "Genehmigen / Ablehnen" muss der Nutzer eine zweistellige Zahl eingeben, die auf dem Anmeldebildschirm angezeigt wird. Diese Maßnahme schützt nicht vor einem ausgeklügelten AiTM-Proxy (der Proxy kann die Zahl anzeigen), aber sie blockiert MFA-Fatigue-Angriffe (Push-Benachrichtigungs-Bombardement) und fügt Reibung hinzu, die die Erfolgsrate der Angriffe reduziert.

Aktivierung in Entra ID:

1. Gehe zum Microsoft Entra Admin Center (entra.microsoft.com)
2. Navigiere zu Protection > Authentication methods > Microsoft Authenticator
3. Aktiviere im Tab Configure "Require number matching for push notifications"
4. Wende es auf alle Nutzer oder eine Pilotgruppe an

Die Priorität bleibt der FIDO2/Passkey-Rollout für hochprivilegierte Konten (Administratoren, Führungskräfte, Finanzteams), gefolgt von der schrittweisen Ausweitung auf alle Nutzer.

Die Rolle von ARC in Relay-Ketten

Das Protokoll ARC (Authenticated Received Chain) wurde genau dafür entwickelt, das Problem des Verlusts des Authentifizierungskontexts beim Transit über Vermittler zu lösen. ARC ermöglicht es jedem Relay, die beobachteten Authentifizierungsergebnisse zu signieren und so eine verifizierbare Vertrauenskette zu erstellen.

Theoretisch, wenn der Drittanbieter-Dienst ARC korrekt implementiert:

1. Der Drittanbieter-Dienst empfängt die E-Mail und wertet SPF/DKIM/DMARC aus
2. Er fügt einen Satz ARC-Header hinzu (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal), die die beobachteten Ergebnisse dokumentieren
3. Microsoft 365 empfängt die E-Mail und prüft die ARC-Kette
4. Wenn die ARC-Kette gültig ist und von einem vertrauenswürdigen ARC-Absender stammt, kann Microsoft 365 die ursprünglichen Authentifizierungsergebnisse verwenden, statt seiner eigenen Ergebnisse (die durch das indirekte Routing verfälscht sind)

In der Praxis hängt die Wirksamkeit von ARC von zwei Bedingungen ab: Der Drittanbieter-Dienst muss ARC implementieren (was nicht durchgängig der Fall ist), und Microsoft 365 muss dem ARC-Absender vertrauen (konfigurierbar im Defender-Portal). Ohne beide Bedingungen ändert ARC nichts.

Microsoft empfiehlt ARC als ergänzende Lösung, aber nicht als Ersatz für Enhanced Filtering for Connectors oder den Wechsel zu direktem MX.

Überwachung und Reaktion bei einem Vorfall

Die Absicherung des E-Mail-Routings ist kein einmaliges Projekt. Angreifer passen ihre Techniken an, Konfigurationen entwickeln sich weiter, und neue Versanddienste werden regelmäßig hinzugefügt. Aktive Überwachung ist notwendig, um Regressionen oder Ausnutzungsversuche schnell zu erkennen.

Alerts in Microsoft Defender konfigurieren

Microsoft Defender for Office 365 ermöglicht die Erstellung benutzerdefinierter Alerts, die die in diesem Artikel beschriebenen Angriffsmuster erkennen:

Alert bei wiederkehrenden DMARC-Fehlschlägen: Gehe im Defender-Portal (security.microsoft.com) zu Email & collaboration > Explorer. Filtere nach DMARC = fail und action = none für deine Domain. Wenn du ein abnormales Volumen von DMARC-Fehlschlägen ohne Aktion beobachtest, ist das ein Zeichen, dass deine p=none-Richtlinie ausgenutzt wird. Konfiguriere einen automatisierten Alert, um benachrichtigt zu werden, wenn das Volumen einen Schwellenwert überschreitet (zum Beispiel mehr als 50 DMARC-Fehlschläge pro Tag für eine interne Domain).

Alert bei Self-Spoofing: Suche nach E-Mails, deren From-Feld eine interne Domain enthält, aber deren Return-Path eine externe Domain enthält. Dieses Muster ist charakteristisch für Self-Spoofing. In Exchange Online kann eine Mail-Flow-Regel (Transportregel) diese Bedingung erkennen und eine visuelle Warnung zur Nachricht hinzufügen oder sie unter Quarantäne stellen.

Überwachung aggregierter DMARC-Berichte: Aggregierte DMARC-Berichte (gesendet an die rua-Adresse) enthalten die Authentifizierungsergebnisse aller E-Mails, die im Namen deiner Domain gesendet wurden. Analysiere sie mindestens einmal pro Woche. Ein plötzlicher Anstieg von Fehlschlägen von unbekannten IPs weist auf eine laufende Spoofing-Kampagne hin. Kostenlose Tools wie DMARC Analyzer, Postmark DMARC oder die aggregierten Berichte von Microsoft ermöglichen es, diese Daten ohne manuelle Verarbeitung zu visualisieren.

Was tun, wenn du einen laufenden Angriff erkennst?

Wenn du Phishing-E-Mails identifizierst, die indirektes MX-Routing gegen deine Domain ausnutzen:

1. Aktiviere sofort EFC, falls noch nicht geschehen. Das ist die schnellste Maßnahme, um den korrekten Authentifizierungskontext wiederherzustellen.
2. Setze DMARC mindestens auf p=quarantine, auch ohne die empfohlene schrittweise Steigerung. Bei einem aktiven Angriff ist das Risiko von False Positives zweitrangig gegenüber dem Kompromittierungsrisiko.
3. Blockiere die Quell-IPs, die in den Received-Headern identifiziert wurden, über Exchange Online Mail-Flow-Regeln oder über den Drittanbieter-Dienst.
4. Informiere die betroffenen Nutzer. Wenn Self-Spoofing-E-Mails zugestellt wurden, müssen die Nutzer wissen, dass sie keine Links anklicken und keine Anhänge öffnen sollen.
5. Prüfe verdächtige Anmeldungen in den Entra ID-Auditprotokollen. Wenn der AiTM-Angriff Session-Cookies erfasst hat, wirst du Anmeldungen von ungewöhnlichen IPs kurz nach der Zustellung der Phishing-E-Mails sehen.
6. Widerrufe aktive Sitzungen potenziell kompromittierter Konten über Entra ID (Revoke Sessions). Erzwinge eine Passwortänderung und MFA-Neuauthentifizierung.

Langfristige Erkennung automatisieren

Für Organisationen mit signifikantem E-Mail-Volumen ist die Automatisierung der Erkennung unverzichtbar. Microsoft Sentinel (Microsofts Cloud-SIEM) kann Exchange Online-Protokolle aufnehmen und automatisierte Playbooks bei folgenden Bedingungen auslösen:

• Abnormales Volumen von E-Mails mit dmarc=fail action=none für eine interne Domain
• Eingehende E-Mails, bei denen die From-Domain eine interne Domain ist, aber die Quell-IP nicht in der Liste der autorisierten IPs steht
• Entra ID-Anmeldungen von einer geografisch inkonsistenten IP innerhalb von Minuten nach der Zustellung einer verdächtigen E-Mail

Diese Automatisierungen verwandeln reaktive Erkennung ("Wir haben eine verdächtige E-Mail gefunden") in proaktive Erkennung ("Das System hat die E-Mail isoliert und das Konto gesperrt, bevor der Nutzer geklickt hat").

Vollständige Sicherheitscheckliste

Hier ist die konsolidierte Checkliste zur Absicherung deiner Domain gegen den von Microsoft dokumentierten Angriffsvektor. Jeder Punkt ist nach Priorität geordnet.

Kritische Priorität (Woche 1)

• Prüfe deinen MX: dig MX captaindns.com +short
• Prüfe deine DMARC-Richtlinie: dig TXT _dmarc.captaindns.com +short
• Prüfe deinen SPF-Endmechanismus: dig TXT captaindns.com +short
• Bei indirektem MX + DMARC p=none: Enhanced Filtering for Connectors sofort aktivieren
• DKIM für deine Domain in Microsoft 365 aktivieren

Hohe Priorität (Wochen 2 bis 4)

• Schrittweise DMARC-Steigerung Richtung p=quarantine starten
• SPF ~all nach Inventur der Versandquellen durch -all ersetzen
• Eingehende Konnektoren in Exchange Online auditieren
• Skip-List-IP-Konfiguration für EFC prüfen
• Number Matching in Microsoft Authenticator aktivieren

Mittlere Priorität (Monate 2 bis 3)

• DMARC-Steigerung Richtung p=reject fortsetzen
• Migration auf direktes MX zu Microsoft 365 evaluieren
• FIDO2/Passkey-Rollout für hochprivilegierte Konten starten
• Vertrauenswürdige ARC-Absender konfigurieren, wenn indirektes Routing beibehalten wird
• Regelmäßige Überwachung der aggregierten DMARC-Berichte einrichten

Niedrige Priorität (nächstes Quartal)

• FIDO2/Passkeys auf alle Nutzer ausweiten
• Indirektes MX-Routing entfernen, wenn nicht erforderlich
• DMARC-Berichtsanalyse mit einem dedizierten Tool automatisieren
• Nutzer schulen, Phishing-E-Mails zu erkennen

Was Microsofts Warnung für deine Organisation bedeutet

Microsofts Warnung vom Januar 2026 hat keinen Bug enthüllt. Sie hat einen architektonischen blinden Fleck aufgedeckt, den Angreifer im großen Stil ausnutzen. Die Kombination aus indirektem MX-Routing + SPF Softfail + fehlendem DKIM + DMARC p=none ist eine Konfiguration, die Tausende Organisationen nutzen, ohne zu wissen, dass sie anfällig ist.

Die Lösung ist kein Software-Patch. Es ist eine Arbeit an der DNS-Konfiguration und E-Mail-Architektur. Manche Organisationen werden in einem Tag korrigieren (DKIM aktivieren, SPF auf Hardfail setzen, EFC aktivieren). Andere werden mehrere Monate brauchen, um ihren MX zu migrieren und FIDO2 bereitzustellen.

Die drei sofortigen Maßnahmen:

1. Jetzt diagnostizieren. Die drei dig-Befehle aus dem Diagnoseabschnitt dauern 30 Sekunden. Du weißt sofort, ob sich deine Domain in der kritischen Zone befindet.
2. Enhanced Filtering for Connectors aktivieren, wenn dein MX auf einen Drittanbieter zeigt. Das ist die schnellste Korrektur mit dem besten Verhältnis von Wirkung zu Aufwand.
3. DKIM aktivieren. Es ist das fehlende Puzzleteil in den meisten anfälligen Konfigurationen. Mit aktivem DKIM kann DMARC selbst dann bestehen, wenn SPF wegen indirektem Routing fehlschlägt.

Das Endziel ist einfach: Deine Domain muss durch SPF -all, aktives DKIM und DMARC p=reject geschützt sein. Das ist kein theoretisches Ideal, sondern die Baseline, die Google, Yahoo und Microsoft seit 2024 von Absendern fordern. Microsofts Warnung vom Januar 2026 erinnert daran, dass E-Mails im Spam landen, wenn diese Baseline nicht erreicht wird, und schlimmer noch, dass Angreifer Domains, die sie nicht erreichen, aktiv ausnutzen.