Konfigurera Sophos Email Gateway med Google Workspace

Med en Gateway-integration följer inkommande e-post Internet → Sophos Gateway → Google Workspace och utgående e-post Google Workspace → Sophos Gateway → Internet. Konfigurera och testa varje destination, gateway och intern rutt innan MX-posterna för produktion ändras. Då finns en känd leveransväg och möjlighet att återställa i varje steg.

Snabb väg: verifiera domänen i Sophos Fusion (tidigare Sophos Central), förbered den separata leveransvärden hos Google, lägg till brevlådorna, begränsa Google Inbound Gateway till Sophos regionala IP-adresser och dirigera interna meddelanden direkt till Google. Ange sedan den Outbound Relay Host som visas i Sophos Fusion som Googles utgående gateway. Ändra de primära MX-posterna till värdena för din Sophos-region först efter test i båda riktningarna.

Omfattning och förutsättningar

Guiden gäller Sophos Email i Gateway-läge med Google Workspace. Du behöver administratörsåtkomst till Sophos Fusion, Googles administratörskonsol och e-postdomänens DNS. Domänen måste vara konfigurerad i Sophos Gateway och varje mottagare som ska skyddas måste finnas i Sophos Email.

Dokumentera följande i ett ändringsunderlag innan du börjar:

e-postdomän och berörd organisationsenhet i Google Workspace;
aktuell MX-uppsättning för produktion, inklusive prioriteringar och TTL;
aktuell SPF-post och befintlig DKIM- och DMARC-konfiguration;
MX-, Delivery IP-, relay- och SPF-värden som Sophos Fusion visar för din dataregion;
aktuella MX-destinationer som Google anger för din tenant;
en extern och en intern testavsändare samt en intern och en extern mottagare;
avsedda TLS-krav och ett underhålls- eller återställningsfönster.

Kopiera inte regionala värdar eller IP-adresser från exempel eller gamla ärenden. Hämta dem från Sophos Fusion precis före ändringen. Kontrollera även Google-destinationerna mot aktuell Google-dokumentation eller tenantvyn.

Produktgräns: Google Post Delivery Protection och Google Directory-synkronisering ändrar eller ersätter inte denna SMTP-routing. De är separata uppgifter och ingår inte här.

Förbered ändringen säkert

Dokumentera nuvarande e-postflöde med ett inkommande och ett utgående testmeddelande. Spara rubrikerna och Google-spårningen och bekräfta att meddelandena ännu inte visas i Sophos Message History.
Sänk DNS-TTL för produktions-MX-posterna till ett driftsmässigt lämpligt värde i god tid. Dokumentera den gamla MX-uppsättningen och alla befintliga Google-routingregler som återställningsläge.
Kontrollera om en annan secure email gateway, Google Outbound Gateway eller catch-all-regel redan är aktiv. Tillämpa inte överlappande regler parallellt på samma meddelanden.
Använd en liten pilotgrupp eller ett planerat testfönster. Aktivera skydd som Reject all mail not from gateway IPs först när alla regionala Sophos Delivery IP har lagts till och de interna Google-vägarna har testats.

Det viktigaste skyddet mot loopar är att destinationerna skiljs tydligt: primär MX ska peka mot Sophos, medan leveransdestinationen i Sophos pekar mot en separat Google-destination och aldrig tillbaka mot Sophos MX. Googles utgående rutt pekar mot Sophos, men får inte tillämpas igen på inkommande meddelanden som redan levererats av Sophos.

Konfigurera inkommande e-postflöde

Förbered domänen och Google-destinationen i Sophos

Öppna Global Settings > Products and Services > Email > Gateway Domains i Sophos Fusion och välj eller lägg till domänen.
Använd ett separat MX-namn under din domän som Delivery Destination, till exempel routing-mx.example.com, och ange SMTP-porten som Sophos dokumenterar. Namnet är en särskild DNS-leveransväg för Sophos, inte huvuddomänens produktions-MX.
Starta Verify Domain Ownership, publicera TXT-värdet som visas för domänen oförändrat i DNS och verifiera igen efter propagering.
Skapa MX-poster för routing-mx.example.com som pekar mot de aktuella Google-destinationerna för din Google Workspace-tenant. De får inte peka mot Sophos.
Lägg till varje skyddad brevlåda eller mottagare i Sophos Email och spara domänkonfigurationen.

Verifieringen lyckas när Sophos Fusion visar domänen som verifierad och en DNS-fråga för routing-mx.example.com bara returnerar avsedda Google-destinationer.

