Sophos Email Gateway mit Microsoft 365 einrichten

Bei Sophos Gateway zeigt der öffentliche MX-Eintrag auf Sophos. Sophos prüft eingehende Nachrichten und stellt sie über einen abgesicherten Partner-Connector an Exchange Online zu. Ausgehende Nachrichten sendet Microsoft 365 über einen zweiten Connector an den Sophos Smart Host.

Sicherer Schnellablauf: Zuerst Domain, Empfänger, Microsoft-Ziel und Rückweg dokumentieren. Dann den eingehenden Connector samt TLS- und IP-Einschränkung sowie die Regeln vorbereiten. Anschliessend den ausgehenden Connector erstellen und erfolgreich validieren. Erst danach schaltet man MX und ausgehende Route um. SPF wird passend zum tatsächlich aktiven Versandweg geändert, nicht vorauseilend.

Diese Anleitung gilt für manuell eingerichtete Gateway-Connectors unter Gateway Domains. Sophos Mailflow ist eine andere Architektur: Sophos verwaltet dort Anwendungen, Connectors und Mailflow-Regeln über Microsoft APIs. Man mischt beide Verfahren für dieselbe Domain nicht; sonst drohen doppelte Prüfung und Schleifen.

Voraussetzungen und Werte vorbereiten

Man benötigt Exchange-Administratorrechte, DNS-Zugriff, eine Sophos-Email-Lizenz und eine bereits geplante Gateway-Domain. Vor Änderungen exportiert oder protokolliert man bestehende MX-, SPF-, Connector- und Mailflow-Regelwerte samt Priorität und Status.

In Sophos Fusion (ehemals Sophos Central) öffnet man Global Settings > Products and Services > Email > Gateway Domains und erfasst beziehungsweise prüft:

die eigene E-Mail-Domain;
als Zustellziel den in Microsoft 365 unter Domains angezeigten erwarteten MX-FQDN der Domain;
den tatsächlich verwendeten SMTP-Port;
den domainspezifischen TXT-Wert aus Verify Domain Ownership;
alle zu schützenden Mailboxen und Aliase.

Die Wertquellen sind zu trennen: Der Zustellziel-FQDN stammt aus Domains im eigenen Microsoft-365-Tenant, und Verify Domain Ownership erzeugt den TXT-Wert für diese Domain. Sophos veröffentlicht die veränderlichen regionalen Werte in der Delivery-IP-Tabelle, MX-Tabelle und SPF-Tabelle. Den Outbound Relay Host kopiert man aus den externen Abhängigkeiten der Domain in Sophos Fusion. Werte anderer Regionen oder Beispiele gehören nicht in die Produktion. Bei neuen Gateway-Testkonten kann ausgehendes Routing standardmässig deaktiviert sein; falls benötigt, lässt man es durch den Sophos-Partner oder Vertrieb freischalten.

1. Eingehenden Weg vor dem MX-Wechsel absichern

Partner-Connector erstellen

In Exchange admin center > Mail flow > Connectors legt man einen Connector mit diesen Werten an:

From: Partner organization; To: Office 365.
Ein eindeutiger Name, zum Beispiel Sophos Email Inbound Connector.
Use the sender’s domain und als Senderdomain *.
Reject email messages if they aren’t sent over TLS aktivieren.
Reject email messages if they aren’t sent from within this IP address range aktivieren und nur die aktuellen Sophos-Delivery-IP-Adressen der eigenen Central-Region eintragen.
Einstellungen prüfen, speichern und den Connector aktivieren, sobald die restlichen Schutzschritte bereit sind.

Zusätzlich trägt man dieselben aktuellen Sophos-Delivery-IPs im Microsoft 365 Defender Portal in die standardmässige Connection-Filter-Policy ein. Dieser Eintrag kennzeichnet die Sophos-Quellen für den Filter; eine IP Allow List schliesst keinen direkten Zustellweg. Den zulässigen eingehenden Pfad erzwingt der aktivierte Partner-Connector, weil er für die Senderdomain * gilt, TLS verlangt und die Zustellung auf diese Sophos-IPs beschränkt.

Enhanced Filtering und EOP-Bypass konfigurieren

