Sophos Phish Threat in Microsoft 365 sicher zustellen

Für Sophos Phish Threat gibt es in Microsoft 365 zwei technisch verschiedene Zustellwege:

• M365 Direct Delivery schreibt Kampagnen-, Trainingsregistrierungs- und Trainingserinnerungs-E-Mails über Microsoft Graph direkt in die Postfächer. Die Nachrichten umgehen die Microsoft-Transportpipeline; Erweiterte Übermittlung (Advanced Delivery) greift deshalb nicht.
• Bei der SMTP-Zustellung durchläuft die Nachricht die Microsoft-Transportpipeline. Microsoft 365 muss sie anhand der tatsächlichen Sending IP und der Domain aus 5321.MailFrom oder der DKIM-Domain als Drittanbieter-Phishingsimulation erkennen.

Beide Wege sind von Sophos Email Mailflow und Sophos Email Gateway zu trennen. Phish Threat simuliert Angriffe; Sophos Email schützt den produktiven Mailverkehr. Für Direct Delivery werden weder MX-Einträge noch Exchange-Online-Connectors angelegt. Auch der SMTP-Weg rechtfertigt keinen globalen EOP-Bypass und keine pauschale IP-Allow-List.

Voraussetzungen und Change-Grenzen

Vor der Änderung benötigt man:

• eine aktive Sophos-Phish-Threat-Berechtigung und eine in Sophos Fusion (ehemals Sophos Central) verifizierte E-Mail-Domain;
• administrativen Zugriff auf Sophos Phish Threat > Settings;
• für Direct Delivery eine genehmigte Microsoft-Graph-Anwendung und tenantweite Adminzustimmung;
• für den SMTP-Weg Berechtigung zur Pflege von Erweiterte Übermittlung im Microsoft Defender Portal;
• je Domain eine kontrollierte Pilotmailbox, einen fachlichen Owner, ein Change-Fenster und ein Abbruchkriterium.

Bei der manuellen Direct-Delivery-Einrichtung verlangt Sophos die Microsoft-Graph-Anwendungsberechtigungen (Application permissions, nicht delegierte Berechtigungen) Domain.Read.All und Mail.ReadWrite; beide benötigen Adminzustimmung. Domain.Read.All darf ohne angemeldeten Benutzer alle Domaineigenschaften lesen. Mail.ReadWrite darf ohne zusätzliche Einschränkung Nachrichten in allen Mailboxen des Tenants lesen, erstellen, ändern und löschen. Die Berechtigung umfasst nicht Mail.Send, bleibt aber wegen ihres tenantweiten Lese- und Schreibzugriffs hochprivilegiert. Dieser Umfang muss vor der Zustimmung und beim Offboarding berücksichtigt werden.

Vorher erfasst man Domain, Tenant-ID, gewählten Zustellweg, Credential, aktuellen Direct-Delivery-Status und bestehende Microsoft-Simulationswerte. Ein vorhandener Sophos-Email-Mailflow- oder Gateway-Aufbau bleibt ein separates System. Dessen Connectors, Transportregeln, MX-, SPF- und Enhanced-Filtering-Einstellungen werden für diesen Phish-Threat-Change nicht nebenbei verändert. Die jeweiligen Owner sind Sophos Email Mailflow für Microsoft 365 und Sophos Email Gateway mit Microsoft 365.

Zustellweg auswählen

Sophos empfiehlt Direct Delivery. Es wird pro verifizierter Domain aktiviert; ein grüner Status einer Domain ist kein Nachweis für weitere Domains. Autorisierung, Schnelltest, Fehlerbehebung und Deaktivierung dieses Wegs beschreibt das Owner-Runbook Sophos Phish Threat: Direct Delivery einrichten. Dieser Artikel behandelt im Folgenden den Microsoft-365-spezifischen SMTP-Weg und dessen Abgrenzung zu Direct Delivery.

SMTP-Zustellung mit Erweiterter Übermittlung einrichten

Die veränderlichen Sophos-Werte werden nicht aus einer alten Anleitung kopiert. Man liest sie unmittelbar vor dem Change in Sophos Fusion unter My Products > Phish Threat > Settings > Sending domains and IPs aus und bestätigt sie mit den Headern einer aktuellen Pilotnachricht. Weitere Ziele und deren sichere Begrenzung behandelt Phish-Threat-Absender und Ziele allowlisten.

