Configurer Sophos Email Gateway avec Google Workspace

Avec une intégration Gateway, le courrier entrant suit Internet → Sophos Gateway → Google Workspace et le courrier sortant Google Workspace → Sophos Gateway → Internet. Pour une migration sûre, configurez et testez chaque destination, passerelle et route interne avant de modifier les enregistrements MX de production. Un chemin de remise connu et une possibilité de retour restent ainsi disponibles à chaque étape.

Parcours rapide : vérifiez le domaine dans Sophos Fusion (anciennement Sophos Central), préparez l’hôte de remise Google distinct, ajoutez les boîtes aux lettres, limitez l’Inbound Gateway Google aux adresses IP Sophos régionales et acheminez les messages internes directement vers Google. Saisissez ensuite l’Outbound Relay Host affiché dans Sophos Fusion comme passerelle sortante Google. Ne remplacez les MX principaux par les valeurs affichées pour votre région Sophos qu’après avoir testé les deux sens.

Périmètre et prérequis

Ce guide concerne Sophos Email en mode Gateway avec Google Workspace. Il faut un accès administrateur à Sophos Fusion, à la console d’administration Google et au DNS du domaine de messagerie. Le domaine doit être configuré dans Sophos Gateway et chaque destinataire protégé doit exister dans Sophos Email.

Consignez les données suivantes dans la fiche de changement :

domaine de messagerie et unité organisationnelle Google Workspace concernée ;
jeu de MX de production actuel, priorités et TTL compris ;
enregistrement SPF actuel et configuration DKIM et DMARC existante ;
valeurs MX, Delivery IP, relais et SPF affichées dans Sophos Fusion pour votre région de données ;
destinations MX actuellement imposées par Google pour votre tenant ;
un expéditeur externe et interne de test, ainsi qu’un destinataire interne et externe ;
exigences TLS prévues et créneau de maintenance ou de retour arrière.

Ne copiez jamais les hôtes ou adresses IP régionaux depuis des exemples ou d’anciens tickets. Relevez-les dans Sophos Fusion juste avant le changement. Vérifiez aussi les destinations Google dans la documentation actuelle de Google ou l’affichage du tenant.

Limite du produit : Google Post Delivery Protection et la synchronisation de l’annuaire Google ne modifient ni ne remplacent cette architecture de routage SMTP. Ce sont des tâches distinctes, hors périmètre ici.

Préparer le changement en toute sécurité

Documentez le flux actuel avec un message entrant et un message sortant de test. Conservez les en-têtes et la trace Google, puis vérifiez qu’ils n’apparaissent pas encore dans Message History de Sophos.
Réduisez suffisamment tôt le TTL DNS des MX de production à une valeur adaptée à l’exploitation. Documentez l’ancien jeu de MX et toutes les règles de routage Google comme état de retour.
Vérifiez si une autre passerelle de messagerie sécurisée, un Google Outbound Gateway ou une règle de routage catch-all est actif. N’appliquez pas simultanément des règles qui se chevauchent aux mêmes messages.
Utilisez un petit périmètre pilote ou une fenêtre de test planifiée. N’activez une protection telle que Reject all mail not from gateway IPs qu’après avoir saisi toutes les Sophos Delivery IP régionales et testé les chemins internes Google.

La protection essentielle contre les boucles est une séparation sans ambiguïté des destinations : le MX principal pointera vers Sophos, tandis que la destination enregistrée dans Sophos pointe vers une destination Google distincte et jamais vers le MX Sophos. La route sortante Google pointe vers Sophos, mais ne doit pas reprendre les messages entrants déjà remis par Sophos.

Configurer le flux entrant

Préparer le domaine et la destination Google dans Sophos

Dans Sophos Fusion, ouvrez Global Settings > Products and Services > Email > Gateway Domains, puis sélectionnez ou ajoutez le domaine.
Comme Delivery Destination, utilisez un nom MX distinct sous votre domaine, par exemple routing-mx.example.com, et saisissez le port SMTP documenté par Sophos. Ce nom est un chemin DNS réservé aux remises de Sophos, pas le MX de production du domaine principal.
Lancez Verify Domain Ownership, publiez sans le modifier le TXT affiché pour ce domaine dans le DNS, puis recommencez la vérification après propagation.
Créez pour routing-mx.example.com des MX pointant vers les destinations Google actuelles prévues pour votre tenant Google Workspace. Ils ne doivent pas pointer vers Sophos.
Ajoutez chaque boîte ou destinataire protégé dans Sophos Email et enregistrez la configuration du domaine.

La vérification réussit lorsque Sophos Fusion affiche le domaine comme vérifié et qu’une requête DNS sur routing-mx.example.com ne renvoie que les destinations Google prévues.

