Sophos Email Gateway met Google Workspace configureren

Bij een Gateway-integratie volgt inkomende mail Internet → Sophos Gateway → Google Workspace en uitgaande mail Google Workspace → Sophos Gateway → Internet. Configureer en test voor een veilige migratie elke bestemming, gateway en interne route voordat je de productie-MX-records wijzigt. Zo blijven in elke fase een bekende bezorgroute en een terugvalmogelijkheid beschikbaar.

Snelle aanpak: verifieer het domein in Sophos Fusion (voorheen Sophos Central), bereid de afzonderlijke Google-bezorghost voor, voeg postvakken toe, beperk de Google Inbound Gateway tot de regionale Sophos-IP-adressen en routeer interne berichten rechtstreeks naar Google. Voer daarna de in Sophos Fusion getoonde Outbound Relay Host in als uitgaande gateway van Google. Wijzig de primaire MX-records pas na tests in beide richtingen naar de waarden die voor jouw Sophos-regio worden getoond.

Bereik en vereisten

Deze handleiding geldt voor Sophos Email in Gateway-modus met Google Workspace. Je hebt beheertoegang nodig tot Sophos Fusion, de Google-beheerconsole en de DNS van het maildomein. Het domein moet in Sophos Gateway zijn geconfigureerd en elke te beveiligen ontvanger moet in Sophos Email bestaan.

Leg vóór de start de volgende gegevens vast in een wijzigingsblad:

maildomein en betrokken organisatie-eenheid in Google Workspace;
huidige productie-MX-set, inclusief prioriteiten en TTL;
huidig SPF-record en bestaande DKIM- en DMARC-configuratie;
MX-, Delivery IP-, relay- en SPF-waarden die Sophos Fusion voor jouw dataregio toont;
actuele MX-bestemmingen die Google voor jouw tenant voorschrijft;
één externe en één interne testafzender en één interne en één externe ontvanger;
beoogde TLS-eisen en een onderhouds- of terugvalvenster.

Kopieer regionale hosts of IP-adressen niet uit voorbeelden of oude tickets. Neem ze direct vóór de wijziging over uit Sophos Fusion. Controleer ook de Google-bestemmingen aan de hand van de actuele Google-documentatie of tenantweergave.

Productgrens: Google Post Delivery Protection en Google Directory-synchronisatie wijzigen of vervangen dit SMTP-routeringsontwerp niet. Het zijn afzonderlijke taken die hier buiten het bereik vallen.

De wijziging veilig voorbereiden

Documenteer de huidige mailflow met één inkomend en één uitgaand testbericht. Bewaar headers en Google-trace en bevestig dat de berichten nog niet in Sophos Message History verschijnen.
Verlaag de DNS-TTL van de productie-MX-records ruim voor de wijziging tot een operationeel passende waarde. Leg de oude MX-set en alle bestaande Google-routeringsregels vast als terugvalstatus.
Controleer of er al een andere secure email gateway, Google Outbound Gateway of catch-all-routeringsregel actief is. Pas overlappende regels niet tegelijk toe op dezelfde berichten.
Gebruik een kleine pilotgroep of gepland testvenster. Schakel beveiligingen zoals Reject all mail not from gateway IPs pas in nadat alle regionale Sophos Delivery IPs zijn vastgelegd en de interne Google-paden zijn getest.

De belangrijkste bescherming tegen lussen is een ondubbelzinnige scheiding van bestemmingen: de primaire MX wijst later naar Sophos, terwijl de in Sophos opgeslagen bezorgbestemming naar een afzonderlijke Google-bestemming wijst en nooit terug naar de Sophos-MX. De uitgaande Google-route wijst naar Sophos, maar mag niet opnieuw worden toegepast op inkomende berichten die Sophos al heeft bezorgd.

Inkomende mailflow configureren

Domein en Google-bezorgbestemming in Sophos voorbereiden

Open in Sophos Fusion Global Settings > Products and Services > Email > Gateway Domains en selecteer of voeg het domein toe.
Gebruik als Delivery Destination een afzonderlijke MX-naam onder je domein, bijvoorbeeld routing-mx.example.com, en voer de door Sophos gedocumenteerde SMTP-poort in. Deze naam is een speciaal DNS-bezorgpad voor Sophos, niet de productie-MX van het hoofddomein.
Start Verify Domain Ownership, publiceer de getoonde TXT-waarde voor dit domein ongewijzigd in DNS en verifieer opnieuw na propagatie.
Maak voor routing-mx.example.com MX-records die naar de actuele Google-bestemmingen voor jouw Google Workspace-tenant wijzen. Deze records mogen niet naar Sophos wijzen.
Voeg elk beveiligd postvak of elke ontvanger toe aan Sophos Email en sla de domeinconfiguratie op.