Richtige Matching-Werte bestimmen

Microsoft verlangt für eine Übereinstimmung mindestens:

1. die tatsächliche Sending IP, die Microsoft 365 für die SMTP-Nachricht erkennt; und
2. entweder die Domain aus 5321.MailFrom — auch MAIL FROM, P1-Absender oder Envelope Sender — oder die vom Anbieter angegebene DKIM-Domain (header.d).

Die sichtbare From:-/5322.From-Domain ist kein austauschbarer Ersatz. In Authentication-Results prüft man deshalb smtp.mailfrom, header.d und die erkannte Quell-IP. Microsoft verknüpft einzelne Domain- und IP-Einträge nicht paarweise; die Listen müssen daher auf die tatsächlich benötigten Sophos-Werte beschränkt bleiben.

Das optionale Feld Zulässige Simulations-URLs (Simulation URLs to allow) wird für Links in E-Mail-Phishingsimulationen nicht benötigt. Microsoft sieht es primär für Nicht-E-Mail-Simulationen vor, etwa Links in Teams-Nachrichten oder Office-Dokumenten. Für diesen E-Mail-Ablauf bleibt es leer.

Im Microsoft Defender Portal konfigurieren

1. Im Microsoft 365 Admin Center Alle anzeigen > Sicherheit öffnen.
2. Im Microsoft Defender Portal E-Mail & Zusammenarbeit > Richtlinien & Regeln > Bedrohungsrichtlinien öffnen.
3. Unter Regeln Erweiterte Übermittlung wählen.
4. Den Tab Phishingsimulation öffnen und Bearbeiten wählen. Wenn noch keine Drittanbieter-Simulation vorhanden ist, wird stattdessen die Schaltfläche zum Hinzufügen angezeigt.
5. Unter Domain ausschliesslich bestätigte 5321.MailFrom- oder DKIM-Domains eintragen — nicht die sichtbare From:-Domain, sofern sie nicht zugleich einer dieser beiden Werte ist.
6. Unter Sending IP ausschliesslich die von Microsoft erkannte Sophos-Quell-IP beziehungsweise den belegten, möglichst kleinen Bereich eintragen.
7. Zulässige Simulations-URLs für diese E-Mail-Simulation leer lassen, die Werte gegen den Change-Beleg vergleichen und Speichern wählen.

Connector- und Routing-Grenze

Wenn der MX-Eintrag nicht direkt auf Microsoft 365 zeigt, muss die IP in Authentication-Results weiterhin mit der unter Erweiterte Übermittlung hinterlegten Sending IP übereinstimmen. Enhanced Filtering for Connectors kann bei unterstützten vorgeschalteten Filter-Topologien helfen, die ursprüngliche Quell-IP zu erkennen; es ersetzt aber weder das Domain-und-IP-Matching noch die Simulationskonfiguration.

Für das In-and-out-Routing Internet > Microsoft 365 > lokale Umgebung oder Drittanbieter-Sicherheitsdienst > zurück zu Microsoft 365 dokumentiert Microsoft ausdrücklich eine Grenze: Microsoft 365 kann die echte Quell-IP der Drittanbieter-Simulation nicht zuverlässig erkennen, und Enhanced Filtering behebt dies für diesen Fall nicht. Die Gateway-, lokale oder Connector-IP darf nicht als vermeintliche Sending IP eingetragen werden. Sonst könnten beliebige Internetabsender, die eine hinterlegte Domain imitieren, den Spamfilter umgehen.

Als sichere Grenze sendet die Simulation direkt an den Microsoft-365-MX oder verwendet ein für die konkrete Topologie ausdrücklich von Microsoft dokumentiertes Verfahren. Lässt sich die echte Sophos-IP damit nicht erkennen, wird der SMTP-Rollout gestoppt statt durch eine Gateway-IP oder eine breite Transportregel erzwungen.

Safe Links und Safe Attachments richtig einordnen

Die beiden Zustellwege dürfen hier nicht vermischt werden:

