Aller au contenu
Avanet

Sophos Email Mailflow : réparer Microsoft 365 méthodiquement

Sophos Email

Si Sophos Email Mailflow tombe en panne dans Microsoft 365, il ne faut pas supprimer des connecteurs ou des règles de transport au hasard. Il faut d’abord lire l’état du domaine dans Sophos Fusion (anciennement Sophos Central), lancer Run a Quick Test, puis comparer le même message dans Microsoft Message Trace et Sophos Message History. La réparation vient ensuite.

Parcours rapide : Connected avec une coche verte indique que la connexion Mailflow fonctionne. Not Connected avec une croix rouge impose de contrôler la connexion ou les autorisations. Un point d’exclamation accompagné de View Details signale une règle ou un connecteur modifié directement dans Microsoft 365. Pour une erreur 552, la présence d’en-têtes Sophos et Microsoft en double indique souvent qu’un service de signature a renvoyé le message vers Sophos.

Ce guide concerne uniquement Sophos Email en mode Mailflow (MFR). Les enregistrements MX restent dirigés vers Microsoft 365, tandis que les règles de transport et connecteurs Microsoft acheminent les messages vers Sophos puis les ramènent. En mode Gateway, les MX pointent vers Sophos : le diagnostic et la suppression sont donc différents. Il ne faut pas appliquer les instructions Gateway à un domaine Mailflow. Le déploiement et la migration planifiée sont décrits dans Configurer Sophos Email Mailflow pour Microsoft 365.

Prérequis et point de départ sûr

Il faut un accès administratif à Sophos Fusion et un compte capable d’accorder le consentement à l’application Sophos Email ainsi que les autorisations de flux de messagerie Exchange Online. Les domaines Microsoft 365 doivent être admissibles à Mailflow et les utilisateurs et groupes requis doivent être synchronisés.

Avant toute modification, consigner :

  • domaine, expéditeur, destinataire, heure UTC, Internet Message-ID et en-têtes complets ;
  • état Mailflow Connection et, le cas échéant, Post Delivery ;
  • nom, activation et priorité des règles et connecteurs Sophos, du service de signature et des autres services ;
  • résultats de Microsoft Message Trace et Sophos Message History ;
  • dernière configuration opérationnelle et responsable de chaque modification.

Ne modifier qu’un facteur par test. Ne pas supprimer le domaine xgeconnector.com créé par Sophos, car cela peut interrompre le flux et le traitement. Ne pas effacer non plus un connecteur apparemment orphelin avant d’avoir documenté son domaine et le retour arrière.

1. Vérifier la connexion et l’état du domaine

  1. Dans Sophos Fusion, ouvrir Global Settings.
  2. Choisir Products and Services > Email > M365 Mailflow Domains.
  3. Examiner le domaine :
    • coche verte, Connected : la connexion existe ;
    • croix rouge, Not Connected : survoler puis cliquer sur la coche verte pour reconnecter ;
    • point d’exclamation, View Details : rechercher une modification Microsoft 365.
  4. Cliquer sur l’icône de test. Sous Run a Quick Test, saisir une adresse contrôlée et sélectionner Proceed. Le test peut durer quelques minutes.
  5. En cas d’échec, utiliser d’abord Run The Test Again, puis Reconnect si l’échec persiste.

Un Quick Test réussi rétablit la coche verte, mais ne prouve pas la livraison de bout en bout. Envoyer ensuite un message entrant et un message sortant contrôlés et les suivre jusqu’au destinataire final dans Microsoft Message Trace et Sophos Message History.

Si Reconnect ne crée pas les règles ou connecteurs

Vérifier que l’application Sophos Mailflow dispose des affectations de rôle requises dans le tenant Microsoft 365. Les autorisations de flux Exchange Online doivent notamment être disponibles via le rôle d’administrateur Exchange. La réparation automatique exige un consentement valide et ces autorisations.

Si Reconnect échoue encore, ne pas multiplier les suppressions manuelles. Conserver l’état, le résultat du Quick Test, les noms des règles et connecteurs et le Message-ID, puis transmettre au support Sophos ; un nettoyage manuel peut être nécessaire.

2. Traiter une alerte concernant des objets Mailflow modifiés

Sophos surveille la désactivation, la suppression et la modification des règles et connecteurs indispensables à Mailflow. L’audit Microsoft 365 doit être activé et l’application Sophos Email doit posséder l’autorisation d’organisation Read activity data. Pour un domaine configuré avant le 12 avril 2022, l’accorder en déconnectant puis reconnectant le domaine ; les configurations ultérieures devraient déjà l’avoir.

