Sophos Email Gateway mit Google Workspace einrichten

Bei einer Gateway-Integration läuft eingehende Mail Internet → Sophos Gateway → Google Workspace und ausgehende Mail Google Workspace → Sophos Gateway → Internet. Für eine sichere Umstellung richtet man zuerst alle Ziel-, Gateway- und internen Routen ein, testet sie und ändert erst danach die produktiven MX-Einträge. So gibt es zu jedem Zeitpunkt einen bekannten Zustellpfad und einen Rückweg.

Schnellweg: Domain in Sophos Fusion (ehemals Sophos Central) verifizieren, den separaten Google-Zustellhost vorbereiten, Mailboxen erfassen, das Google Inbound Gateway auf die regionalen Sophos-IP-Adressen begrenzen und interne Nachrichten direkt zu Google routen. Danach den in Sophos Fusion angezeigten Outbound Relay Host als ausgehendes Gateway in Google eintragen. Erst nach Tests in beiden Richtungen werden die primären MX-Einträge auf die für die eigene Sophos-Region angezeigten Werte umgestellt.

Geltungsbereich und Voraussetzungen

Diese Anleitung gilt für Sophos Email im Gateway-Modus mit Google Workspace. Man benötigt Administratorzugriff auf Sophos Fusion, die Google Admin-Konsole und das DNS der Maildomain. Die Domain muss in Sophos Gateway konfiguriert sein, und alle zu schützenden Empfänger müssen in Sophos Email vorhanden sein.

Folgende Daten werden vor dem Change in einem Arbeitsblatt erfasst:

Maildomain und betroffene Organisationseinheit in Google Workspace;
aktueller produktiver MX-Satz samt Prioritäten und TTL;
aktueller SPF-Eintrag sowie bestehende DKIM- und DMARC-Konfiguration;
die in Sophos Fusion für die eigene Datenregion angezeigten MX-, Delivery-IP-, Relay- und SPF-Werte;
die von Google aktuell für den eigenen Tenant vorgegebenen MX-Ziele;
ein externer und ein interner Testabsender sowie je ein interner und externer Empfänger;
gewünschte TLS-Anforderungen und ein Wartungs- beziehungsweise Rücksetzfenster.

Regionale Hosts und IP-Adressen werden nicht aus Beispielen oder alten Tickets übernommen. Man kopiert sie unmittelbar vor dem Change aus Sophos Fusion. Auch die Google-Zielwerte werden gegen die aktuelle Google-Dokumentation beziehungsweise die Tenant-Anzeige geprüft.

Produktgrenze: Google Post Delivery Protection und die Google-Directory-Synchronisierung ändern weder diesen SMTP-Routingaufbau noch ersetzen sie ihn. Beide sind separate Aufgaben und bleiben hier ausserhalb des Umfangs.

Änderung sicher vorbereiten

Den aktuellen Mailflow mit je einer ein- und ausgehenden Testnachricht dokumentieren. Header und Google-Nachverfolgung sichern und prüfen, dass die Nachrichten noch nicht in Sophos Message History erscheinen.
Die DNS-TTL der produktiven MX-Einträge rechtzeitig vor dem Change auf einen betrieblich passenden Wert senken. Den alten MX-Satz und alle bisherigen Google-Routingregeln als Rücksetzstand dokumentieren.
Prüfen, ob bereits ein anderer Secure Email Gateway, ein Google Outbound Gateway oder eine Catch-all-Routingregel aktiv ist. Überlappende Regeln werden nicht parallel auf dieselben Nachrichten angewendet.
Einen kleinen Pilotbereich oder ein geplantes Testfenster verwenden. Schutzregeln wie Reject all mail not from gateway IPs erst aktivieren, wenn alle regionalen Sophos Delivery IPs vollständig erfasst und die internen Google-Pfade getestet sind.

Der wichtigste Schleifenschutz ist eine eindeutige Trennung der Ziele: Der primäre MX zeigt später zu Sophos; das in Sophos hinterlegte Zustellziel zeigt zu einem separaten Google-Ziel und niemals zurück zum Sophos-MX. Die Google-Outbound-Route zeigt zu Sophos, darf aber nicht erneut auf bereits von Sophos zugestellte eingehende Nachrichten angewendet werden.

