Sophos Email: Gateway-Domänen, DKIM und SMTP-Routing einrichten

Eine Gateway-Domäne ist erst produktionsbereit, wenn Eigentum, eingehendes Ziel, ausgehende Quelle und die DNS-Abhängigkeiten zusammenpassen. Am sichersten arbeitet man in dieser Reihenfolge: Ausgangszustand sichern, Domain verifizieren, interne Ziele konfigurieren, die für die eigene Sophos-Fusion-Region angezeigten MX- und SPF-Daten übernehmen, beide Mailrichtungen testen und erst danach BATV, DKIM oder eine benutzerdefinierte ausgehende Route aktivieren.

Schnellweg: Unter Products and Services > Email > Gateway Domains die Domain hinzufügen und den angezeigten Ownership-TXT-Eintrag verifizieren. Danach Ziele, Gateways und Port festlegen, speichern und Configure External Dependencies abarbeiten. Für DKIM einen 2048-Bit-Schlüssel erzeugen, den generierten Selector-TXT-Eintrag publizieren, mit Test record prüfen und erst dann aktivieren. Eine Route zu einem nachgelagerten SMTP-System richtet man getrennt unter Custom SMTP Routing ein und testet sie mit einer ausgehenden Nachricht.

Geltungsbereich und sichere Vorbereitung

Diese Anleitung gilt ausschliesslich für Sophos Email Gateway in Sophos Fusion (ehemals Sophos Central). Für dieselbe Domain sollte man nicht gleichzeitig Gateway und Mailflow verwenden, weil dies doppelte Einträge in Message History erzeugen kann. Custom SMTP Routing verarbeitet nur ausgehende Gateway-Nachrichten, ist bei aktiviertem EMS-Modus nicht verfügbar und wird bei Sophos Email Mailflow in Microsoft 365 konfiguriert. On-Box Mail Protection einer Sophos Firewall ist ebenfalls ein anderes Produkt.

Falls die Architektur noch nicht verbindlich gewählt wurde, zuerst Sophos Email: Architektur wählen und Onboarding planen verwenden. Vor der Änderung hält man pro Domain fest:

aktuelle MX-, SPF- und DKIM-Einträge einschliesslich TTL;
bisheriges eingehendes Ziel, ausgehende Gateways, erlaubte Quellnetze und SMTP-Ports;
alle Systeme, die mit der Domain direkt versenden, sowie Weiterleitungen und Relays;
Owner für Sophos Fusion, DNS, Firewall und nachgelagerten Mailserver;
Testempfänger, Change-Fenster, Abbruchkriterium und freigegebenen Rückweg.

Man senkt eine hohe DNS-TTL rechtzeitig nach dem eigenen Change-Verfahren. Ein alter Pfad wird erst entfernt, wenn eingehende und ausgehende Tests über den neuen Pfad erfolgreich sind.

Gateway-Domäne hinzufügen und Eigentum verifizieren

In Sophos Fusion das Symbol Global Settings öffnen und Products and Services > Email > Gateway Domains wählen.
Add Domain anklicken und unter Email Domain die eigene Domain eintragen.
Verify Domain Ownership öffnen. Host beziehungsweise Name und vollständigen TXT-Wert exakt aus diesem Dialog in die autoritative DNS-Zone übernehmen. Dieser Eintrag bestätigt nur den Besitz und ändert den Mailfluss nicht.
Auf DNS-Verteilung warten und Verify anklicken. Sophos nennt für diesen Ownership-Eintrag bis zu zehn Minuten. Eine nicht verifizierte Domain kann nicht gespeichert werden; bei einem Fehler korrigiert man DNS, statt die Prüfung zu umgehen.
Nach erfolgreicher Prüfung den Dialog schliessen und als Nachrichtenrichtung Inbound Only oder Inbound and Outbound wählen. Für ausgehende Prüfung, Berichte und Funktionen wie Smart Banners benötigt man Inbound and Outbound.