Les alertes sont High, Medium ou Low. Toutes figurent dans Sophos Fusion ; seules High et Medium envoient aussi un e-mail aux administrateurs et super-administrateurs et changent l’état du domaine. Dans Alerts, regrouper les alertes, ouvrir Mail Flow Rules, puis View Details pour voir le domaine, l’heure, l’objet et la modification.

  • Renommage connu d’une liste de distribution : vérifier la synchronisation du nouveau groupe, le mettre à jour dans les paramètres du domaine M365 et enregistrer.
  • Modification intentionnelle : la documenter et lancer Run a Quick Test ; ne la conserver que si le test réussit.
  • Modification inconnue ou involontaire : identifier l’événement d’audit Microsoft 365 et son auteur. Annuler une erreur comprise puis relancer le test. Si la réparation n’est pas claire ou échoue, utiliser Reconnect afin que Sophos recrée ou active les objets nécessaires.

Une alerte seule ne prouve pas une interruption. Inversement, une modification planifiée n’est pas sûre simplement parce qu’elle est connue : Quick Test et les essais de livraison font foi.

3. Corriger les échecs SPF au retour dans Microsoft 365

Avec Mailflow, les messages sortants passent de Microsoft 365 à Sophos puis reviennent à Microsoft 365. Microsoft peut donc faire échouer SPF si l’expéditeur Sophos régional n’est pas autorisé dans l’enregistrement SPF du domaine.

v=spf1 include:spf.protection.outlook.com -all

Ajouter le domaine include publié pour la région Sophos Fusion :

v=spf1 include:spf.protection.outlook.com include:<sophos-spf-domain> -all

<sophos-spf-domain> est un espace réservé, pas une valeur à publier. Reprendre la valeur régionale actuelle dans Sophos Email domain information, conserver un seul enregistrement TXT SPF par domaine et ne pas modifier le mécanisme final sans contrôle. Après propagation DNS, vérifier le TXT publié et envoyer un test sortant ; SPF doit réussir pour le trajet attendu.

4. Corriger les transferts et Microsoft DLP

Un message transféré automatiquement vers l’extérieur est rejeté

Microsoft 365 réécrit avec SRS l’adresse envelope-from (P1 From). Si Header-From reste un domaine externe absent de Sophos Email, Sophos peut rejeter le message. Sophos ne relaie pas globalement les messages d’origine externe, car cela créerait un risque comparable à un relais ouvert et nuirait à la réputation.

  1. Dans Microsoft 365 Security Center, ouvrir Policies & rules > Threat policies > Rules > Enhanced filtering.
  2. Sélectionner le connecteur qui autorise les messages entrants de Sophos Email.
  3. Activer Automatically detect and skip the last IP address pour l’organisation.
  4. Configurer le transfert concerné afin qu’il utilise comme expéditeur une boîte locale du domaine protégé.
  5. Refaire le test avec le même expéditeur et la même destination ; comparer en-têtes, Message Trace et Message History.

Ne pas ajouter des domaines externes quelconques dans Sophos ni créer une large exception de relais.

Microsoft DLP envoie deux notifications

Si une règle DLP se déclenche lors des deux passages Mailflow, exclure uniquement de cette règle les adresses IP d’expéditeur Sophos Email documentées :

  1. Se connecter comme administrateur au portail DLP Microsoft Purview.
  2. Modifier la stratégie et la règle sous Advanced DLP rules > Customize advanced DLP rules.
  3. Choisir Add exception > Except if sender IP address is et saisir uniquement les IP Sophos régionales actuelles indiquées dans les informations de domaine.
  4. Enregistrer et répéter pour chaque règle concernée.
  5. Avec un message contrôlé, vérifier que l’évaluation DLP reste active mais ne produit qu’une notification.

Ne pas étendre l’exception à des plages inutiles ; DLP reste ainsi actif sur les autres trajets.

5. Analyser l’erreur 552 et les services de signature

Le NDR typique est :

552 5.6.0 Headers too large (32768 max)

Examiner les en-têtes complets. Des groupes en double tels que X-Sophos-Antispam, X-LASED-Hits, X-Microsoft-Antispam-Message-Info ou X-Microsoft-Antispam-Message-Info-Original signalent un traitement répété. Avec CodeTwo ou Exclaimer, le trajet incorrect est souvent :

Microsoft 365 > Sophos > Microsoft 365 > signature service > Microsoft 365 > Sophos > Microsoft 365 > recipient