Auf genau diesem eingehenden Partner-Connector aktiviert man Enhanced Filtering for Connectors (auch Skip listing genannt). Ohne diese Einstellung kann Microsoft 365 den ursprünglichen Absender hinter Sophos falsch klassifizieren.

Danach erstellt man unter Mail flow > Rules die Transportregel:

Name: Sophos Email EOP Bypass.
Apply this rule if: Apply to all messages.
Do the following: Modify the message properties > Set the spam confidence level (SCL) auf -1.
Keine Ausnahme hinzufügen; Modus Enforce, Severity: Low.
Regel speichern und einschalten.

Diese breite SCL-Regel ist nur vertretbar, wenn MX, TLS- und IP-Einschränkung sicherstellen, dass Internet-Mail ausschliesslich nach der Sophos-Prüfung eintrifft. Existiert noch ein direkter oder dritter eingehender Pfad, stoppt man den Cutover und schliesst diese Lücke zuerst.

2. Ausgehenden Connector über Sophos erstellen

In Gateway Domains wählt man die Domain, setzt Direction auf Inbound and Outbound, wählt unter Outbound Gateway Microsoft Office 365 und speichert. Unter Configure External Dependencies > Outbound Settings kopiert man den angezeigten Outbound Relay Host.

Danach erstellt man in Exchange admin center > Mail flow > Connectors:

From: Office 365; To: Partner organization.
Einen eindeutigen Namen, zum Beispiel Sophos Email Outbound Connector, und Turn it on.
Only when email messages are sent to these domains mit *, wenn sämtlicher externer Versand über Sophos laufen soll.
Route email through these smart hosts und exakt den zuvor kopierten Outbound Relay Host.
Always use Transport Layer Security (TLS) to secure the connection und die dokumentierte Option Any digital certificate, including self-signed certificates.
Eine Adresse in einer externen Domain angeben und Validate ausführen. Nur nach erfolgreicher Validierung speichern.

Andere ausgehende Connectors deaktiviert oder entfernt man erst, nachdem der Sophos-Connector validiert ist. Spezialwege, etwa für Archivierung, werden nicht pauschal abgeschaltet; man prüft ihren Scope und ihre Priorität einzeln. Änderungen können verzögert wirksam werden.

Für Microsoft 365 GCC High verwendet man in Sophos nicht die Standardauswahl Microsoft Office 365, wenn ausgehende Nachrichten dadurch abgewiesen werden. Man wählt Custom Gateway und übernimmt die erforderlichen Subnetze aus Microsofts aktuellen GCC-High-Endpunkten für Exchange Online. IP-Bereiche werden nicht aus alten Listen übernommen.

3. DNS und Routing kontrolliert umschalten

Vor dem Wartungsfenster reduziert man die DNS-TTL rechtzeitig und hält die ursprünglichen Werte fest. Dann gilt diese Reihenfolge:

Enhanced Filtering und den Connection-Filter-Eintrag prüfen. Zuerst den eingehenden Partner-Connector aktivieren und bestätigen, dass Senderdomain *, TLS und die Sophos-Delivery-IP-Beschränkung aktiv sind; unmittelbar vor dem MX-Wechsel die SCL-Regel aktivieren.
Öffentliche MX-Einträge auf die aktuellen Namen aus der regionalen Sophos-MX-Tabelle ändern. Eine eindeutig erkennbare Nachricht von einem externen Konto an eine geschützte Mailbox senden und exakt diese Nachricht sowohl im Microsoft 365 Message Trace als auch in Sophos Message History bestätigen.
Den ausgehenden Sophos-Connector validieren und den dokumentierten bisherigen Connector für den Rollback aufbewahren. Danach das Produktionsrouting bewusst umstellen: Den Sophos-Connector mit Empfängerscope * aktiviert lassen und jeden überlappenden Standard-Outbound-Connector deaktivieren. Spezialwege wie Archivierung separat prüfen.
Erst nach diesem Status-/Scope-Wechsel eine eindeutig erkennbare Nachricht aus Microsoft 365 an eine kontrollierte externe Adresse senden. Exakt diese Nachricht im Microsoft 365 Message Trace und in der ausgehenden Ansicht von Sophos Message History bestätigen. Ein vor der Umschaltung gesendeter Test belegt den Sophos-Weg nicht.