Eingehenden Mailflow konfigurieren

Domain und Google-Zustellziel in Sophos vorbereiten

In Sophos Fusion Global Settings > Products and Services > Email > Gateway Domains öffnen und die Domain auswählen beziehungsweise hinzufügen.
Als Delivery Destination einen separaten MX-Namen unter der eigenen Domain verwenden, beispielsweise routing-mx.example.com, und den von Sophos dokumentierten SMTP-Port eintragen. Der Name ist ein eigener DNS-Zustellpfad für Sophos und nicht der produktive MX der Hauptdomain.
Verify Domain Ownership starten, den für diese Domain angezeigten TXT-Wert unverändert in der DNS-Zone veröffentlichen und nach der Propagation erneut verifizieren.
Für routing-mx.example.com MX-Einträge zu den aktuell für den eigenen Google-Workspace-Tenant vorgegebenen Google-Zielen anlegen. Diese Einträge dürfen nicht auf Sophos zeigen.
Alle geschützten Mailboxen beziehungsweise Empfänger in Sophos Email erfassen und die Domainkonfiguration speichern.

Die Verifizierung ist bestanden, wenn Sophos Fusion die Domain als verifiziert anzeigt und eine DNS-Abfrage für routing-mx.example.com ausschliesslich die beabsichtigten Google-Ziele liefert.

Wenn die Zustellung über ASPMX.L.GOOGLE.COM Probleme verursacht, kann man ausschliesslich das Google-Zustellziel hinter routing-mx.example.com auf SMTP.GOOGLE.COM ändern. Das ist eine bedingte Alternative für die Zustellung von Sophos zu Google, kein allgemeiner Standard und keine Änderung am produktiven MX der Hauptdomain, der weiterhin zu Sophos zeigt. Vor der Änderung bestätigt man die für die eigene Google-Workspace-Umgebung gültigen Werte, danach testet man den eingehenden Mailflow erneut. Schlägt auch dieser Test fehl, stellt man das zuvor dokumentierte Google-Zustellziel wieder her und kontaktiert Sophos Support.

Google Inbound Gateway absichern

In der Google Admin-Konsole die Einstellung Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway für die betroffene oberste Organisation öffnen.
Das Inbound Gateway aktivieren und ausschliesslich die in Sophos Fusion für die eigene Region angegebenen Delivery IPs hinzufügen.
Automatically detect external IP und die vereinbarte TLS-Anforderung aktivieren.
Reject all mail not from gateway IPs nur nach einem Pilot-Test aktivieren. Diese Option blockiert direkte Zustellung, schützt damit vor einer Umgehung von Sophos, kann bei einer unvollständigen IP-Liste aber auch legitime Mail stoppen.
Speichern und bis zu 24 Stunden warten, bis die eingehende Einstellung wirksam ist.

Wenn Google-eigene Zustellpfade durch die strikte Gateway-Beschränkung blockiert werden, schaltet man die Ablehnung vorübergehend aus, stellt den Mailflow wieder her und klärt die benötigten aktuellen Google- und Sophos-Adressen anhand der Herstellerangaben. Keine unbekannten Netze pauschal freigeben.

Sophos berichtet von einer DMARC-Anomalie aus eigenen Tests: Sind Time of Click URL Protection oder Einstellungen für Endbenutzernachrichten aktiviert, kennzeichnet Google eingehende Nachrichten manchmal als DMARC-Fehler, obwohl laut Google-Dokumentation die DMARC-Authentifizierung für Nachrichten von eingetragenen Gateway-Hosts umgangen wird und das eingehende Gateway die Prüfung durchführen soll. Sophos hat diese Abweichung nach eigenen Angaben bei Google gemeldet. Sie ist zu berücksichtigen, bevor eine solche Meldung als Beleg für eine falsche Konfiguration von Automatically detect external IP oder der Delivery-IP-Liste gilt.

Interne Nachrichten direkt zu Google routen