Le trajet définitif ne traite le message qu’une fois dans chaque service :

Microsoft 365 > signature service > Microsoft 365 > Sophos > recipient

Examiner les connecteurs et règles du service de signature et de Sophos. CodeTwo ou Exclaimer doit intervenir avant le trajet sortant Sophos ; supprimer ou limiter les règles qui renvoient le message vers Sophos. Configurer la règle tierce selon les recommandations actuelles de son fournisseur. Message Trace et les en-têtes doivent prouver un seul passage dans chaque service.

Contournement limité en l’absence de boucle

S’il n’existe pas de double trajet mais qu’un grand en-tête de diagnostic dépasse encore la limite, créer dans Exchange Admin Center, Mail flow > Rules :

  • Apply this rule if: A message header > includes any of these words ; en-tête X-Sophos-Email-ID, mot True.
  • Do the following: Modify the message properties > remove a message header ; en-tête X-Microsoft-Exchange-Diagnostics-untrusted.
  • Conserver les autres valeurs par défaut. Placer la règle après les règles de préfiltrage et de redirection Sophos Email ; si leurs priorités par défaut sont 0, 1 et 2, utiliser la priorité 3.

Exporter ou documenter auparavant l’ordre des règles. Tester ensuite un message concerné et un message normal. Cette règle réduit les en-têtes, mais ne corrige pas une boucle. Supprimer des en-têtes Microsoft dans Sophos avec .* n’est également qu’un contournement temporaire ; si les en-têtes Sophos sont doublés, corriger le routage.

Comportement attendu : deux étiquettes de confidentialité

Microsoft 365 peut appliquer deux fois la même sensitivity label à un message sortant : une fois avant l’envoi à Sophos et une fois après son retour. Si Message Trace montre ce trajet sans boucle, ce doublon est attendu en mode Mailflow et ne prouve pas une seconde analyse Sophos. Ne pas modifier les connecteurs pour cette seule raison.

Validation, retour arrière et escalade

La réparation est terminée lorsque :

  • le domaine affiche Connected sous M365 Mailflow Domains et Quick Test réussit ;
  • un message entrant et un sortant concordent dans Microsoft Message Trace et Sophos Message History et sont livrés ;
  • les en-têtes montrent uniquement les passages Sophos, Microsoft et service de signature attendus ;
  • SPF réussit et les tests de transfert ou DLP donnent exactement le résultat prévu ;
  • aucune nouvelle alerte Mailflow High ou Medium n’apparaît.

Pour un retour manuel délibéré, déconnecter le domaine en cliquant sur la croix à côté de Connected dans M365 Mailflow Domains. Sophos supprime alors les applications, connecteurs et règles créés pour ce domaine, ce qui peut prendre quelques minutes. Avant de reconnecter, vérifier leur suppression sous App registrations dans Microsoft Entra Admin Center, puis Mail flow > Rules et Mail flow > Connectors dans Exchange Admin Center. Reconnecter ensuite avec un consentement valide.

Distinguer un blocage RBL Gateway antérieur à la détection Mailflow

Si un message entrant est rejeté, que les journaux Sophos Gateway indiquent un rejet RBL, mais que Sophos Message History ne contient aucun événement Mailflow correspondant, la connexion Gateway encore active a peut-être appliqué sa liste de blocage en temps réel avant que Sophos puisse détecter la connexion Mailflow et transférer le message. Corréler le même message et la même heure UTC dans les journaux Gateway, Microsoft Message Trace et Mailflow Message History. Dans ce cas, l’absence d’événement Mailflow ne prouve pas une défaillance du connecteur Mailflow.

Il ne faut ni contourner largement ni désactiver globalement une RBL. Il ne faut pas non plus prolonger le traitement parallèle : dès que Mailflow est validé en entrée et en sortie, supprimer rapidement l’ancienne connexion Gateway conformément au plan de migration.

Il s’agit d’une réparation contrôlée, pas d’un nettoyage improvisé. En production, définir d’abord une fenêtre, un trajet de remplacement et un critère d’abandon. Lors d’une migration Gateway vers Mailflow, ne conserver le trajet Gateway documenté que comme retour planifié ; Gateway et Mailflow ne doivent pas acheminer simultanément le même domaine de production via Sophos, sous peine de doubles analyses ou de boucles. Si des objets subsistent, si leur responsable est inconnu ou si Reconnect échoue malgré les autorisations, arrêter les modifications et transmettre au support Sophos le domaine, les Message-IDs, heures UTC, en-têtes, traces, résultat Quick Test et inventaire.