Configurer Sophos Email Gateway avec Microsoft 365

Avec Sophos Gateway, l’enregistrement MX public pointe vers Sophos. Sophos analyse les messages entrants et les remet à Exchange Online par un connecteur partenaire restreint. Pour les messages sortants, un second connecteur les envoie de Microsoft 365 vers le smart host Sophos.

Parcours rapide sûr : consignez d’abord le domaine, les destinataires, la destination Microsoft et le chemin de retour. Préparez le connecteur entrant avec restrictions TLS et IP, puis ses règles. Créez et validez le connecteur sortant. Basculez seulement ensuite le MX et la route sortante. Adaptez SPF au chemin qui émet réellement, pas à un état futur.

Cette procédure concerne les connecteurs Gateway configurés manuellement sous Gateway Domains. Sophos Mailflow est une autre architecture : Sophos y gère applications, connecteurs et règles de flux via les API Microsoft. Ne combinez jamais les deux pour un domaine, au risque de créer une double analyse ou une boucle.

Préparer les prérequis et les valeurs

Il faut des droits d’administrateur Exchange, l’accès DNS, une licence Sophos Email et un domaine Gateway planifié. Avant toute modification, exportez ou consignez MX, SPF, connecteurs et règles actuels avec leur priorité et leur état.

Dans Sophos Fusion (anciennement Sophos Central), ouvrez Global Settings > Products and Services > Email > Gateway Domains, puis ajoutez ou contrôlez :

votre domaine de messagerie ;
comme destination, le FQDN MX attendu affiché pour le domaine sous Domains dans Microsoft 365 ;
le port SMTP réellement utilisé ;
la valeur TXT propre au domaine fournie par Verify Domain Ownership ;
toutes les boîtes protégées et leurs alias.

Séparez les sources des valeurs : le FQDN de destination de remise vient de Domains dans votre tenant Microsoft 365, et Verify Domain Ownership génère le TXT propre à ce domaine. Sophos publie les valeurs régionales variables dans les tableaux des IP de remise, MX et SPF. Copiez l’Outbound Relay Host depuis les dépendances externes du domaine dans Sophos Fusion. N’utilisez aucune valeur d’une autre région ni aucun exemple en production. La sortie peut être désactivée par défaut sur un nouvel essai Gateway ; demandez son activation au partenaire ou commercial Sophos.

1. Restreindre le chemin entrant avant de modifier le MX

Créer le connecteur partenaire

Dans Exchange admin center > Mail flow > Connectors, créez un connecteur :

From: Partner organization ; To: Office 365.
Un nom clair, par exemple Sophos Email Inbound Connector.
Use the sender’s domain, avec * comme domaine expéditeur.
Activez Reject email messages if they aren’t sent over TLS.
Activez Reject email messages if they aren’t sent from within this IP address range et saisissez seulement les IP de remise Sophos Email actuelles de votre région Central.
Vérifiez et enregistrez ; activez-le quand les autres protections sont prêtes.

Ajoutez les mêmes IP actuelles à la stratégie de filtre de connexion par défaut dans Microsoft 365 Defender. Cette entrée identifie les sources Sophos auprès du filtre ; une IP Allow List ne ferme pas un chemin de remise direct. Le connecteur partenaire activé impose le chemin entrant accepté, car il s’applique au domaine expéditeur *, exige TLS et limite la remise à ces IP Sophos.

Configurer Enhanced Filtering et le contournement EOP

Activez Enhanced Filtering for Connectors (aussi appelé skip listing) sur ce connecteur entrant précis. Sans ce réglage, Microsoft 365 peut mal classer l’expéditeur d’origine derrière Sophos.

Créez ensuite sous Mail flow > Rules cette règle de transport :

Name: Sophos Email EOP Bypass.
Apply this rule if: Apply to all messages.
Do the following: Modify the message properties > Set the spam confidence level (SCL) à -1.
Aucune exception ; mode Enforce, Severity: Low.
Enregistrez et activez la règle.

Cette règle SCL large n’est acceptable que si le MX et les restrictions TLS/IP garantissent que le courrier Internet arrive après analyse Sophos. S’il reste un chemin direct ou tiers, arrêtez la bascule et fermez-le d’abord.

2. Créer le connecteur sortant via Sophos

Dans Gateway Domains, sélectionnez le domaine, réglez Direction sur Inbound and Outbound, choisissez Microsoft Office 365 sous Outbound Gateway, puis enregistrez. Copiez l’Outbound Relay Host affiché sous Configure External Dependencies > Outbound Settings.

Dans Exchange admin center > Mail flow > Connectors, créez :

From: Office 365 ; To: Partner organization.
Un nom tel que Sophos Email Outbound Connector, avec Turn it on.
Only when email messages are sent to these domains, avec * si tout courrier externe doit passer par Sophos.
Route email through these smart hosts, avec l’Outbound Relay Host copié.
Always use Transport Layer Security (TLS) to secure the connection et Any digital certificate, including self-signed certificates.
Saisissez un destinataire d’un domaine externe et lancez Validate. Enregistrez seulement après réussite.

