Zum Inhalt springen
Avanet

Sophos Email Mailflow: Microsoft 365 systematisch reparieren

Sophos Email

Wenn Sophos Email Mailflow in Microsoft 365 ausfällt, sollte man nicht auf Verdacht Connectors oder Transportregeln löschen. Zuerst liest man den Domainstatus in Sophos Fusion (ehemals Sophos Central), führt einen Run a Quick Test aus und vergleicht dieselbe Nachricht in Microsoft Message Trace und Sophos Message History. Erst danach repariert man den betroffenen Pfad.

Schnellweg: Connected mit grünem Haken bedeutet, dass die Mailflow-Verbindung steht. Not Connected mit rotem Kreuz verlangt einen Verbindungs- oder Berechtigungscheck. Ein Ausrufezeichen mit View Details weist auf eine direkt in Microsoft 365 geänderte Regel oder einen Connector hin. Bei einem 552-Fehler sucht man zuerst nach doppelten Sophos- und Microsoft-Headern: Sie belegen häufig, dass eine Signaturplattform die Nachricht erneut durch Sophos routet.

Dieses Runbook gilt ausschliesslich für Sophos Email im Mailflow-Modus (MFR). Dabei bleiben die MX-Einträge auf Microsoft 365 und Microsoft-Transportregeln sowie Connectors führen Nachrichten zu Sophos und zurück. Im Gateway-Modus zeigen die MX-Einträge dagegen auf Sophos; dessen Diagnose und Rückbau folgen einem anderen Ablauf. Gateway-Anweisungen dürfen deshalb nicht auf eine Mailflow-Domain übertragen werden. Die vollständige Bereitstellung und eine geplante Migration beschreibt Sophos Email Mailflow für Microsoft 365 einrichten.

Voraussetzungen und sichere Ausgangslage

Für die Diagnose benötigt man administrativen Zugriff auf Sophos Fusion sowie ein Konto, das Zustimmung für die Sophos Email App und die nötigen Exchange-Online-Mailflow-Berechtigungen erteilen kann. Die betroffenen Microsoft-365-Domains müssen für Mailflow geeignet und die benötigten Benutzer und Gruppen synchronisiert sein.

Vor jeder Änderung erfasst man:

  • betroffene Domain, Absender, Empfänger, UTC-Zeit, Internet Message-ID und vollständige Header;
  • aktuellen Mailflow Connection- und gegebenenfalls Post Delivery-Status;
  • Namen, Aktivierungszustand und Priorität der Sophos-, Signatur- und sonstigen Transportregeln und Connectors;
  • Ergebnis von Microsoft Message Trace und Sophos Message History;
  • letzte bekannte funktionierende Konfiguration und den Owner jeder Änderung.

Man ändert nur einen Faktor pro Test. Die von Sophos angelegte Domain xgeconnector.com darf nicht entfernt werden: Das kann den Mailfluss und die Verarbeitung unterbrechen. Auch ein scheinbar verwaister Sophos-Connector wird nicht gelöscht, bevor seine Domainzuordnung und der Rückweg dokumentiert sind.

1. Verbindung und Domainstatus prüfen

  1. In Sophos Fusion das Symbol Global Settings öffnen.
  2. Products and Services > Email > M365 Mailflow Domains wählen.
  3. Den Status der betroffenen Domain prüfen:
    • grüner Haken, Connected: Verbindung vorhanden;
    • rotes Kreuz, Not Connected: mit dem eingeblendeten grünen Haken kann man die Domain erneut verbinden;
    • Ausrufezeichen, View Details: eine Microsoft-365-Änderung muss geprüft werden.
  4. Das Testsymbol der Domain anklicken, unter Run a Quick Test eine kontrollierte Empfängeradresse eingeben und Proceed wählen. Der Test kann einige Minuten dauern.
  5. Bei einem Fehler zuerst Run The Test Again verwenden. Bleibt der Fehler bestehen, Reconnect wählen.

Ein erfolgreicher Quick Test entfernt das Ausrufezeichen und setzt den Status wieder auf den grünen Haken. Das ist der Verbindungstest, aber noch kein vollständiger Zustellnachweis: Danach sendet man je eine kontrollierte Nachricht ein- und ausgehend und verfolgt beide in Microsoft Message Trace und Sophos Message History bis zum endgültigen Empfänger.

Wenn Reconnect Regeln oder Connectors nicht erstellen kann