Für SPF veröffentlicht man genau einen SPF-TXT-Record. Während Microsoft 365 und Sophos nachweislich parallel senden, ergänzt man im bestehenden Record den aktuellen regionalen Sophos-Include. Sobald nur noch Sophos versendet, kann der Microsoft-Include entfernt werden. -all verwendet man erst, wenn wirklich jede legitime Quelle erfasst und über Sophos geführt ist; während einer kontrollierten Übergangsphase ist ~all weniger störanfällig. DKIM-Signierung und Alignment prüft man nach der Umstellung ebenfalls, weil ein korrekter Transportweg allein keine Absenderauthentifizierung garantiert.

Validierung und Rollback

Für jede Domain testet man eingehend und ausgehend mit einer kontrollierten externen Adresse. Im Microsoft 365 Message Trace prüft man erwarteten Absender, Empfänger, Zeitpunkt, Message-ID, Zustellstatus und endgültige Zustellung; der gewöhnliche Message Trace dient hier nicht als Nachweis der Connector- oder Regelverarbeitung. In Sophos Fusion öffnet man Reports > Message History, prüft beide Richtungen und ordnet diese Angaben exakt denselben Testnachrichten zu. Der Cutover ist erst abgeschlossen, wenn beide Systeme jeden Test nach der Umschaltung enthalten.

Bei unzustellbaren Nachrichten oder einer Schleife führt man den vorbereiteten Rückweg aus, statt weitere Regeln hinzuzufügen:

Für ausgehende Mail den vorherigen funktionierenden Connector wieder aktivieren und danach den Sophos-Outbound-Connector deaktivieren, bevor man einen Rollback-Test sendet. Die externe Zustellung erst nach diesem Statuswechsel bestätigen.
Für eingehende Mail zuerst die breite Sophos-spezifische SCL-Regel und den auf Sophos-IPs beschränkten Inbound-Connector deaktivieren sowie die Sophos-Einträge aus dem Connection Filter entfernen. Erst danach den ursprünglichen Microsoft-MX wiederherstellen. Die DNS-Propagation berücksichtigen: Die autoritative MX-Antwort prüfen und kontrollierte externe Zustelltests wiederholen, bis sie den wiederhergestellten Weg verwenden.
SPF erst an den wieder tatsächlich sendenden Weg anpassen.
Nichts löschen, bis DNS-Propagation, Warteschlangen und beide Traces geprüft sind.

Fehler gezielt eingrenzen

Eingehend erscheint nur bei Sophos: Ziel-FQDN, SMTP-Port, Mailboxbestand, aktuelle Delivery IPs und TLS-Aushandlung des Partner-Connectors prüfen.
Eingehend erreicht Microsoft direkt: MX-Propagation und alternative MX-/Weiterleitungswege prüfen. Eine SCL-Regel darf einen ungeschützten Direktpfad nicht kaschieren.
Ausgehend umgeht Sophos: Connector-Scope *, Status sowie konkurrierende Connectors und deren Vorrang kontrollieren.
Connector-Validierung scheitert: Den Relay Host erneut aus Sophos Fusion kopieren, TLS-Einstellung prüfen und eine wirklich externe Testadresse verwenden.
SPF schlägt fehl: Nach tatsächlichen Absendern suchen, auf mehrere SPF-Records, falschen regionalen Include oder ein verfrühtes -all prüfen.
GCC-High-Mail wird abgewiesen: Custom Gateway und die aktuell veröffentlichten GCC-High-Exchange-Online-Subnetze kontrollieren.
Nachrichten laufen im Kreis oder werden doppelt geprüft: Gateway- und API-verwaltete Mailflow-Connectors, alte Smart Hosts, Weiterleitungen und Mailflow-Regelprioritäten gemeinsam prüfen. Den zuletzt aktivierten Pfad deaktivieren und erneut in beiden Traces testen.

Bei einer Eskalation sammelt man Zeitstempel, Sender, Empfänger, Message-ID, Connector-Namen, Regelprioritäten sowie die passenden Einträge aus Message Trace und Message History. So lässt sich ein Routingfehler untersuchen, ohne den Schutz durch eine breite Ausnahme zu schwächen.