De verificatie is geslaagd als Sophos Fusion het domein als geverifieerd toont en een DNS-query voor routing-mx.example.com uitsluitend de bedoelde Google-bestemmingen retourneert.

Als bezorging via ASPMX.L.GOOGLE.COM problemen geeft, wijzig je alleen de Google-bezorgbestemming achter routing-mx.example.com in SMTP.GOOGLE.COM. Dit is een voorwaardelijk alternatief voor bezorging van Sophos naar Google, geen universele standaard en geen wijziging van de productie-MX van het hoofddomein, die naar Sophos blijft wijzen. Bevestig vóór de wijziging welke waarden voor jouw Google Workspace-omgeving gelden en test daarna de inkomende mailflow opnieuw. Als ook die test mislukt, herstel je de eerder gedocumenteerde Google-bezorgbestemming en neem je contact op met Sophos Support.

De Google Inbound Gateway beveiligen

Open in de Google-beheerconsole Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway voor de betrokken hoofdorganisatie.
Schakel de Inbound Gateway in en voeg alleen de Delivery IPs toe die Sophos Fusion voor jouw regio toont.
Schakel Automatically detect external IP en de afgesproken TLS-eis in.
Schakel Reject all mail not from gateway IPs pas na een pilottest in. Deze optie blokkeert rechtstreekse bezorging en voorkomt zo omzeiling van Sophos, maar een onvolledige IP-lijst kan ook geldige mail stoppen.
Sla op en wacht maximaal 24 uur totdat de inkomende instelling actief is.

Als de strikte gatewaybeperking Google’s eigen bezorgroutes blokkeert, schakel je de weigering tijdelijk uit, herstel je de mailflow en bepaal je de vereiste actuele Google- en Sophos-adressen uit de leveranciersdocumentatie. Sta onbekende netwerken niet breed toe.

Sophos meldt een DMARC-afwijking uit eigen tests: als Time of Click URL Protection of instellingen voor berichten van eindgebruikers zijn ingeschakeld, markeert Google inkomende berichten soms als DMARC-fouten, hoewel Google’s documentatie zegt dat DMARC-authenticatie wordt overgeslagen voor berichten van hosts op de gatewaylijst en dat de inkomende gateway de controle moet uitvoeren. Sophos zegt deze afwijking bij Google te hebben gemeld. Houd hiermee rekening voordat je zo’n fout ziet als bewijs dat Automatically detect external IP of de Delivery IP-lijst onjuist is.

Interne berichten rechtstreeks naar Google routeren

Interne berichten mogen niet via de productie-MX naar Sophos en vervolgens terug naar Google gaan. Maak daarom in Apps > Google Workspace > Gmail > Hosts een route met de actuele Google-bestemmingen voor de tenant. Pas die route in Apps > Google Workspace > Gmail > Routing alleen toe op Internal - Sending en beperk haar met een envelope-senderfilter tot je eigen domein. Schakel TLS en validatie van een door een CA ondertekend certificaat in volgens de voorschriften van Google en Sophos.

Geef de interne route en de uitgaande gatewayregel niet-overlappende bereiken en matchvoorwaarden. Sla de routeringswijziging op en wacht maximaal 24 uur totdat deze actief is; je kunt wijzigingen volgen in het beheerdersauditlogboek van Google Workspace. Begin pas daarna met de validatie van interne berichten of de pilot en wijzig ook de productie-MX pas dan. Stuur vervolgens intern naar een ontvanger in hetzelfde domein: het bericht moet binnen Google blijven en mag niet ook als inkomende én uitgaande scan in Sophos verschijnen.

Uitgaande mailflow configureren

Open het domein in Gateway Domains en selecteer Inbound and Outbound onder Configure Domain.
Kies Google Apps Gmail als Outbound Gateway, sla op en kopieer de voor deze tenant getoonde Outbound Relay Host onder Configure External Dependencies > Outbound Settings. Dit label staat in Sophos Fusion voor Google Workspace.
Open in de Google-beheerconsole de configuratie van de uitgaande gateway voor de betrokken hoofdorganisatie en voer precies die Relay Host in. De actuele Google-interface kan de routeringssectie anders indelen; leid geen hostnamen af uit voorbeelden.
Geef de regel afzender- en berichtcriteria die niet met de interne route overlappen. Schakel een tweede catch-all- of gatewayregel voor hetzelfde bereik uit of haal deze uit het bereik.
Sla op, wacht enkele minuten totdat de uitgaande instelling actief is en stuur eerst vanaf een pilotafzender naar een extern testadres.

SPF en DKIM op het werkelijke verzendpad afstemmen

Het SPF-record moet elk pad bevatten dat werkelijk geautoriseerde mail verzendt, maar geen ongebruikte paden behouden. Tijdens een gecontroleerde overgang kunnen Google Workspace en Sophos beide geautoriseerd zijn. Verwijder het verouderde rechtstreekse Google-pad pas wanneer alle uitgaande mail uitsluitend via Sophos loopt én geen toepassing, doorstuurservice of extern platform het nog gebruikt.