Bei mehreren Domains wird jede einzeln verifiziert. Ein TXT-Wert aus einer anderen Domain oder einem anderen Tenant ist kein Ersatz, auch wenn der Hostname ähnlich aussieht.

Ziele, Gateways und Ports festlegen

Unter Inbound destination wählt man Mail Host für genau ein öffentlich erreichbares Ziel oder MX, wenn Sophos anhand eines Mail-Exchange-Namens zustellen soll. Mehrere Ziele erfordern MX. Beim Mail Host trägt man die öffentliche IP-Adresse oder den FQDN des Routers, der Firewall oder des Front-End-Mailservers ein; bei MX den FQDN des Mail Exchange. Private Adressen und nur intern auflösbare Namen sind als öffentliches Cloud-Ziel ungeeignet.

Bei Inbound and Outbound wählt man eine oder mehrere ausgehende Quellen: Microsoft Office 365, Google Apps Gmail oder Custom Gateway. Für Custom Gateway trägt man mindestens eine öffentliche Quell-IP oder einen passenden CIDR-Bereich ein und fügt ihn mit Add hinzu. Der Bereich darf nur Systeme umfassen, die für diese Domain tatsächlich über Sophos senden dürfen; unnötig breite Netze erhöhen das Relay-Risiko. Der Mailserver beziehungsweise Dienst kann Nachrichten auf Port 25 oder 587 an Sophos senden. Die Auswahl muss mit Firewall, Provider und TLS-Konfiguration übereinstimmen.

Diese ausgehenden Gateways autorisieren die Quelle zu Sophos. Sie sind nicht dasselbe wie Custom SMTP Routing, das nach der Sophos-Verarbeitung ein Ziel von Sophos weg festlegt.

Regionale DNS- und Relay-Werte übernehmen

Nach Save zeigt Configure External Dependencies die für den Tenant benötigten Daten. Unter Inbound Settings stehen MX-Werte und Sophos-Zustell-IP-Adressen; unter Outbound Settings der gegebenenfalls benötigte Relay-Host. Die Werte sind regionsabhängig und können sich ändern. Deshalb werden sie hier nicht kopiert: Man vergleicht die in Sophos Fusion gewählte Datenregion und übernimmt die Werte direkt aus der aktuellen Sophos-Übersicht für Email-Domain-Informationen.

Für den Cutover gelten vier Regeln:

öffentliche MX-Einträge zeigen auf die beiden Sophos-MX-Ziele der eigenen Region und behalten deren Prioritäten bei;
der nachgelagerte Mailhost nimmt Zustellung nur von den veröffentlichten Sophos Gateway IPs der eigenen Region an;
der bestehende SPF-TXT-Eintrag wird zu einem syntaktisch gültigen SPF-Eintrag zusammengeführt und erhält ausschliesslich den regionalen Sophos-Include-Wert;
ein Sophos-Relay-Host wird nur dort konfiguriert, wo die Provider-Anleitung ihn verlangt; für Microsoft 365 und Google Workspace ist laut Sophos kein zusätzlicher Outbound-Relay-Host erforderlich.

Den alten allgemeinen Include _spf.prod.hydra.sophos.com sollte man nicht neu verwenden. Er kann zu SPF PermError: too many DNS lookups führen. Auch Werte anderer Regionen werden nicht vorsorglich ergänzt: Sie erhöhen DNS-Lookups und können den Mailfluss brechen. Vor dem MX-Wechsel prüft man die autoritative DNS-Antwort und Erreichbarkeit des internen Ziels; nach dem Wechsel kontrolliert man externe Resolver und tatsächliche Zustellung.

BATV kontrolliert aktivieren

Bounce Address Tag Validation (BATV) kennzeichnet ausgehende Envelope-Sender und erkennt eingehende Zustellberichte ohne gültiges Tag. Sophos behandelt dabei eine Nachricht ohne SMTP-Envelope-Absender und mit content-type: multipart/report; report-type=delivery-status als Bounce. BATV funktioniert nur zuverlässig, wenn alle ausgehenden Nachrichten der betroffenen Domain über Sophos Email laufen.

