Configurare Sophos Email Gateway con Google Workspace

Con un’integrazione Gateway, la posta in entrata segue Internet → Sophos Gateway → Google Workspace, mentre quella in uscita segue Google Workspace → Sophos Gateway → Internet. Per una migrazione sicura, configura e prova ogni destinazione, gateway e route interna prima di modificare i record MX di produzione. In ogni fase rimangono così disponibili un percorso di consegna noto e una via di ripristino.

Percorso rapido: verifica il dominio in Sophos Central, prepara l’host di consegna Google separato, aggiungi le caselle, limita l’Inbound Gateway Google agli indirizzi IP Sophos regionali e instrada i messaggi interni direttamente a Google. Inserisci poi l’Outbound Relay Host mostrato in Sophos Central come gateway in uscita di Google. Modifica i record MX principali con i valori mostrati per la tua regione Sophos solo dopo aver provato entrambe le direzioni.

Ambito e prerequisiti

Questa guida riguarda Sophos Email in modalità Gateway con Google Workspace. Servono accesso amministrativo a Sophos Central, alla Console di amministrazione Google e al DNS del dominio di posta. Il dominio deve essere configurato in Sophos Gateway e ogni destinatario protetto deve esistere in Sophos Email.

Prima di iniziare, annota in una scheda di modifica:

dominio di posta e unità organizzativa Google Workspace interessata;
set MX di produzione attuale, incluse priorità e TTL;
record SPF attuale e configurazione DKIM e DMARC esistente;
valori MX, Delivery IP, relay e SPF mostrati in Sophos Central per la tua regione dati;
destinazioni MX attualmente indicate da Google per il tenant;
un mittente di test esterno e uno interno, più un destinatario interno e uno esterno;
requisiti TLS previsti e finestra di manutenzione o ripristino.

Non copiare host o indirizzi IP regionali da esempi o vecchi ticket. Copiali da Sophos Central subito prima della modifica. Verifica anche le destinazioni Google nella documentazione Google corrente o nell’interfaccia del tenant.

Confine del prodotto: Google Post Delivery Protection e la sincronizzazione Google Directory non modificano né sostituiscono questa architettura di routing SMTP. Sono attività separate e qui non vengono trattate.

Preparare la modifica in sicurezza

Documenta il flusso attuale con un messaggio di test in entrata e uno in uscita. Conserva intestazioni e traccia Google e conferma che non appaiano ancora nella Message History di Sophos.
Riduci con sufficiente anticipo il TTL DNS degli MX di produzione a un valore adatto all’operatività. Documenta il vecchio set MX e tutte le regole di routing Google come stato di ripristino.
Verifica se sono già attivi un altro secure email gateway, un Google Outbound Gateway o una regola catch-all. Non applicare in parallelo regole sovrapposte agli stessi messaggi.
Usa un piccolo gruppo pilota o una finestra di test pianificata. Attiva protezioni come Reject all mail not from gateway IPs solo dopo aver inserito tutti i Sophos Delivery IP regionali e provato i percorsi interni Google.

La misura principale contro i loop è separare chiaramente le destinazioni: l’MX principale punterà a Sophos, mentre la destinazione salvata in Sophos punta a una destinazione Google distinta e mai di nuovo all’MX Sophos. La route in uscita Google punta a Sophos, ma non deve essere riapplicata ai messaggi in entrata già consegnati da Sophos.

Configurare il flusso in entrata

Preparare dominio e destinazione Google in Sophos

In Sophos Central apri Global Settings > Products and Services > Email > Gateway Domains, quindi seleziona o aggiungi il dominio.
Come Delivery Destination usa un nome MX separato sotto il tuo dominio, ad esempio routing-mx.example.com, e inserisci la porta SMTP documentata da Sophos. È un percorso DNS dedicato alle consegne di Sophos, non l’MX di produzione del dominio principale.
Avvia Verify Domain Ownership, pubblica nel DNS senza modifiche il valore TXT mostrato per il dominio e verifica di nuovo dopo la propagazione.
Crea per routing-mx.example.com record MX diretti alle destinazioni Google correnti indicate per il tenant Google Workspace. Non devono puntare a Sophos.
Aggiungi a Sophos Email ogni casella o destinatario protetto e salva la configurazione del dominio.

La verifica riesce quando Sophos Central mostra il dominio come verificato e una query DNS per routing-mx.example.com restituisce solo le destinazioni Google previste.