Interne Nachrichten sollen nicht über den produktiven MX zu Sophos und anschliessend zurück zu Google laufen. In Apps > Google Workspace > Gmail > Hosts wird deshalb eine Route mit den aktuellen Google-Zielen für den Tenant angelegt. In Apps > Google Workspace > Gmail > Routing wird diese Route nur auf Internal - Sending angewendet und über einen Envelope-Senderfilter auf die eigene Domain begrenzt. TLS und eine von einer CA signierte Zertifikatsprüfung werden gemäss der Google- und Sophos-Vorgabe aktiviert.

Interne Route und Outbound-Gateway-Regel erhalten nicht überlappende Geltungsbereiche und Abgleichbedingungen. Die Routing-Änderung wird gespeichert und darf bis zu 24 Stunden wirksam werden; Änderungen lassen sich im Admin-Audit-Log von Google Workspace verfolgen. Erst wenn die Änderung wirksam ist, werden interne Nachrichten oder der Pilot validiert und die produktiven MX-Einträge umgestellt. Anschliessend sendet man intern an einen Empfänger derselben Domain: Die Nachricht muss in Google bleiben und darf nicht zusätzlich als ein- und ausgehender Scan in Sophos auftauchen.

Ausgehenden Mailflow konfigurieren

In Gateway Domains die Domain öffnen und unter Configure Domain die Richtung Inbound and Outbound wählen.
Als Outbound Gateway Google Apps Gmail wählen, speichern und unter Configure External Dependencies > Outbound Settings den für diesen Tenant angezeigten Outbound Relay Host kopieren. Diese Bezeichnung steht in Sophos Fusion für Google Workspace.
In der Google Admin-Konsole die ausgehende Gateway-Konfiguration der obersten betroffenen Organisation öffnen und exakt diesen Relay Host eintragen. Die aktuelle Google-Oberfläche kann den Routingbereich anders anordnen; keine Hostnamen aus Beispielen ableiten.
Für die Regel Absender- und Nachrichtenbedingungen festlegen, die sich nicht mit der internen Route überschneiden. Eine zweite Catch-all- oder Gateway-Regel für denselben Bereich deaktivieren beziehungsweise aus dem Geltungsbereich nehmen.
Speichern, mehrere Minuten bis zur Wirksamkeit der ausgehenden Einstellung warten und zunächst mit einem Pilotabsender an eine externe Testadresse senden.

SPF und DKIM passend zum echten Sendeweg halten

Der SPF-Eintrag muss alle tatsächlich autorisierten Sendewege abbilden, aber keine nicht mehr verwendeten Wege behalten. Während einer kontrollierten Übergangsphase können Google Workspace und Sophos gleichzeitig autorisiert sein. Sobald ausgehende Mail ausschliesslich über Sophos läuft, entfernt man den nicht mehr benötigten direkten Google-Sendeweg nur dann, wenn keine Anwendung, Weiterleitung oder Drittplattform ihn noch verwendet.

Den für die eigene Region gültigen Sophos-SPF-Include-Wert übernimmt man aus Sophos Fusion; ein Beispielwert wäre hier gefährlich. Vor dem Speichern wird geprüft, dass für die Domain weiterhin genau ein SPF-TXT-Eintrag existiert und die gewählte -all- oder ~all-Strategie zur Umstellung passt. DKIM-Signaturen und DMARC bleiben separat aktiv und werden nach der Umstellung anhand einer extern empfangenen Nachricht kontrolliert.

Pilot validieren, dann den produktiven MX umstellen

Vor der produktiven MX-Umstellung validiert man im Pilotbereich oder Testfenster die ausgehende Zustellung über Sophos und eine interne Nachricht, die in Google bleibt. Erwartete Header, Google-Nachverfolgung und Sophos Message History werden geprüft; ausserdem muss der vorbereitete SPF-Eintrag den tatsächlichen Sendeweg des Piloten abdecken.

