Sophos Email Gateway mit Exchange On-Premises einrichten

Bei Exchange On-Premises besteht der Mailflow aus zwei getrennten Wegen: Eingehende Nachrichten erreichen zuerst die regionalen Sophos-MX-Ziele und werden danach an Exchange zugestellt. Ausgehende Nachrichten sendet Exchange über den regionalen Sophos-Smart-Host. Beide Richtungen müssen separat konfiguriert und getestet werden.

Diese Anleitung gilt nicht für Microsoft 365 und nicht für die automatische Connector-Verwaltung von Sophos Mailflow. Ein lokaler Exchange Server benötigt eigene Receive- und Send-Connectoren; Microsoft-365-Connectoren dürfen dafür nicht nachgebaut werden.

Schnellablauf: Bestandswerte und Rückweg sichern, die Domain in Sophos Fusion (ehemals Sophos Central) für Inbound and Outbound konfigurieren, den Exchange-Empfang auf die regionalen Sophos-Zustell-IP-Adressen begrenzen, einen Send Connector zum kopierten Outbound Relay Host einrichten, beide Richtungen nachverfolgen und erst danach alte Filterrouten deaktivieren.

Eingaben und Rückweg vorbereiten

Vor der Änderung werden folgende Werte im Change dokumentiert:

Maildomain, zum Beispiel example.org, und alle zu schützenden Empfänger;
öffentlich erreichbares Exchange-Ziel als FQDN oder IP-Adresse, zum Beispiel mail.example.org, sowie der tatsächlich verwendete SMTP-Port;
öffentliche Quell-IP-Adressen oder CIDR-Netze, über die Exchange ausgehend sendet, zum Beispiel die zu ersetzende Dokumentationsadresse 192.0.2.25/32;
regionale Sophos-MX-Ziele, Zustell-IP-Adressen, Outbound Relay Host und SPF-Domain aus den aktuellen externen Abhängigkeiten des eigenen Tenants;
vorhandene Receive- und Send-Connectoren, deren Geltungsbereiche und Priorität sowie Firewall- und NAT-Regeln;
bisherige MX- und SPF-Werte samt TTL.

Die Sophos-Werte sind regionsabhängig. Man übernimmt sie aus dem eigenen Sophos-Fusion-Tenant und verwendet die aktuellen Sophos-Listen für Gateway-Zustell-IP-Adressen, MX-Records, ausgehende Relay-Hosts und SPF-Domains. Der Tenant zeigt das Relay zudem unter Gateway Domains > Domain > Configure External Dependencies > Outbound Settings. Vor dem Pilot bleiben alte DNS-Werte und Connector-Einstellungen als geprüfter Rückweg verfügbar. Die DNS-TTL senkt man rechtzeitig vor der MX-Umstellung. Laut Sophos können Connector-Änderungen bis zu 24 Stunden zur Propagation benötigen; ein Soforttest beweist daher noch keine vollständige Propagation.

Domain und eingehenden Weg konfigurieren

Sophos Gateway vorbereiten

In Sophos Fusion zu Global Settings > Products and Services > Email > Gateway Domains gehen und die Domain hinzufügen oder öffnen.
Domain, Verkehrsrichtung sowie Zustellziel und dessen SMTP-Port eintragen. Für den vollständigen Ablauf wird die Richtung Inbound and Outbound benötigt.
Verify Domain Ownership wählen, den angezeigten domainspezifischen TXT-Wert als TXT-Record an der Domainwurzel veröffentlichen und danach Verify ausführen. Als Name verwendet man den angezeigten Namen oder @.
Erst weiterarbeiten, wenn Sophos die Domain-Verifizierung bestätigt. Eine fehlgeschlagene Prüfung bedeutet meist, dass der TXT-Wert falsch ist oder DNS noch nicht propagiert wurde.
Die tatsächlich geschützten Mailboxen in Sophos Email anlegen oder synchronisieren.

Das Zustellziel ist der öffentlich erreichbare Exchange-Endpunkt, nicht der Sophos-MX-Name. Sein FQDN beziehungsweise seine IP-Adresse und der Port müssen genau zum veröffentlichten SMTP-Dienst und zur Firewall-Weiterleitung passen.

Exchange-Empfang einschränken

Auf Firewall und Exchange-Receive-Pfad werden ausschliesslich die regionalen Sophos-Zustell-IP-Adressen als Quelle für den Sophos-Zustellweg zugelassen. Die konkreten Adressen stammen aus den aktuellen externen Abhängigkeiten des Tenants. Fehlt eine davon, kann Sophos nicht zustellen; ein fremdes oder zu breites Netz schwächt die Umgehungssperre.