Se la consegna tramite ASPMX.L.GOOGLE.COM presenta problemi, modifica esclusivamente la destinazione di consegna Google dietro routing-mx.example.com impostandola su SMTP.GOOGLE.COM. È un’alternativa condizionale per la consegna da Sophos a Google, non un’impostazione predefinita universale né una modifica dell’MX di produzione del dominio principale, che continua a puntare a Sophos. Prima conferma i valori validi per il tuo ambiente Google Workspace, quindi prova di nuovo il flusso in entrata. Se anche questa prova non riesce, ripristina la destinazione di consegna Google documentata in precedenza e contatta il supporto Sophos.

Proteggere l’Inbound Gateway Google

Nella Console di amministrazione Google apri Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway per l’organizzazione principale interessata.
Attiva l’Inbound Gateway e aggiungi solo i Delivery IP elencati in Sophos Central per la tua regione.
Attiva Automatically detect external IP e il requisito TLS concordato.
Attiva Reject all mail not from gateway IPs solo dopo una prova pilota. L’opzione blocca la consegna diretta e impedisce di aggirare Sophos, ma un elenco IP incompleto può fermare anche posta legittima.
Salva e attendi fino a 24 ore perché l’impostazione in entrata diventi effettiva.

Se la restrizione rigida blocca percorsi di consegna propri di Google, disattiva temporaneamente il rifiuto, ripristina il flusso e determina gli indirizzi Google e Sophos correnti necessari dalle indicazioni dei produttori. Non autorizzare genericamente reti sconosciute.

Sophos segnala un’anomalia DMARC riscontrata nei propri test: se sono attivi Time of Click URL Protection o le impostazioni dei messaggi per gli utenti finali, Google a volte contrassegna i messaggi in entrata come errori DMARC, sebbene la documentazione di Google affermi che l’autenticazione DMARC viene ignorata per i messaggi provenienti dagli host elencati nel gateway e che il controllo deve essere eseguito dal gateway in entrata. Sophos dichiara di aver segnalato questa discrepanza a Google. Considerala prima di interpretare l’errore come prova che Automatically detect external IP o l’elenco Delivery IP siano errati.

Instradare i messaggi interni direttamente a Google

I messaggi interni non devono passare dall’MX di produzione a Sophos e poi tornare a Google. In Apps > Google Workspace > Gmail > Hosts crea quindi una route con le destinazioni Google correnti del tenant. In Apps > Google Workspace > Gmail > Routing applicala solo a Internal - Sending e limitala al tuo dominio con un filtro sul mittente della busta. Attiva TLS e la convalida di un certificato firmato da una CA secondo le indicazioni Google e Sophos.

Assegna alla route interna e alla regola del gateway in uscita ambiti e condizioni di corrispondenza non sovrapposti. Salva la modifica di routing e attendi fino a 24 ore perché diventi effettiva; puoi seguire le modifiche nel log di controllo amministrativo di Google Workspace. Non iniziare la convalida dei messaggi interni o del pilota e non modificare l’MX di produzione finché la modifica non è effettiva. Invia quindi un messaggio interno a un destinatario dello stesso dominio: deve rimanere in Google e non apparire anche come scansione in entrata e in uscita in Sophos.

Configurare il flusso in uscita

Apri il dominio in Gateway Domains e seleziona Inbound and Outbound sotto Configure Domain.
Seleziona Google Apps Gmail come Outbound Gateway, salva e copia l’Outbound Relay Host mostrato per il tenant in Configure External Dependencies > Outbound Settings. Questa etichetta rappresenta Google Workspace in Sophos Central.
Nella Console Google apri la configurazione del gateway in uscita per l’organizzazione principale interessata e inserisci esattamente quel Relay Host. L’interfaccia Google corrente può disporre diversamente la sezione di routing: non ricavare host da esempi.
Assegna alla regola criteri di mittente e messaggio che non si sovrappongano alla route interna. Disattiva o rimuovi dallo stesso ambito una seconda regola catch-all o gateway.
Salva, attendi alcuni minuti perché l’impostazione in uscita diventi effettiva e invia prima da un mittente pilota a un indirizzo esterno di test.

Allineare SPF e DKIM al percorso di invio reale

Il record SPF deve coprire ogni percorso che invia realmente posta autorizzata, senza conservare percorsi inutilizzati. Durante una transizione controllata possono essere autorizzati sia Google Workspace sia Sophos. Quando tutta la posta in uscita passa esclusivamente da Sophos, rimuovi il vecchio percorso diretto Google solo se nessuna applicazione, inoltro o piattaforma terza lo usa ancora.