Neem de regionale Sophos SPF-include-waarde over uit Sophos Fusion; een voorbeeldwaarde zou hier onveilig zijn. Controleer vóór opslaan dat het domein nog precies één SPF-TXT-record heeft en dat de gekozen -all- of ~all-strategie bij de migratie past. Laat DKIM-handtekeningen en DMARC afzonderlijk actief en controleer ze na de wijziging op een extern ontvangen bericht.

De pilot valideren en daarna de productie-MX wijzigen

Gebruik vóór de productie-MX-omschakeling het pilotbereik of testvenster om uitgaande bezorging via Sophos en een intern bericht dat binnen Google blijft te valideren. Controleer de verwachte headers, Google-trace en Sophos Message History en verifieer dat het voorbereide SPF-record het werkelijke verzendpad van de pilot dekt.

Vervang pas wanneer bezorgbestemming, ontvangers, Inbound Gateway, interne route, uitgaande gateway, SPF-voorbereiding en pilotcontroles werken de productie-MX-set van het hoofddomein door de MX-waarden en prioriteiten die Sophos Fusion voor jouw regio toont. Houd tijdens DNS-propagatie de vorige toestand, eigenaar en terugvalbeslissing gedocumenteerd. Herstel bij een bezorgstoring de opgeslagen MX-set in plaats van meer ongeteste routes toe te voegen.

Beide richtingen valideren

Wacht na elke wijziging de propagatie af en voer vier gerichte tests uit:

extern → beveiligde interne ontvanger;
interne gebruiker → externe ontvanger;
interne gebruiker → interne gebruiker in hetzelfde domein;
directe bezorgpoging die Sophos omzeilt, mits deze test geautoriseerd en veilig uitvoerbaar is.

Voor test 1 en 2 moet onder Reports > Message History in Sophos Fusion precies één passende vermelding staan met juiste richting, afzender, ontvanger, tijd en resultaat. Controleer parallel de Google-trace en alle headers van het bezorgde bericht. De Received-keten moet het verwachte pad in de juiste volgorde tonen; controleer SPF, DKIM en DMARC op de externe bestemming.

Test 3 mag niet onnodig tweemaal door Sophos lopen. Test 4 moet na inschakeling van de strikte Inbound Gateway-beperking worden geweigerd. Meerdere Sophos-vermeldingen voor dezelfde Message-ID, herhaalde hosts in de Received-keten of sterk oplopende bezorgtijden duiden op dubbele verwerking of een lus.

Problemen gericht oplossen

Externe inkomende mail ontbreekt: controleer eerst de productie-MX en regio, daarna Sophos Message History. Zonder vermelding ligt de fout vóór Sophos. Is er wel een vermelding maar geen Google-bezorging, controleer dan routing-mx.example.com, Google-bestemmingen, ontvangers, Delivery IP-beperking en TLS.
Uitgaande mail ontbreekt in Sophos: controleer bereik en matchvoorwaarden van de Google-regels en de ingevoerde Outbound Relay Host. Verschijnt het bericht in Sophos maar niet op de bestemming, onderzoek dan bezorgstatus, SPF/DKIM/DMARC en de fout van het doelsysteem.
Interne mail verschijnt tweemaal in Sophos: bevestig dat Internal - Sending alleen je eigen domein omvat en dat geen algemene regel dezelfde berichten omvat. Verwijder overlappende uitgaande of catch-all-regels in plaats van nog een bypass toe te voegen.
TLS-fout: vergelijk bron- en doelhost, certificaatnaam, CA-vertrouwen en de aan beide kanten vereiste TLS-optie. Schakel de eis niet permanent uit; versoepel haar voor een test alleen na een gedocumenteerde risicobeslissing en herstel haar daarna.
Mail circuleert tussen Google en Sophos: stop de wijziging. Vergelijk primaire MX, routing-mx.example.com, uitgaande Google-route en headerhops naast elkaar. De Sophos-bezorgbestemming moet Google zijn, niet Sophos; de uitgaande Google-regel mag door Sophos inkomend bezorgde mail niet opnieuw vangen.
Alleen afzonderlijke ontvangers mislukken: controleer of de ontvanger in Sophos Email en Google Workspace bestaat en identiek is gespeld, inclusief alias- en groepsresolutie. Omzeil domein- of ontvangerfouten niet met brede relaytoestemming.

Als DNS, routebereik, hosts, domeinkoppeling, TLS en ontvangers correct zijn maar de gedocumenteerde fout reproduceerbaar blijft, geef Sophos Support dan Message-ID, tijdstip, afzender, ontvanger, relevante headers en vermeldingen uit Sophos Message History en de Google-trace. Zo kan de betrokken hop worden onderzocht zonder op basis van vermoedens meer productieregels te wijzigen.