Si la remise via ASPMX.L.GOOGLE.COM pose problème, remplacez uniquement la destination de remise Google située derrière routing-mx.example.com par SMTP.GOOGLE.COM. Il s’agit d’une solution de remplacement conditionnelle pour la remise de Sophos à Google, et non d’une valeur par défaut universelle ni d’une modification du MX de production du domaine principal, qui continue de pointer vers Sophos. Confirmez d’abord les valeurs valides pour votre environnement Google Workspace, puis testez de nouveau le flux entrant. Si ce test échoue également, restaurez la destination de remise Google précédemment documentée et contactez le support Sophos.

Sécuriser l’Inbound Gateway Google

Dans la console d’administration Google, ouvrez Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway pour l’organisation racine concernée.
Activez l’Inbound Gateway et ajoutez uniquement les Delivery IP indiquées dans Sophos Fusion pour votre région.
Activez Automatically detect external IP et l’exigence TLS convenue.
N’activez Reject all mail not from gateway IPs qu’après un test pilote. Cette option bloque les remises directes et empêche donc le contournement de Sophos, mais une liste IP incomplète peut aussi bloquer des messages légitimes.
Enregistrez et attendez jusqu’à 24 heures que le paramètre entrant prenne effet.

Si la restriction stricte bloque les propres chemins de remise de Google, désactivez temporairement le rejet, rétablissez le flux et déterminez les adresses Google et Sophos actuelles nécessaires d’après les indications des fabricants. N’autorisez pas largement des réseaux inconnus.

Sophos signale une anomalie DMARC constatée lors de ses propres tests : si Time of Click URL Protection ou les paramètres de messages des utilisateurs finaux sont activés, Google marque parfois des messages entrants comme des échecs DMARC, alors que la documentation Google indique que l’authentification DMARC est contournée pour les messages provenant d’hôtes répertoriés dans la passerelle et que la passerelle entrante doit effectuer le contrôle. Sophos indique avoir signalé cet écart à Google. Tenez-en compte avant d’interpréter un échec comme la preuve que Automatically detect external IP ou la liste Delivery IP est incorrecte.

Acheminer les messages internes directement vers Google

Les messages internes ne doivent pas passer par le MX de production vers Sophos puis revenir à Google. Dans Apps > Google Workspace > Gmail > Hosts, créez donc une route avec les destinations Google actuelles du tenant. Dans Apps > Google Workspace > Gmail > Routing, appliquez-la uniquement à Internal - Sending et limitez-la à votre domaine avec un filtre sur l’expéditeur d’enveloppe. Activez TLS et la validation d’un certificat signé par une CA conformément aux prescriptions Google et Sophos.

Attribuez à la route interne et à la règle de passerelle sortante des périmètres et des conditions de correspondance qui ne se chevauchent pas. Enregistrez la modification de routage et attendez jusqu’à 24 heures qu’elle prenne effet ; vous pouvez suivre les modifications dans le journal d’audit d’administration Google Workspace. Ne commencez pas la validation des messages internes ou du pilote et ne basculez pas le MX de production avant que la modification soit effective. Envoyez ensuite un message interne à un destinataire du même domaine : il doit rester chez Google et ne pas apparaître en plus comme analyse entrante et sortante dans Sophos.

Configurer le flux sortant

Ouvrez le domaine dans Gateway Domains et choisissez Inbound and Outbound sous Configure Domain.
Sélectionnez Google Apps Gmail comme Outbound Gateway, enregistrez, puis copiez l’Outbound Relay Host affiché pour ce tenant sous Configure External Dependencies > Outbound Settings. Ce libellé représente Google Workspace dans Sophos Fusion.
Dans la console Google, ouvrez la configuration de passerelle sortante de l’organisation racine concernée et saisissez exactement ce Relay Host. L’interface Google actuelle peut présenter le routage autrement ; ne déduisez aucun nom d’hôte d’un exemple.
Donnez à la règle des critères d’expéditeur et de message qui ne chevauchent pas la route interne. Désactivez ou retirez du même périmètre toute seconde règle catch-all ou de passerelle.
Enregistrez, attendez plusieurs minutes que le paramètre sortant prenne effet, puis commencez par envoyer d’un expéditeur pilote vers une adresse externe de test.

Aligner SPF et DKIM sur le chemin d’envoi réel

L’enregistrement SPF doit couvrir tous les chemins qui envoient réellement des messages autorisés, sans conserver ceux qui ne servent plus. Pendant une transition contrôlée, Google Workspace et Sophos peuvent être autorisés ensemble. Quand tous les messages sortants passent exclusivement par Sophos, ne retirez l’ancien chemin direct Google que si aucune application, redirection ou plateforme tierce ne l’utilise encore.