Preleva da Sophos Central il valore include SPF Sophos regionale; un esempio qui sarebbe rischioso. Prima di salvare, verifica che il dominio abbia ancora esattamente un record TXT SPF e che la strategia -all o ~all scelta sia adatta alla migrazione. Mantieni attive le firme DKIM e, separatamente, mantieni DMARC attivo; verificali su un messaggio ricevuto esternamente dopo la modifica.

Validare il pilota, quindi modificare l’MX di produzione

Prima del passaggio dell’MX di produzione, usa l’ambito pilota o la finestra di test per validare la consegna in uscita tramite Sophos e un messaggio interno che rimanga in Google. Conferma intestazioni previste, traccia Google e Sophos Message History e verifica che il record SPF preparato copra il percorso di invio reale del pilota.

Solo quando destinazione, destinatari, Inbound Gateway, route interna, gateway in uscita, preparazione SPF e controlli pilota funzionano, sostituisci il set MX di produzione del dominio principale con valori e priorità mostrati in Sophos Central per la tua regione. Durante la propagazione DNS mantieni documentati stato precedente, responsabile e decisione di ripristino. Se la consegna fallisce, ripristina il set MX salvato invece di aggiungere altre route non provate.

Verificare entrambe le direzioni

Dopo ogni modifica, attendi la propagazione ed esegui quattro prove mirate:

esterno → destinatario interno protetto;
utente interno → destinatario esterno;
utente interno → utente interno dello stesso dominio;
tentativo di consegna diretta che aggira Sophos, se autorizzato ed eseguibile in sicurezza.

Per le prove 1 e 2, in Sophos Central sotto Reports > Message History deve apparire esattamente una voce corrispondente con direzione, mittente, destinatario, ora ed esito corretti. Esamina in parallelo la traccia Google e le intestazioni complete del messaggio consegnato. La catena Received deve mostrare il percorso previsto nell’ordine corretto; controlla SPF, DKIM e DMARC sulla destinazione esterna.

La prova 3 non deve attraversare Sophos due volte inutilmente. La prova 4 deve essere rifiutata dopo l’attivazione della restrizione rigida dell’Inbound Gateway. Più voci Sophos per lo stesso Message-ID, host ripetuti nella catena Received o tempi di consegna in forte aumento indicano elaborazione duplicata o un loop.

Risolvere i problemi in modo mirato

Manca la posta esterna in entrata: controlla prima l’MX di produzione e la regione, poi Sophos Message History. Se non c’è una voce, il guasto precede Sophos. Se c’è ma Google non riceve, controlla routing-mx.example.com, destinazioni Google, destinatari, restrizione Delivery IP e TLS.
La posta in uscita manca in Sophos: controlla ambito e condizioni di corrispondenza delle regole Google e l’Outbound Relay Host inserito. Se appare in Sophos ma non a destinazione, esamina stato di consegna, SPF/DKIM/DMARC ed errore del sistema destinatario.
La posta interna appare due volte in Sophos: conferma che Internal - Sending corrisponda solo al tuo dominio e che nessuna regola generale corrisponda agli stessi messaggi. Rimuovi regole in uscita o catch-all sovrapposte invece di aggiungere un altro bypass.
Errore TLS: confronta host sorgente e destinazione, nome del certificato, fiducia CA e opzione TLS richiesta su entrambi i lati. Non disattivare il requisito in modo permanente; allentalo per un test solo dopo una decisione di rischio documentata, poi ripristinalo.
La posta rimbalza tra Google e Sophos: interrompi la modifica. Confronta MX principale, routing-mx.example.com, route in uscita Google e hop delle intestazioni. La destinazione Sophos deve essere Google, non Sophos; la regola in uscita Google non deve riprendere posta consegnata in entrata da Sophos.
Falliscono solo alcuni destinatari: controlla esistenza e grafia identica in Sophos Email e Google Workspace, inclusa la risoluzione di alias e gruppi. Non aggirare errori di dominio o destinatario con un’autorizzazione relay ampia.

Se DNS, ambito delle route, host, corrispondenza del dominio, TLS e destinatari sono corretti ma l’errore documentato resta riproducibile, fornisci al supporto Sophos Message-ID, data e ora, mittente, destinatario, intestazioni pertinenti e voci di Sophos Message History e della traccia Google. Sarà possibile analizzare l’hop interessato senza modificare altre regole di produzione per tentativi.