Erst wenn Zustellziel, Empfänger, Inbound Gateway, interne Route, Outbound Gateway, SPF-Vorbereitung und Pilotprüfungen funktionieren, ersetzt man den produktiven MX-Satz der Hauptdomain durch die in Sophos Fusion für die eigene Region angezeigten MX-Werte und Prioritäten. Während der DNS-Propagation bleiben alter Zustand, Verantwortlicher und Rücksetzentscheidung dokumentiert. Bei einem Zustellausfall wird auf den vorher gesicherten MX-Satz zurückgestellt, statt weitere ungetestete Routen hinzuzufügen.

Beide Richtungen validieren

Nach jeder Änderung wartet man die Propagation ab und führt vier gezielte Tests durch:

extern → interner geschützter Empfänger;
interner Benutzer → externer Empfänger;
interner Benutzer → interner Benutzer derselben Domain;
direkter Zustellversuch, der Sophos umgeht, sofern dieser Test autorisiert und sicher durchführbar ist.

Für Test 1 und 2 muss in Sophos Fusion unter Reports > Message History genau der passende Eintrag mit korrekter Richtung, Absender, Empfänger, Zeit und Ergebnis erscheinen. Parallel prüft man die Google-Nachverfolgung und die vollständigen Header der zugestellten Nachricht. Die Received-Kette muss den erwarteten Weg in der richtigen Reihenfolge zeigen; SPF, DKIM und DMARC werden am externen Ziel auf das erwartete Resultat geprüft.

Test 3 darf nicht unnötig zweimal durch Sophos laufen. Test 4 muss nach Aktivierung der strikten Inbound-Gateway-Beschränkung abgewiesen werden. Mehrere Sophos-Einträge für dieselbe Message-ID, wiederholte Hosts in der Received-Kette oder stark steigende Zustellzeiten sind Hinweise auf doppelte Verarbeitung oder eine Schleife.

Fehler gezielt eingrenzen

Extern eingehende Mail fehlt: Zuerst den produktiven MX und seine Region prüfen, danach die Sophos Message History. Existiert dort kein Eintrag, liegt der Fehler vor Sophos. Existiert ein Eintrag ohne Google-Zustellung, routing-mx.example.com, Google-Ziele, Empfängerbestand, Delivery-IP-Beschränkung und TLS prüfen.
Ausgehende Mail fehlt in Sophos: Geltungsbereich und Abgleichbedingungen der Google-Regeln sowie den eingetragenen Outbound Relay Host prüfen. Erscheint sie in Sophos, aber nicht beim Ziel, Zustellstatus, SPF/DKIM/DMARC und die Fehlermeldung des Zielsystems auswerten.
Interne Mail erscheint zweimal in Sophos: Prüfen, ob Internal - Sending nur die eigene Domain erfasst und keine allgemeine Regel dieselben Nachrichten erfasst. Überlappende Outbound- oder Catch-all-Regeln entfernen, statt einen weiteren Bypass anzulegen.
TLS-Fehler: Quell- und Zielhost, Zertifikatsname, CA-Vertrauen und die auf beiden Seiten verlangte TLS-Option vergleichen. Die Anforderung nicht dauerhaft abschalten; für einen Test nur nach dokumentierter Risikoentscheidung lockern und danach wiederherstellen.
Mail pendelt zwischen Google und Sophos: Den Change stoppen. Primären MX, routing-mx.example.com, Google-Outbound-Route und Header-Hops nebeneinander prüfen. Das Sophos-Zustellziel muss Google sein, nicht Sophos; die Google-Outbound-Regel darf keine von Sophos eingehend zugestellte Mail erneut erfassen.
Nur einzelne Empfänger scheitern: Existenz und Schreibweise des Empfängers in Sophos Email und Google Workspace sowie Alias- und Gruppenauflösung prüfen. Domain- und Empfängerfehler nicht durch eine breite Relay-Freigabe umgehen.

Sind DNS, Routingumfang, Hosts, Domainzuordnung, TLS und Empfängerbestand korrekt, aber der dokumentierte Fehler bleibt reproduzierbar, übergibt man Message-ID, Zeitstempel, Absender, Empfänger, relevante Header und die Einträge aus Sophos Message History sowie der Google-Nachverfolgung an Sophos Support. So lässt sich der betroffene Hop untersuchen, ohne weitere produktive Regeln auf Verdacht zu ändern.