Prenez la valeur d’inclusion SPF Sophos régionale dans Sophos Fusion ; un exemple serait dangereux ici. Avant d’enregistrer, vérifiez que le domaine possède toujours exactement un enregistrement TXT SPF et que la stratégie -all ou ~all choisie convient à la migration. Laissez les signatures DKIM actives et, séparément, laissez DMARC actif ; contrôlez-les sur un message reçu à l’extérieur après le changement.

Valider le pilote, puis modifier le MX de production

Avant la bascule du MX de production, utilisez le périmètre pilote ou la fenêtre de test pour valider la remise sortante via Sophos et un message interne qui reste chez Google. Confirmez les en-têtes attendus, la trace Google et Sophos Message History, puis vérifiez que l’enregistrement SPF préparé couvre le chemin d’envoi réel du pilote.

Ne remplacez le jeu de MX de production du domaine principal par les valeurs et priorités affichées dans Sophos Fusion pour votre région qu’une fois la destination, les destinataires, l’Inbound Gateway, la route interne, la passerelle sortante, la préparation SPF et les contrôles pilotes opérationnels. Pendant la propagation DNS, conservez l’état précédent, le responsable et la décision de retour documentés. En cas d’échec, restaurez le jeu de MX sauvegardé au lieu d’ajouter d’autres routes non testées.

Valider les deux sens

Après chaque modification, attendez la propagation, puis effectuez quatre tests ciblés :

externe → destinataire interne protégé ;
utilisateur interne → destinataire externe ;
utilisateur interne → utilisateur interne du même domaine ;
tentative de remise directe contournant Sophos, si ce test est autorisé et réalisable en sécurité.

Pour les tests 1 et 2, un seul enregistrement correspondant, avec sens, expéditeur, destinataire, heure et résultat corrects, doit apparaître dans Sophos Fusion sous Reports > Message History. Examinez en parallèle la trace Google et tous les en-têtes du message remis. La chaîne Received doit montrer le chemin attendu dans le bon ordre ; contrôlez SPF, DKIM et DMARC à la destination externe.

Le test 3 ne doit pas traverser Sophos deux fois inutilement. Le test 4 doit être rejeté une fois la restriction stricte de l’Inbound Gateway active. Plusieurs entrées Sophos pour le même Message-ID, des hôtes répétés dans la chaîne Received ou une forte hausse du délai signalent un double traitement ou une boucle.

Dépanner méthodiquement

Le courrier externe entrant manque : vérifiez d’abord le MX de production et sa région, puis Sophos Message History. Sans entrée, le défaut précède Sophos. Avec une entrée mais sans remise Google, vérifiez routing-mx.example.com, les destinations Google, les destinataires, la restriction Delivery IP et TLS.
Le courrier sortant manque dans Sophos : vérifiez le périmètre et les conditions de correspondance des règles Google ainsi que l’Outbound Relay Host saisi. S’il apparaît dans Sophos mais pas à destination, analysez l’état de remise, SPF/DKIM/DMARC et l’erreur du système cible.
Le courrier interne apparaît deux fois dans Sophos : confirmez que Internal - Sending ne vise que votre domaine et qu’aucune règle générale ne vise les mêmes messages. Supprimez les règles sortantes ou catch-all qui se chevauchent au lieu d’ajouter un autre contournement.
Erreur TLS : comparez hôtes source et cible, nom de certificat, confiance CA et option TLS exigée des deux côtés. Ne désactivez pas durablement l’exigence ; ne l’assouplissez pour un test qu’après une décision de risque documentée, puis rétablissez-la.
Le courrier boucle entre Google et Sophos : arrêtez le changement. Comparez le MX principal, routing-mx.example.com, la route sortante Google et les sauts des en-têtes. La destination Sophos doit être Google, pas Sophos ; la règle sortante Google ne doit pas reprendre les messages entrants remis par Sophos.
Seuls certains destinataires échouent : vérifiez l’existence et l’orthographe identique du destinataire dans Sophos Email et Google Workspace, y compris la résolution des alias et groupes. Ne contournez pas une erreur de domaine ou de destinataire par une autorisation de relais large.

Si le DNS, le périmètre des routes, les hôtes, la correspondance du domaine, TLS et les destinataires sont corrects, mais que l’erreur documentée reste reproductible, transmettez au support Sophos le Message-ID, l’horodatage, l’expéditeur, le destinataire, les en-têtes utiles et les entrées de Sophos Message History et de la trace Google. Le saut concerné pourra être analysé sans modifier d’autres règles de production au hasard.