Beim Hinzufügen oder Bearbeiten der Domain aktiviert man BATV enabled und wählt die Fehleraktion. Für die erste Woche nimmt man Quarantine, nicht Delete. Das gilt auch nach erneutem Aktivieren: Bounces zu Nachrichten, die vor der Aktivierung versendet wurden, besitzen noch kein Tag und könnten legitim sein. Man prüft in dieser Woche normale Nichtzustellbarkeitsberichte, gibt legitime Treffer kontrolliert frei und verschärft die Aktion erst nach dokumentierter Auswertung. Die optionale Einstellung Apply BATV to a message marked bounce by SophosLabs heuristics erweitert die Erkennung auf automatisch erzeugte Antworten und wird deshalb ebenfalls mit repräsentativen Nachrichten getestet.

DKIM mit einem 2048-Bit-Schlüssel einrichten

Unter Products and Services > Email > Gateway Domains die ausgehend über Sophos geroutete Domain öffnen und Add key wählen.
Sophos erzeugt ein 2048-Bit-Schlüsselpaar. Der private Schlüssel bleibt in Sophos Email; den angezeigten Selector beziehungsweise DNS-Namen und den vollständigen Public-Key-TXT-Wert exakt zum DNS-Provider übertragen.
Auf DNS-Verteilung warten. Sophos nennt dafür bis zu eine Stunde. Anschliessend Test record anklicken. Bei einem Fehler bleibt der Schlüssel inaktiv, bis Name und Wert korrigiert wurden und der Test besteht.
Erst nach erfolgreichem Test den Schlüssel aktivieren und Save wählen. Die Aktivierung deaktiviert einen anderen aktiven DKIM-Schlüssel derselben Domain. Den bisherigen öffentlichen Selector lässt man für die Übergangszeit bestehen, damit bereits versendete Nachrichten noch geprüft werden können.
Eine neue ausgehende Nachricht über Sophos senden und in den empfangenen Headern DKIM=pass sowie die erwartete Signing-Domain kontrollieren.

Der Wert d= in DKIM-Signature muss für die Sophos-Auswertung zur Absenderdomain passen. Weicht die Signing-Domain von der Absenderdomain ab und erfüllt keine Signatur diese Ausrichtung, kann Sophos das Ergebnis als dkim=none behandeln. Bei mehreren Signierern löst man deshalb zuerst den Provider-Konflikt; dieser Ablauf richtet nur die ausgehende Signatur von Sophos Email ein.

Benutzerdefiniertes SMTP-Routing testen und zurücknehmen

Eine benutzerdefinierte Route eignet sich, wenn ausgehende, bereits von Sophos verarbeitete Nachrichten einer Domain an ein bestimmtes nachgelagertes Gateway, Archiv oder anderes SMTP-System gehen sollen.

Den bisherigen Zielwert und Port dokumentieren und die Erreichbarkeit des neuen Ziels sowie dessen Relay-Berechtigung für Sophos klären.
Global Settings > Products and Services > Email > Custom SMTP Routing öffnen und Add wählen.
Die Domain auswählen, Ziel-IP oder FQDN und den vom Ziel tatsächlich angebotenen SMTP-Port eintragen und Add anklicken.
Eine Nachricht dieser Domain an einen kontrollierten externen Empfänger senden. In Message History Verbindung und Übergabe prüfen und die endgültige Zustellung zusätzlich beim Zielsystem und Empfänger bestätigen.
Schlägt der Test fehl, keine DNS-, Policy- und Routing-Änderungen gleichzeitig nachschieben. Die neue Route anhand des vorher gesicherten Zustands zurücknehmen beziehungsweise den früheren Zieleintrag wiederherstellen, erneut testen und erst danach DNS, Port, Firewall, Relay-Berechtigung und TLS-Aushandlung einzeln untersuchen.