Om leveransen via ASPMX.L.GOOGLE.COM får problem ändrar du endast Google-leveransdestinationen bakom routing-mx.example.com till SMTP.GOOGLE.COM. Det är ett villkorat alternativ för leverans från Sophos till Google, inte en universell standard och inte en ändring av huvuddomänens produktions-MX, som fortsätter att peka mot Sophos. Bekräfta först vilka värden som gäller för din Google Workspace-miljö och testa sedan det inkommande e-postflödet igen. Om även det testet misslyckas återställer du den tidigare dokumenterade Google-leveransdestinationen och kontaktar Sophos Support.

Skydda Google Inbound Gateway

Öppna Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway i Googles administratörskonsol för den berörda topporganisationen.
Aktivera Inbound Gateway och lägg endast till de Delivery IP som Sophos Fusion anger för din region.
Aktivera Automatically detect external IP och det överenskomna TLS-kravet.
Aktivera Reject all mail not from gateway IPs först efter ett pilottest. Alternativet blockerar direktleverans och förhindrar att Sophos kringgås, men en ofullständig IP-lista kan även stoppa legitim e-post.
Spara och vänta upp till 24 timmar på att den inkommande inställningen ska börja gälla.

Om den strikta begränsningen blockerar Googles egna leveransvägar, stänger du tillfälligt av avvisningen, återställer e-postflödet och fastställer nödvändiga aktuella Google- och Sophos-adresser utifrån leverantörernas anvisningar. Tillåt inte okända nätverk generellt.

Sophos rapporterar en DMARC-avvikelse från sina egna tester: om Time of Click URL Protection eller inställningar för slutanvändarmeddelanden är aktiverade markerar Google ibland inkommande meddelanden som DMARC-fel, trots att Googles dokumentation säger att DMARC-autentisering hoppas över för meddelanden från gatewaylistade värdar och att den inkommande gatewayen ska utföra kontrollen. Sophos uppger att avvikelsen har rapporterats till Google. Beakta den innan ett rapporterat fel tolkas som bevis på att Automatically detect external IP eller Delivery IP-listan är felaktig.

Dirigera interna meddelanden direkt till Google

Interna meddelanden ska inte gå via produktions-MX till Sophos och sedan tillbaka till Google. Skapa därför en rutt med aktuella Google-destinationer för tenanten i Apps > Google Workspace > Gmail > Hosts. Tillämpa rutten endast på Internal - Sending i Apps > Google Workspace > Gmail > Routing och begränsa den till din domän med ett envelope-senderfilter. Aktivera TLS och validering av ett CA-signerat certifikat enligt Google och Sophos anvisningar.

Ge den interna rutten och den utgående gatewayregeln omfattningar och matchningsvillkor som inte överlappar. Spara routingändringen och vänta upp till 24 timmar på att den ska börja gälla; du kan följa ändringarna i Google Workspace administratörsgranskningslogg. Börja inte validera interna meddelanden eller piloten och ändra inte produktions-MX förrän ändringen gäller. Skicka sedan internt till en mottagare i samma domän: meddelandet ska stanna hos Google och inte dessutom visas som både inkommande och utgående skanning i Sophos.

Konfigurera utgående e-postflöde

Öppna domänen i Gateway Domains och välj Inbound and Outbound under Configure Domain.
Välj Google Apps Gmail som Outbound Gateway, spara och kopiera den Outbound Relay Host som visas för tenanten under Configure External Dependencies > Outbound Settings. Denna etikett representerar Google Workspace i Sophos Fusion.
Öppna konfigurationen för utgående gateway för berörd topporganisation i Google-konsolen och ange exakt denna Relay Host. Googles aktuella gränssnitt kan ordna routingavsnittet på annat sätt; härled inte värdnamn från exempel.
Ge regeln avsändar- och meddelandekriterier som inte överlappar den interna rutten. Inaktivera eller ta bort en andra catch-all- eller gatewayregel från samma omfattning.
Spara, vänta flera minuter på att den utgående inställningen ska börja gälla och skicka först från en pilotavsändare till en extern testadress.

Anpassa SPF och DKIM till den verkliga sändvägen

SPF-posten måste omfatta alla vägar som faktiskt skickar behörig e-post, men inte behålla oanvända vägar. Under en kontrollerad övergång kan både Google Workspace och Sophos vara behöriga. När all utgående e-post enbart går via Sophos tar du bort den föråldrade direkta Google-vägen endast om ingen applikation, vidarebefordran eller tredjepartsplattform fortfarande använder den.