Ne désactivez ou supprimez les autres connecteurs sortants qu’après validation de celui de Sophos. Examinez séparément la portée et la priorité des chemins spéciaux comme l’archivage. La propagation peut prendre du temps.

Pour Microsoft 365 GCC High, n’utilisez pas le choix Sophos standard Microsoft Office 365 si les messages sortants sont rejetés. Sélectionnez Custom Gateway et ajoutez les sous-réseaux requis depuis les points de terminaison Exchange Online GCC High actuels de Microsoft. Ne reprenez pas une ancienne liste d’IP.

3. Basculer DNS et routage de façon contrôlée

Réduisez le TTL DNS bien avant la maintenance et consignez les valeurs d’origine. Respectez cet ordre :

Contrôlez Enhanced Filtering et l’entrée du filtre de connexion. Activez d’abord le connecteur partenaire entrant et confirmez que le domaine expéditeur *, TLS et la restriction aux IP de remise Sophos sont actifs ; activez ensuite la règle SCL juste avant la modification du MX.
Remplacez les MX publics par les noms actuels du tableau MX régional Sophos. Envoyez un message identifiable sans ambiguïté depuis un compte externe vers une boîte protégée et confirmez exactement ce message dans Microsoft 365 Message Trace et Sophos Message History.
Validez le connecteur sortant Sophos et conservez la configuration documentée de l’ancien connecteur pour le retour arrière. Basculez ensuite volontairement le routage de production : gardez le connecteur Sophos activé avec la portée destinataire * et désactivez chaque connecteur sortant standard qui se chevauche. Examinez séparément les chemins spéciaux comme l’archivage.
Seulement après ce changement d’état et de portée, envoyez un message identifiable sans ambiguïté depuis Microsoft 365 vers une adresse externe contrôlée. Confirmez exactement ce message dans Microsoft 365 Message Trace et dans la vue sortante de Sophos Message History. Un test envoyé avant la bascule ne prouve pas le chemin Sophos.

Publiez un seul TXT SPF par domaine. Tant que Microsoft 365 et Sophos émettent réellement en parallèle, ajoutez l’include Sophos régional actuel à l’enregistrement existant. Quand Sophos est l’unique émetteur, l’include Microsoft peut être retiré. N’utilisez -all que si toutes les sources légitimes sont connues et passent par Sophos ; ~all perturbe moins une transition contrôlée. Vérifiez également signature et alignement DKIM.

Valider et revenir en arrière

Testez chaque domaine dans les deux sens avec une adresse externe contrôlée. Dans Microsoft 365 Message Trace, vérifiez expéditeur, destinataire, heure, Message-ID, état et remise finale attendus ; le Message Trace ordinaire ne sert pas ici de preuve du traitement des connecteurs ou des règles. Dans Sophos Fusion, ouvrez Reports > Message History, examinez les deux directions et faites correspondre ces détails exactement aux mêmes messages de test. La bascule est terminée seulement lorsque les deux systèmes contiennent chaque test postérieur au changement.

En cas de non-remise ou de boucle, utilisez le retour préparé :

Pour la sortie, réactivez l’ancien connecteur fonctionnel, puis désactivez le connecteur sortant Sophos avant tout test de retour. Confirmez la remise externe seulement après cette transition d’état.
Pour l’entrée, désactivez d’abord la règle SCL large propre à Sophos et le connecteur entrant limité aux IP Sophos, puis retirez les entrées Sophos du filtre de connexion. Restaurez seulement ensuite le MX Microsoft d’origine. Tenez compte de la propagation DNS : vérifiez la réponse MX faisant autorité et répétez des tests de remise externes contrôlés jusqu’à ce qu’ils empruntent le chemin restauré.
Adaptez SPF seulement après le retour effectif du chemin d’émission.
Ne supprimez rien avant d’avoir contrôlé propagation DNS, files d’attente et les deux traces.

Diagnostiquer par symptôme

L’entrée apparaît seulement dans Sophos : contrôlez FQDN de destination, port SMTP, boîtes, IP actuelles et négociation TLS.
L’entrée atteint Microsoft directement : contrôlez propagation MX et autres MX ou redirections ; la règle SCL ne doit pas masquer un chemin non protégé.
La sortie contourne Sophos : contrôlez portée *, état, connecteurs concurrents et priorité.
La validation échoue : recopiez le relay host, contrôlez TLS et utilisez un destinataire réellement externe.
SPF échoue : inventoriez les émetteurs réels et recherchez plusieurs SPF, un mauvais include régional ou un -all prématuré.
GCC High est rejeté : contrôlez Custom Gateway et les sous-réseaux Exchange Online GCC High actuels.
Boucle ou double analyse : examinez ensemble connecteurs Gateway et Mailflow gérés par API, anciens smart hosts, redirections et priorités des règles. Désactivez le dernier chemin activé et retestez dans les deux traces.

Pour une escalade, collectez heures, expéditeur, destinataire, Message-ID, noms des connecteurs, priorités et entrées correspondantes de Message Trace et Message History. Le routage peut ainsi être étudié sans affaiblir la protection par une exception large.