Man prüft, ob die Sophos-Mailflow-Anwendung die benötigten rollenbasierten Zuweisungen im Microsoft-365-Tenant besitzt. Insbesondere müssen die erforderlichen Exchange-Online-Mailflow-Berechtigungen unter der Exchange-Administratorrolle verfügbar sein. Automatische Reparaturen funktionieren nur mit gültiger Zustimmung und diesen Berechtigungen.

Scheitert Reconnect weiterhin, führt man keine wiederholten manuellen Löschversuche aus. Man sichert Status, Quick-Test-Ergebnis, Regel- und Connectornamen sowie die Message-ID und eskaliert an Sophos Support; eine manuelle Bereinigung kann erforderlich sein.

2. Eine Warnung zu geänderten Mailflow-Objekten bearbeiten

Sophos überwacht Deaktivierung, Löschung und Änderung der für Mailflow benötigten Transportregeln und Connectors. Dafür muss Microsoft-365-Auditing eingeschaltet sein und die Sophos Email App die Organisationsberechtigung Read activity data besitzen. Bei Domains, deren Mailflow vor dem 12. April 2022 eingerichtet wurde, erteilt man diese zusätzliche Berechtigung durch Trennen und erneutes Verbinden; bei später eingerichteten Regeln sollte sie bereits vorhanden sein.

Warnungen haben die Stufen High, Medium und Low. Alle erscheinen in Sophos Fusion; zusätzliche E-Mails an Admins und Super Admins sowie ein geänderter Domainstatus werden nur für High und Medium erzeugt. Unter Alerts kann man gruppieren und die Zeile Mail Flow Rules öffnen. View Details zeigt Domain, Zeitpunkt, betroffenes Objekt und konkrete Änderung.

  • Bekannte Umbenennung einer Verteilerliste: Prüfen, ob der neue Gruppenname nach Sophos Fusion synchronisiert wurde. Den Gruppennamen anschliessend in den M365-Domaineinstellungen aktualisieren und speichern.
  • Bekannte, beabsichtigte Änderung: Änderung dokumentieren und Run a Quick Test ausführen. Nur bei erfolgreichem Test beibehalten.
  • Unbekannte oder unbeabsichtigte Änderung: Zuerst das Microsoft-365-Änderungsprotokoll und den Owner klären. Eine verstandene Fehländerung in Microsoft 365 zurücknehmen und danach den Quick Test ausführen. Ist die Reparatur unklar oder schlägt der Test fehl, Reconnect verwenden; Sophos erstellt beziehungsweise aktiviert fehlende oder deaktivierte Objekte erneut.

Eine Warnung beweist allein noch keinen unterbrochenen Mailfluss. Umgekehrt darf ein beabsichtigter Change nicht allein deshalb akzeptiert werden, weil er bekannt ist: Entscheidend sind Quick Test und Zustelltests.

3. SPF-Fehler nach dem Rückweg zu Microsoft 365 beheben

In Mailflow laufen ausgehende Nachrichten von Microsoft 365 zu Sophos und wieder zu Microsoft 365. Deshalb kann Microsoft die SPF-Prüfung ablehnen, wenn der regionale Sophos-Absender nicht im SPF-Record der Domain autorisiert ist.

Ein bestehender Record kann so aussehen:

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

Er wird um genau die für den eigenen Sophos-Central-Datenstandort ausgewiesene Include-Domain ergänzt:

v=spf1 include:spf.protection.outlook.com include:<sophos-spf-domain> -all

<sophos-spf-domain> ist ein Platzhalter, kein veröffentlichbarer Wert. Man übernimmt den aktuellen regionalen Wert aus den Sophos Email domain information, hält nur einen SPF-TXT-Record pro Domain und verändert den abschliessenden Mechanismus nicht ungeprüft. Nach der DNS-Propagation kontrolliert man den veröffentlichten TXT-Wert und sendet eine ausgehende Testnachricht. In den empfangenen Headern muss SPF für den erwarteten Pfad bestehen.

4. Weiterleitungen und Microsoft DLP korrigieren

Extern automatisch weitergeleitete Nachricht wird abgelehnt