Beim für Sophos verwendeten Exchange Receive Connector setzt man die lokale Bindung auf die vorgesehene lokale Exchange-IP-Adresse und den Listening-Port; getrennt davon begrenzt man die Remote-IP-Bereiche ausschliesslich auf die regionalen Sophos-Zustell-IP-Adressen und verwendet nicht 0.0.0.0/0. Die normale Annahme für Empfänger in akzeptierten Exchange-Domains ist von einer SMTP-Relay-Berechtigung zu unterscheiden: Dafür ist kein allgemeines Relay-Recht nötig und dieser Connector darf keines erhalten. Überlappen mehrere Receive Connectoren, muss vor dem Cutover klar sein, welcher Connector für jede Sophos-Quelladresse greift.

Zuerst prüft man die Erreichbarkeit dieses Weges, ohne den alten Schutzpfad zu entfernen. Danach ersetzt man beim DNS-Provider die MX-Records durch die regionalen Sophos-MX-Ziele. Schreibweise, Priorität und Region müssen exakt den Tenant-Angaben entsprechen.

Ausgehenden Weg über Sophos konfigurieren

Ausgehende Quelle in Sophos autorisieren

Die Domain unter Gateway Domains öffnen und Edit wählen.
In Configure Domain die Richtung Inbound and Outbound bestätigen.
Unter Outbound Gateway die Option Custom Gateway wählen.
Mindestens eine öffentliche IP-Adresse oder ein CIDR-Netz hinzufügen, von dem Sophos die ausgehenden Verbindungen tatsächlich sieht, und speichern. Private Exchange-Adressen hinter NAT sind hier nicht die sichtbare Quelle.
Configure External Dependencies > Outbound Settings öffnen und den regionsabhängigen Outbound Relay Host kopieren.

Die Quellbereiche werden so eng wie möglich gewählt. Ein unnötig grosses CIDR kann fremde Systeme als Absender autorisieren; eine falsche NAT-Adresse führt dagegen zu Relay-Ablehnungen.

Exchange Send Connector umstellen

Auf Exchange richtet man für Internetempfänger einen SMTP Send Connector ein, wählt Route mail through smart hosts und fügt mit Add genau den kopierten Outbound Relay Host hinzu. Jeder Exchange-Regler hat eine eigene Bedeutung: Adressräume bestimmen die gerouteten Empfängerdomains; Quell-Transportserver sind die Exchange-Server, auf denen der Connector gehostet wird – für diesen Connector ausgewählte Nachrichten werden zu einem von ihnen geroutet, der die Zustellung an den Smart Host herstellt; Kosten entscheiden zwischen gleich spezifischen passenden Adressräumen; und die Scoped-Einstellung begrenzt die Verfügbarkeit in der Exchange-Topologie auf den Active-Directory-Standort, nicht das Empfängerrouting. Massgeblich sind Microsofts Anleitungen für Exchange 2019, Exchange 2016 oder Exchange 2013.

Während Abnahme und Cutover deaktiviert man jeden alten Filter-Send-Connector, dessen Adressräume den Sophos-Connector überlappen, unabhängig von seiner Quellserverliste; seine dokumentierte Konfiguration, nicht eine aktiv konkurrierende Route, bleibt für den Rollback erhalten. Müssen in einem Pilot beide aktiviert bleiben, erhalten sie tatsächlich nicht überlappende Adressräume. Getrennte Quellserverlisten teilen Nachrichten nicht nach ihrem ursprünglichen Exchange-Server auf und bieten keine sichere Isolation. Kosten allein genügen nicht, da Exchange zuerst die Adressraum-Spezifität auswertet. Nach erfolgreichem Test bleibt der alte überlappende Connector deaktiviert oder wird entfernt.

SPF, DKIM und beide Richtungen prüfen

Wenn Sophos ausgehend zustellt, aktualisiert man den vorhandenen einen SPF-TXT-Record mit dem regionalen Wert aus der verlinkten Sophos-SPF-Liste. Ein reiner Sophos-Ersatz hat exakt die Platzhalterform v=spf1 include:<spf-domain> -all. Im Parallelbetrieb bleiben alle bisherigen autorisierten Mechanismen erhalten und include:<spf-domain> wird vor dem einzigen abschliessenden all eingefügt, zum Beispiel v=spf1 include:old.example include:<spf-domain> -all. <spf-domain> ist durch den Regionalwert zu ersetzen; der Platzhalter, ein zweites abschliessendes all oder ein zweiter SPF-Record dürfen nie veröffentlicht werden. -all verwendet man, wenn nachweislich jeder tatsächliche Absender im einen Record erfasst ist, andernfalls ~all. Entscheidend ist die Absenderabdeckung, nicht ob Sophos der einzige Weg ist. DKIM wird separat geprüft.