• SMTP mit korrektem Advanced-Delivery-Match: Safe Links blockiert oder detoniert die angegebenen URLs dieser E-Mail-Simulation beim Klick nicht; Safe Attachments detoniert deren Anhänge nicht. Die URLs bleiben umgeschrieben. Eine zusätzliche Aufnahme unter Folgende URLs in E-Mails nicht umschreiben ist nicht erforderlich und kann unerwünschte Klickalarme auslösen.
• Direct Delivery: Diese Nachrichten umgehen die Transportpipeline, daher greift Advanced Delivery nicht. Wenn ein kontrollierter Direct-Delivery-Test einen Safe-Links-Klickblock reproduziert, kann die von Sophos dokumentierte, auf die tatsächlich verwendete Simulationsdomain begrenzte Safe-Links-Ausnahme nötig sein. Sie gilt nur für diesen Direct-Delivery-Fall und wird nach Phish-Threat-Absender und Ziele allowlisten umgesetzt.

Legacy-Transportregeln mit X-MS-Exchange-Organization-SkipSafeLinksProcessing oder X-MS-Exchange-Organization-SkipSafeAttachmentProcessing sind kein zusätzlicher Standardschritt. Eine bestehende Regel wird nur nach belegtem Bedarf und bestätigter enger Quell-IP-Bedingung separat bewertet; sie wird nie auf alle Nachrichten oder eine frei gewählte Absenderdomain erweitert.

Validierung vor der ersten SMTP-Kampagne

Eine kleine Pilotkampagne wird nur an autorisierte Testkonten gesendet. Für jede Domain dokumentiert man Empfänger, Versandzeit, Kampagnen-ID und erwartete Matching-Werte. Danach prüft man:

• Zustellung oder Quarantäne und den passenden Microsoft Message Trace;
• in den Nachrichtenheadern die von Microsoft erkannte Sending IP sowie smtp.mailfrom und header.d;
• dass mindestens die tatsächliche Sending IP und eine zulässige 5321.MailFrom- oder DKIM-Domain mit Erweiterte Übermittlung > Phishingsimulation übereinstimmen;
• Darstellung, Linkklick und die erwarteten Phish-Threat-Ereignisse;
• dass keine automatisierte Prüfung als Benutzeraktion gewertet wurde.

Die fachliche Auswertung gehört in Sophos Phish Threat: Ergebnisse und Berichte. Ein Eintrag in Message Trace allein beweist weder den Posteingang noch eine korrekte Kampagnenmessung.

Fehler systematisch eingrenzen

Schlägt ein Test trotz korrekter Werte fehl, sammelt man Domain, UTC-Zeit, Empfänger, Kampagnen-ID, Microsoft-Trace, relevante Header und die konfigurierten Simulationswerte. Diese Daten gehen an Sophos Support beziehungsweise den Microsoft-365-Owner. Secrets, Zugriffstoken und unnötige personenbezogene Kampagnendaten gehören nicht in das Ticket.

SMTP-Ausnahmen zurückbauen und kontrollieren

Bei einem fehlgeschlagenen SMTP-Change stellt man unter Erweiterte Übermittlung > Phishingsimulation die zuvor dokumentierten Werte wieder her. Neu angelegte Ausnahmen oder Legacy-Transportregeln werden nur entfernt, wenn ihre Zuordnung zur betroffenen Simulation eindeutig ist. Danach bestätigt ein kontrollierter Test, dass der produktive Mailverkehr unverändert funktioniert. Sophos-Email-Connectors und -Regeln bleiben unberührt.

Mindestens vor jeder neuen Kampagnenserie und nach Änderungen an Domain, Sophos-Absenderwerten, Routing oder Microsoft-Sicherheitsrichtlinien prüft der Owner:

• aktuelle Sophos-Werte gegen die tatsächliche Sending IP sowie smtp.mailfrom oder header.d einer Pilotmail;
• den direkten oder ausdrücklich unterstützten Weg zur Microsoft-365-Transportpipeline;
• nicht mehr verwendete Domains, IP-Adressen und Legacy-Regeln;
• einen kontrollierten End-to-End-Test einschliesslich Linkklick und Kampagnenereignis.

Ändern sich Sophos-Absenderwerte, ersetzt man sie in einem genehmigten Change und löscht alte Werte erst nach erfolgreicher Pilotzustellung. Direct-Delivery-Credentials, Tests und Offboarding bleiben im Direct-Delivery-Owner-Runbook, damit der API-Lifecycle nur an einer Stelle gepflegt wird.