Hämta det regionala Sophos SPF-include-värdet från Sophos Fusion; ett exempelvärde vore osäkert här. Bekräfta före sparande att domänen fortfarande har exakt en SPF-TXT-post och att vald -all- eller ~all-strategi passar migreringen. Håll DKIM-signaturer och DMARC separat aktiva och kontrollera dem på ett externt mottaget meddelande efter ändringen.

Validera piloten och ändra sedan produktions-MX

Använd pilotomfattningen eller testfönstret före ändringen av produktions-MX för att validera utgående leverans via Sophos och ett internt meddelande som stannar hos Google. Bekräfta förväntade rubriker, Google-spårning och Sophos Message History och verifiera att den förberedda SPF-posten täcker pilotens verkliga sändväg.

Först när leveransdestination, mottagare, Inbound Gateway, intern rutt, utgående gateway, SPF-förberedelser och pilottester fungerar ska du ersätta huvuddomänens produktions-MX med de MX-värden och prioriteringar som Sophos Fusion visar för din region. Dokumentera föregående läge, ansvarig och återställningsbeslut under DNS-propageringen. Vid leveransfel återställer du den sparade MX-uppsättningen i stället för att lägga till fler oprövade rutter.

Validera båda riktningarna

Vänta efter varje ändring på propageringen och genomför fyra riktade test:

extern → skyddad intern mottagare;
intern användare → extern mottagare;
intern användare → intern användare i samma domän;
direkt leveransförsök som kringgår Sophos, om testet är behörigt och kan göras säkert.

För test 1 och 2 ska exakt en matchande post med rätt riktning, avsändare, mottagare, tid och resultat visas i Sophos Fusion under Reports > Message History. Kontrollera samtidigt Google-spårningen och det levererade meddelandets fullständiga rubriker. Kedjan Received ska visa den förväntade vägen i rätt ordning; kontrollera SPF, DKIM och DMARC hos den externa mottagaren.

Test 3 ska inte passera Sophos två gånger i onödan. Test 4 ska avvisas när den strikta Inbound Gateway-begränsningen har aktiverats. Flera Sophos-poster för samma Message-ID, upprepade värdar i kedjan Received eller kraftigt ökande leveranstid tyder på dubbel behandling eller en loop.

Felsök systematiskt

Extern inkommande e-post saknas: kontrollera först produktions-MX och dess region, sedan Sophos Message History. Utan post ligger felet före Sophos. Finns en post men ingen Google-leverans kontrollerar du routing-mx.example.com, Google-destinationer, mottagare, Delivery IP-begränsning och TLS.
Utgående e-post saknas i Sophos: kontrollera Google-reglernas omfattning och matchningsvillkor samt angiven Outbound Relay Host. Om meddelandet syns i Sophos men inte hos mottagaren granskar du leveransstatus, SPF/DKIM/DMARC och målsystemets fel.
Intern e-post visas två gånger i Sophos: bekräfta att Internal - Sending bara matchar din domän och att ingen generell regel matchar samma meddelanden. Ta bort överlappande utgående regler eller catch-all-regler i stället för att lägga till ytterligare ett undantag.
TLS-fel: jämför käll- och målvärd, certifikatnamn, CA-förtroende och TLS-alternativet som krävs på båda sidor. Stäng inte av kravet permanent; lätta på det för ett test endast efter ett dokumenterat riskbeslut och återställ det sedan.
E-post cirkulerar mellan Google och Sophos: stoppa ändringen. Jämför primär MX, routing-mx.example.com, Googles utgående rutt och rubrikhopp sida vid sida. Sophos leveransdestination måste vara Google, inte Sophos; Googles utgående regel får inte fånga e-post som Sophos levererat inkommande igen.
Bara enskilda mottagare misslyckas: kontrollera att mottagaren finns och stavas identiskt i Sophos Email och Google Workspace, inklusive upplösning av alias och grupper. Kringgå inte domän- eller mottagarfel med ett brett relay-tillstånd.

Om DNS, ruttomfattning, värdar, domänmatchning, TLS och mottagare är korrekta men det dokumenterade felet fortfarande kan reproduceras, lämnar du Message-ID, tidsstämpel, avsändare, mottagare, relevanta rubriker och poster från Sophos Message History och Google-spårningen till Sophos Support. Då kan det berörda hoppet undersökas utan fler ändringar av produktionsregler på måfå.