Ein Eintrag in Message History beweist die Verarbeitung durch Sophos, aber nicht allein die endgültige Annahme im Empfängerpostfach. Deshalb gehören Zielserver-Trace oder -Log und Empfangskontrolle zur Abnahme.

Bearbeiten und Löschen ohne Abhängigkeiten zu brechen

Zum Bearbeiten klickt man in Gateway Domains auf den Domainnamen, ändert die Werte und speichert. Vor Änderungen an Ziel, Port, Gateway, BATV oder DKIM sichert man den Ausgangszustand und ändert nur eine Abhängigkeit pro Testzyklus.

Eine Domain löscht man nicht als schnellen Rollback. Zuerst inventarisiert und entfernt beziehungsweise verlagert man alle abhängigen MX- und SPF-Einträge, Provider-Connectors, Smart Hosts, erlaubten Relay-Quellen, Custom-SMTP-Routen, DKIM-Signierung und nachgelagerten Einschränkungen. Danach testet man den Ersatzpfad in beide Richtungen. Erst wenn keine Nachricht und kein System mehr auf die Gateway-Domain angewiesen ist, verwendet man das Delete-Symbol neben der Domain. Bei Unsicherheit bleibt die Domain bestehen und der Rückbau wird mit Sophos oder dem Provider geklärt.

Validierung und gezielte Fehlersuche

Die Abnahme ist erst vollständig, wenn alle folgenden Kontrollen bestehen:

Ownership-TXT ist autoritativ sichtbar und die Domain in Gateway Domains verifiziert;
MX und regionaler SPF-Include entsprechen der aktuellen Sophos-Anzeige für die Tenant-Region;
je eine eingehende und ausgehende Testnachricht ist in Message History nachvollziehbar und beim endgültigen Empfänger angekommen;
ein legitimer Zustellbericht wurde unter der gewählten BATV-Aktion korrekt verarbeitet;
eine neue ausgehende Nachricht enthält die Sophos-DKIM-Signatur, liefert DKIM=pass und verwendet die erwartete d=-Domain;
eine Custom-SMTP-Route zeigt sowohl erfolgreiche Sophos-Übergabe als auch Annahme durch das Zielsystem.

Bei Fehlern grenzt man die Schicht ein, statt Schutzfunktionen abzuschalten:

Ownership oder DKIM-Test schlägt fehl: autoritative Zone, exakten Host/Selector, TXT-Wert, Anführungszeichen beziehungsweise Aufteilung langer TXT-Werte, doppelte Records und DNS-Verteilung prüfen.
SPF PermError: too many DNS lookups: sicherstellen, dass nur ein SPF-Record existiert, den Lookup-Baum prüfen und den allgemeinen Sophos-Include durch den aktuellen regionalen Wert ersetzen.
Eingehend fehlt: öffentliche MX-Antwort, richtige Region, Sophos Gateway IP-Freigabe, Ziel-FQDN und Port sowie Provider- oder Mailserver-Log prüfen.
Ausgehend fehlt: autorisierte Quell-IP beziehungsweise CIDR, Port 25 oder 587, Firewall, Smart Host, Relay-Berechtigung und TLS-Aushandlung prüfen.
BATV trifft legitime Bounces: bei Quarantine bleiben, bestätigen, dass sämtlicher Ausgangsverkehr über Sophos läuft, und alte vor der Aktivierung versendete Nachrichten berücksichtigen.
dkim=none trotz Signatur: d= aus DKIM-Signature mit der sichtbaren Absenderdomain vergleichen und zusätzliche Provider-Signaturen beziehungsweise Änderungen nach der Signierung untersuchen.

Für eine Eskalation sammelt man Domain, Tenant-Region, Zeitstempel, Message-ID, Absender und Empfänger, autoritative DNS-Antworten sowie die Ereignisse aus Sophos Message History und dem nachgelagerten System. Passwörter, private Schlüssel und vollständige vertrauliche Nachrichteninhalte gehören nicht in ein Support-Ticket.