Für die Abnahme verwendet man eindeutige Betreffzeilen und notiert Absender, Empfänger und Uhrzeit:

Eingehend: Von einer externen Domain an eine geschützte Mailbox senden. In Sophos Fusion unter Reports > Message History muss die Nachricht erscheinen; anschliessend muss sie in der Exchange-Nachrichtenverfolgung und im Zielpostfach sichtbar sein.
Ausgehend: Von einer geschützten Mailbox an eine externe Domain senden. In Message History die Richtung auf outbound stellen und den Eintrag prüfen; danach Annahme beim externen Empfänger und die Exchange-Nachrichtenverfolgung kontrollieren.
Umgehung und Relay: Eine direkte Zustellung an Exchange aus einer nicht autorisierten Quelle sowie ein Relay-Versuch zu einer fremden Domain dürfen über den eingeschränkten Sophos-Receive-Pfad nicht zugelassen werden.

Ein Eintrag nur in einem System ist noch kein Ende-zu-Ende-Erfolg. Die Zeitstempel und Message-ID verbinden Exchange-Verfolgung, Sophos-Verlauf und Empfängerergebnis.

Fehler gezielt eingrenzen

Eingehend fehlt bereits in Sophos: MX-Ziele, Priorität, DNS-Propagation und Region prüfen. Ein alter MX kann weiterhin Verkehr am Gateway vorbeiführen.
In Sophos sichtbar, nicht in Exchange: Zustellziel und Port, Firewall/NAT, regionale Sophos-Zustell-IP-Adressen, Receive-Connector-Geltungsbereich und Exchange-Warteschlangen prüfen. Eine unbekannte Mailbox in Sophos ist ebenfalls auszuschliessen.
Ausgehend bleibt in Exchange hängen: DNS-Auflösung und Erreichbarkeit des kopierten Outbound Relay Host, den gewählten Send Connector, dessen Quellserver sowie Exchange-Warteschlangen prüfen.
Relay wird abgelehnt: Ermitteln, welche öffentliche Quell-IP Sophos tatsächlich sieht, und sie mit den unter Custom Gateway hinterlegten IP/CIDR-Werten vergleichen. Den Bereich nicht pauschal erweitern.
TLS schlägt fehl: Namen des Smart Hosts und Zustellziels, Zertifikatskette, Gültigkeit, Namensübereinstimmung und die auf beiden Seiten unterstützte TLS-Aushandlung prüfen. TLS nicht dauerhaft abschalten, um einen Namens- oder Zertifikatsfehler zu verdecken.
Ein Teil der Nachrichten nimmt den alten Weg oder läuft im Kreis: Überlappende Send-Connector-Adressräume, Kosten/Präzedenz und alte Filter-Connectoren prüfen. Auch alte MX-Ziele und vorgelagerte Relays können eine Schleife erzeugen.

Nach jeder Korrektur wiederholt man genau den betroffenen Richtungstest und vergleicht neue Zeitstempel. Bei weiterhin ausbleibendem Flow sichert man Message-ID, Zeitfenster, Connector-Zustand, Queue-Fehler und den passenden Sophos-Message-History-Eintrag für die Eskalation.

Sicher zurückrollen

Beim Rollback wird nur die fehlerhafte Richtung zurückgenommen. Für eingehende Störungen setzt man die gesicherten bisherigen MX-Werte zurück und lässt den bisherigen Empfangspfad aktiv, bis DNS propagiert ist. Für ausgehende Störungen führt man zuerst die gesicherten bisherigen Absendermechanismen in dem einzigen SPF-Eintrag der Domain wieder zusammen, behält dabei include:<spf-domain> vorübergehend bei und berücksichtigt die DNS-Propagation gemäss Änderungsplan. Danach aktiviert man den bekannten bisherigen Send Connector wieder und deaktiviert den neuen Sophos Send Connector eindeutig, damit keine konkurrierenden Routen entstehen.

Firewall- und Receive-Connector-Anpassungen entfernt man erst, wenn der wiederhergestellte Empfangspfad nachweislich funktioniert. include:<spf-domain> entfernt man erst nach der Validierung der wiederhergestellten ausgehenden Route aus dem einzigen SPF-Eintrag der Domain; die wiederhergestellten Absendermechanismen bleiben dabei erhalten. Anschliessend testet man erneut eingehend und ausgehend, kontrolliert beide Warteschlangen und dokumentiert verbliebene DNS-Caches. So wird ein Teil-Rollback nicht selbst zum offenen Relay oder zu einer zweiten, unkontrollierten Versandroute.