Microsoft 365 schreibt bei externer automatischer Weiterleitung die Envelope-From-Adresse (P1 From) mit SRS um. Bleibt im Header-From eine externe, in Sophos Email nicht konfigurierte Domain, kann Sophos die ausgehende Nachricht mit dem Hinweis ablehnen, dass die Header-From-Domain nicht konfiguriert ist. Sophos leitet solche extern stammenden Nachrichten nicht pauschal weiter, weil eine generelle Freigabe ein Open-Relay-ähnliches Risiko und Reputationsschäden schaffen würde.

  1. Im Microsoft 365 Security Center Policies & rules > Threat policies > Rules > Enhanced filtering öffnen.
  2. Den Connector auswählen, der eingehende Nachrichten von Sophos Email zulässt.
  3. Automatically detect and skip the last IP address einschalten und auf die Organisation anwenden.
  4. Die betroffene ausgehende Weiterleitung so konfigurieren, dass sie als Absender eine lokale Mailbox der geschützten Domain verwendet.
  5. Den Test mit demselben ursprünglichen Absender und Ziel wiederholen und Header, Message Trace und Message History vergleichen.

Man behebt diesen Fall nicht, indem man beliebige externe Domains in Sophos hinzufügt oder eine breite Relay-Ausnahme erstellt.

Microsoft DLP sendet Benachrichtigungen doppelt

Wenn eine Microsoft-DLP-Regel beim Hin- und Rückweg durch Mailflow zweimal auslöst, nimmt man die dokumentierten Sophos-Email-Absender-IP-Adressen gezielt von dieser Microsoft-Regel aus:

  1. Im Microsoft Purview DLP-Portal als Microsoft-365-Administrator anmelden.
  2. Die betroffene Policy und unter Advanced DLP rules > Customize advanced DLP rules die auslösende Regel bearbeiten.
  3. Add exception > Except if sender IP address is wählen und ausschliesslich die aktuellen regionalen Sophos-IP-Adressen aus den oben verlinkten Domaininformationen eintragen.
  4. Speichern und den Schritt für jede tatsächlich betroffene DLP-Regel wiederholen.
  5. Mit einer kontrollierten Nachricht prüfen, dass die gewünschte DLP-Auswertung erhalten bleibt, aber nur eine Benachrichtigung entsteht.

Die Ausnahme wird nicht auf unnötige Adressbereiche erweitert. So bleibt DLP für andere Absenderpfade wirksam.

5. Fehler 552 und Signaturdienste untersuchen

Das typische NDR lautet:

552 5.6.0 Headers too large (32768 max)

Zuerst öffnet man die vollständigen Header. Doppelte Gruppen wie X-Sophos-Antispam, X-LASED-Hits, X-Microsoft-Antispam-Message-Info oder X-Microsoft-Antispam-Message-Info-Original sprechen für mehrfache Verarbeitung. Bei CodeTwo oder Exclaimer entsteht sie häufig durch diesen falschen Weg:

Microsoft 365 > Sophos > Microsoft 365 > signature service > Microsoft 365 > Sophos > Microsoft 365 > recipient

Der dauerhafte Zielpfad verarbeitet die Nachricht in jedem externen Dienst nur einmal:

Microsoft 365 > signature service > Microsoft 365 > Sophos > recipient

Dazu prüft man in Microsoft 365 die Connectors und Regeln des Signaturdienstes und von Sophos. Der CodeTwo-/Exclaimer-Pfad muss vor dem Sophos-Outbound-Pfad greifen; überlappende Regeln, die nach der Rückgabe erneut zu Sophos führen, werden entfernt oder eingegrenzt. Die genaue Drittanbieterregel richtet man nach dessen aktuellem Best-Practice-Verfahren ein. Anschliessend belegt man mit Message Trace und Headern genau einen Signatur- und einen Sophos-Durchlauf.

Begrenzter Workaround, wenn keine Routing-Schleife vorliegt

Ist keine doppelte Route vorhanden und wird die Grenze dennoch durch einen grossen Microsoft-Diagnoseheader überschritten, kann man in Exchange Admin Center unter Mail flow > Rules eine Regel erstellen:

  • Apply this rule if: A message header > includes any of these words; Header X-Sophos-Email-ID, enthaltenes Wort True.
  • Do the following: Modify the message properties > remove a message header; Header X-Microsoft-Exchange-Diagnostics-untrusted.
  • Die übrigen Werte bleiben auf Standard. Die Regel wird nach den Sophos-Email-Prefilter- und Redirect-Regeln angeordnet. Bei deren Standardprioritäten 0, 1 und 2 erhält sie Priorität 3.

