Sophos Phish Threat : résoudre les erreurs de livraison et les rejets
Si des utilisateurs ne reçoivent pas un e-mail Sophos Phish Threat, plusieurs causes sont possibles : la campagne n’a pas encore atteint le destinataire, l’adresse cible n’est pas valide, une passerelle limite le débit d’envoi, ou une fonction de sécurité bloque ou met la simulation en quarantaine. Le diagnostic commence donc dans Sophos Fusion (anciennement Sophos Central), puis suit le chemin de livraison réellement utilisé.
Important : les utilisateurs répertoriés sur la page Bounced Mailboxes ne reçoivent aucun e-mail des campagnes futures tant que la cause n’a pas été corrigée et qu’ils n’ont pas été retirés de la liste. Leur retrait n’est donc pas la première étape du diagnostic ; il ne doit intervenir qu’après la résolution du problème.
Diagnostic rapide
| Observation | À vérifier en premier | Ensuite |
|---|---|---|
| La campagne vient de démarrer | prévoir au moins une heure avant l’envoi et vérifier le calendrier d’envoi | vérifier à nouveau la progression de la campagne |
| Seuls certains utilisateurs ont reçu un e-mail | envoi par intervalles, liste des destinataires et boîtes aux lettres actives | vérifier Bounced Mailboxes et la synchronisation des annuaires |
| Central affiche Bounced ou Not Sent | détails de l’erreur sous Bounced Mailboxes | examiner l’adresse, les erreurs DNS/SMTP et le flux de messagerie |
| Central affiche Delivered, mais l’e-mail n’est pas visible | Message Trace, journaux de la passerelle, quarantaine et dossier Courrier indésirable | déterminer la règle de filtrage déclenchée |
| De nombreux e-mails échouent lorsque le volume est élevé | limitation du débit ou throttling | échelonner l’envoi sur plusieurs heures ou jours |
| Direct Delivery est configuré pour le domaine | configuration de Direct Delivery | poursuivre le diagnostic dans le runbook correspondant |
1. Consigner un cas reproductible
Avant toute modification, consignez les informations suivantes :
- nom de la campagne
- heure de début prévue et réelle, avec le fuseau horaire
- un à trois destinataires concernés et un destinataire fonctionnel à titre de comparaison
- domaine d’envoi utilisé
- état de livraison de l’utilisateur concerné
- heure de la tentative d’envoi
- texte intégral de l’erreur, code DNS et erreur SMTP, s’ils sont affichés
- dernières modifications apportées à la campagne, à la liste des destinataires, à la synchronisation des annuaires ou aux filtres de messagerie
Ne lancez pas immédiatement une autre campagne de grande ampleur. Des envois complets répétés compliquent la corrélation et peuvent déclencher à nouveau des limites de débit ou des règles de sécurité.
2. Vérifier le calendrier et la progression de la campagne
Sous Phish Threat > Campaigns, ouvrez la campagne concernée. Vérifiez qu’elle est active et en cours de traitement, ainsi que l’état de livraison affiché par Central pour les utilisateurs concernés.
Après le démarrage d’une campagne, au moins une heure s’écoule avant l’envoi des e-mails. Une campagne peut également envoyer les e-mails de manière échelonnée : de la livraison immédiate à des lots représentant seulement 5 % des destinataires. Si seule une partie du groupe cible a reçu l’e-mail, vérifiez d’abord le calendrier configuré et les intervalles d’envoi encore en attente.
Pour modifier le calendrier ou suspendre une campagne en cours, suivez la procédure Gérer les campagnes Sophos Phish Threat. Ne modifiez pas une campagne active sans documenter les conséquences sur les e-mails encore en attente.
3. Analyser Bounced Mailboxes
Ouvrez l’icône Global Settings, puis accédez à Products and Services > Sophos Phish Threat > Bounced Mailboxes. Pour les livraisons ayant échoué, cette page contient l’Email ID, le nom de la campagne et les détails de l’erreur, tels que le code DNS et l’erreur SMTP.
Vous pouvez filtrer la liste selon les informations suivantes :
- nom d’utilisateur
- adresse e-mail
- nom de la campagne
- type de rejet
Commencez par l’adresse e-mail concernée et le nom de la campagne. Consignez le texte et l’heure de l’erreur sans les modifier. L’Email ID est un champ de Sophos Fusion et ne doit pas être assimilé à un Message-ID RFC, à un identifiant de journal de passerelle ou à un identifiant de trace sans preuve de cette correspondance.
L’entrée indique que la livraison a échoué, mais pas encore quel système en est à l’origine. Ne retirez les utilisateurs de Bounced Mailboxes qu’une fois les vérifications suivantes terminées et la cause corrigée.
4. Vérifier les destinataires et la synchronisation des annuaires
Pour chaque utilisateur concerné, vérifiez les points suivants :
- L’adresse e-mail est-elle correctement orthographiée et complète ?
- La boîte aux lettres existe-t-elle, est-elle active et peut-elle recevoir des messages normaux ?
- Les adresses incorrectes proviennent-elles d’une importation CSV manuelle ?
- L’adresse principale actuelle a-t-elle été synchronisée avec Sophos Fusion ?
- La synchronisation des annuaires utilisée s’exécute-t-elle sans erreur ?
Corrigez d’abord les adresses cibles incorrectes ou obsolètes dans leur source, puis confirmez la réussite de la synchronisation. Le simple retrait d’un utilisateur de Bounced Mailboxes ne corrige ni une adresse non valide ni une boîte aux lettres désactivée.
5. Déterminer le chemin de livraison
Avant de rechercher des journaux, déterminez si le domaine concerné utilise Direct Delivery ou le flux de messagerie normal.
Si Direct Delivery est configuré, poursuivez avec Configurer et vérifier Sophos Phish Threat Direct Delivery. Les vérifications de l’API, des autorisations et du fournisseur relèvent de cette procédure et non d’une analyse SMTP.
Pour une livraison par le flux de messagerie normal, vérifiez les journaux de tous les systèmes réellement impliqués. Pour Microsoft 365, Livraison Sophos Phish Threat dans Microsoft 365 décrit les étapes propres au fournisseur ; pour Google Workspace, consultez Livraison Sophos Phish Threat dans Google Workspace.
6. Examiner Message Trace et les journaux de la passerelle
Effectuez une recherche dans le Log Viewer ou le Message Trace de la passerelle de messagerie locale en utilisant une plage horaire restreinte. Selon l’environnement, il peut s’agir des journaux de messagerie de Sophos Firewall, de Message Trace dans l’Exchange Admin Center ou des journaux d’un filtre antispam en amont.
Limitez la recherche aux attributs suivants :
- adresse exacte du destinataire
- heure de la tentative d’envoi
- adresses IP d’envoi régionales Sophos Phish Threat documentées
- domaine d’envoi utilisé dans la campagne
Ne reprenez pas les adresses IP d’envoi et les domaines d’anciens tickets. Les valeurs actuelles figurent sous Phish Threat > Settings > Sending domains and IPs.
Pour le dernier saut confirmé, consignez les éléments suivants :
- La passerelle a-t-elle refusé la connexion ?
- L’e-mail a-t-il été bloqué ou mis en quarantaine en raison d’une détection de spam ou de phishing ?
- A-t-il été rejeté en raison de l’alignement SPF, DKIM ou DMARC ?
- Une limitation du débit ou un throttling a-t-il été appliqué ?
- L’e-mail a-t-il été accepté et transféré au saut suivant ?
Consignez l’erreur SMTP complète, l’hôte ayant répondu et l’horodatage. Si l’état est Delivered, vérifiez également la quarantaine, le dossier Courrier indésirable et les règles en aval.
En l’absence d’entrée de journal, vérifiez d’abord la plage horaire, le fuseau horaire, le destinataire, l’adresse IP ou le domaine d’envoi et le chemin de livraison sélectionné. Ce n’est qu’ensuite que vous pouvez conclure qu’aucune tentative de livraison n’a eu lieu.
7. Corriger précisément la cause
Limitation du débit ou throttling
Utilisez la fonction d’envoi par lots pour répartir l’envoi sur plusieurs heures ou jours au lieu d’envoyer tous les e-mails simultanément. Vérifiez ensuite, avec un petit groupe cible autorisé, que la passerelle accepte le nouveau débit.
Un filtre bloque ou met la simulation en quarantaine
Ne créez pas d’exception globale improvisée. Configurez les adresses IP régionales Sophos requises, les domaines d’envoi et les contrôles concernés conformément à Autoriser de manière contrôlée les expéditeurs Sophos Phish Threat.
Pour chaque modification de diagnostic temporaire, consignez :
- configuration initiale
- personne responsable et autorisation
- périmètre strictement limité
- heure de début et d’expiration
- étape de restauration
- résultat du test de livraison et du test de régression après restauration
Les exceptions permanentes pour les simulations nécessitent également un périmètre documenté, un responsable et une révision régulière. Ne les étendez pas à des réseaux ou expéditeurs Sophos arbitraires, ni à l’ensemble des contrôles de sécurité.
Destinataires non valides ou erreurs de synchronisation
Corrigez l’adresse ou la boîte aux lettres dans la source de référence, laissez la synchronisation se terminer sans erreur, puis seulement après effectuez un nouveau test.
8. Supprimer l’entrée de Bounced Mailboxes et effectuer un test limité
Après la correction technique, procédez dans l’ordre suivant :
- Documentez la cause et la correction.
- Confirmez que l’adresse, la boîte aux lettres et le chemin de livraison utilisé fonctionnent désormais.
- Retirez l’utilisateur concerné de Bounced Mailboxes.
- Utilisez une petite campagne de test autorisée ou le prochain envoi de campagne contrôlé.
- Vérifiez l’état de livraison sous Phish Threat > Campaigns.
- Pour le flux de messagerie normal, confirmez l’acceptation et le transfert dans les journaux des systèmes impliqués.
- Vérifiez que l’e-mail apparaît dans la boîte aux lettres prévue ou dans la quarantaine attendue.
N’incluez d’autres destinataires qu’après la réussite du test. Si le test échoue à nouveau, analysez la nouvelle entrée sous Bounced Mailboxes et les journaux de passerelle correspondants au lieu de retirer l’utilisateur à plusieurs reprises.
Éléments de preuve pour l’escalade
Si le problème reste reproductible après la correction, fournissez les informations suivantes par le canal d’assistance sécurisé :
- identifiant du tenant Central ou du compte
- nom de la campagne
- adresse du destinataire concerné, masquée si possible conformément aux exigences de protection des données
- état et heure de livraison, avec le fuseau horaire
- Email ID provenant de Bounced Mailboxes
- code DNS et erreur SMTP complets
- chemin de livraison utilisé
- pour le flux de messagerie normal : code SMTP, hôte ayant répondu, dernier saut confirmé et éventuel identifiant Message Trace ou de passerelle
- correction effectuée et résultat du test limité
Les mots de passe, jetons, liens de campagne et exportations complètes d’utilisateurs ne doivent pas figurer dans ces éléments de preuve. Les en-têtes et journaux peuvent contenir des noms d’hôte internes, des adresses IP, des adresses e-mail et des valeurs de suivi ; ils ne doivent pas être copiés dans des tickets ou forums publics.