Vorher exportiert oder dokumentiert man die Regelreihenfolge. Nachher testet man eine betroffene und eine normale Nachricht. Diese Regel reduziert Headerdaten und ist kein Ersatz für die Korrektur einer Schleife. Auch das Entfernen grosser Microsoft-Header in Sophos mit dem regulären Ausdruck .* ist nur ein temporärer Workaround; bei doppelten Sophos-Headern wird stattdessen das Routing repariert.

Erwartetes Verhalten: Sensitivity Labels erscheinen zweimal

Bei ausgehenden Nachrichten kann Microsoft 365 dasselbe Sensitivity Label zweimal anwenden. Microsoft sendet die Nachricht zuerst zur Sophos-Prüfung und nach der Rückgabe zum Empfänger; die Label-Verarbeitung erfolgt auf beiden Tenant-Durchläufen. Wenn Message Trace genau diesen vorgesehenen Weg ohne Schleife zeigt, ist die doppelte Kennzeichnung erwartetes Mailflow-Verhalten und kein Beleg für eine zweite Sophos-Prüfung. Man ändert deshalb nicht allein wegen zweier Labels die Connectors.

Validierung, Rückweg und Eskalation

Eine Reparatur ist erst abgeschlossen, wenn:

  • die Domain in M365 Mailflow Domains wieder Connected zeigt und der Quick Test erfolgreich ist;
  • eine eingehende und eine ausgehende Kontrollnachricht in Microsoft Message Trace und Sophos Message History zusammenpassen und zugestellt wurden;
  • Header nur die erwartete Zahl an Sophos-, Microsoft- und Signaturdurchläufen zeigen;
  • SPF besteht und Weiterleitungs- beziehungsweise DLP-Tests genau das erwartete Ergebnis liefern;
  • keine neuen High- oder Medium-Mailflow-Warnungen auftreten.

Für einen bewussten manuellen Rückweg trennt man die Domain in M365 Mailflow Domains, indem man beim Status Connected auf das Kreuz klickt. Sophos entfernt dann die für diese Domain angelegten Apps, Connectors und Regeln; das kann einige Minuten dauern. Vor dem erneuten Verbinden prüft man im Microsoft Entra Admin Center unter App registrations, im Exchange Admin Center unter Mail flow > Rules und Mail flow > Connectors, ob die domainbezogenen Sophos-Objekte wirklich entfernt wurden. Danach verbindet man die Domain mit gültiger Zustimmung neu.

Gateway-RBL vor der Mailflow-Erkennung unterscheiden

Wird eine eingehende Nachricht abgelehnt, zeigt das Sophos-Gateway-Protokoll eine RBL-Ablehnung, aber Sophos Message History kein entsprechendes Mailflow-Ereignis, kann die noch aktive Gateway-Verbindung ihre Real-time Block List angewendet haben, bevor Sophos die Mailflow-Verbindung erkennen und die Nachricht weiterleiten konnte. Man korreliert dieselbe Nachricht und denselben UTC-Zeitpunkt im Gateway-Protokoll, in Microsoft Message Trace und in der Mailflow Message History. Das fehlende Mailflow-Ereignis ist in diesem Muster kein Beweis für einen Fehler des Mailflow-Connectors.

Eine RBL wird deshalb nicht breit umgangen oder global deaktiviert. Man verlängert auch nicht den Parallelbetrieb: Sobald Mailflow ein- und ausgehend validiert ist, entfernt man die alte Gateway-Verbindung gemäss dem Migrationsplan umgehend.

Dieser Rückweg ist ein kontrollierter Reparaturschritt, kein spontanes Aufräumen. Wenn die Domain produktive Nachrichten verarbeitet, legt man vorher Wartungsfenster, alternative Route und Abbruchkriterium fest. Bei einer Gateway-zu-Mailflow-Umstellung bleibt der dokumentierte Gateway-Pfad nur als geplanter Rückweg bestehen; Gateway und Mailflow dürfen die gleiche Domain nicht gleichzeitig produktiv über Sophos führen, weil sonst doppelte Scans und Routing-Schleifen drohen. Bleiben Objekte zurück, ist ihre Zuordnung unklar oder scheitert Reconnect trotz korrekter Berechtigungen, stoppt man manuelle Änderungen und übergibt Domain, Message-IDs, UTC-Zeiten, Header, Traces, Quick-Test-Ergebnis und Objektinventar an Sophos Support.