Procédures de dépannage de la livraison

Les autres articles de la catégorie Opérations sont des listes de contrôle de référence : des listes ordonnées de ce qui est vrai en matière de réputation, de contenu ou d’infrastructure. Cet article est la couche de procédure de décision : face au symptôme que signale un client ou un tableau de bord, quel test discriminant lancer ensuite, et où mène chaque branche. Il se justifie ainsi : le travail quotidien d’un analyste de la délivrabilité n’est pas de « dérouler une liste de contrôle », mais de « réduire l’espace des hypothèses un test à la fois ». Chaque procédure est écrite pour qu’un agent puisse la parcourir de haut en bas et s’arrêter à la première branche qui correspond.

Pour la matière première vers laquelle ces procédures renvoient, voir : les catalogues de codes d’erreur (Erreurs SMTP de Gmail et dépannage, Yahoo, codes d’état étendus) ; la pile de surveillance de la réputation ; le fonctionnement interne du filtrage de Microsoft ; la carte des canaux d’escalade ; et le rétablissement après un incident de réputation pour la suite à donner après le diagnostic lorsque la cause est systémique.

Étape 0 — La question qui oriente tout : le message a-t-il été accepté ?

Tout problème de livraison relève de l’une de deux catégories fondamentalement différentes, et la première tâche consiste toujours à établir laquelle. N’appliquez pas une procédure de placement en spam à un message qui n’a jamais reçu de 250, ni une procédure de rebond à un message qui a été accepté puis classé en courrier indésirable.

Comment établir l’acceptation :

• Dans les journaux de votre MTA ou de votre ESP : lisez la dernière réponse SMTP pour ce destinataire. Un 250 signifie que le serveur de réception a pris la responsabilité du message ; toute autre réponse signifie que ce n’est pas le cas.
• Expéditeurs via API (modèle Postmark) : un événement Delivered = le serveur distant a renvoyé 250 2.0.0 OK. Delivered signifie acceptation, pas placement en boîte de réception — le message peut encore être classé en spam ou supprimé en aval. Processed = remis au MTA d’envoi, en attente du verdict du serveur distant. Queued = accepté par la plateforme mais pas encore envoyé (vérifiez si le compte ou le flux est en pause pour des taux de rebonds ou de plaintes élevés, ou consultez la page d’état de la plateforme).
• Côté destinataire Microsoft 365 : lancez un suivi des messages (message trace) : Centre d’administration Exchange → Flux de messagerie → Suivi des messages (Exchange admin center → Mail flow → Message trace). L’état Remis (Delivered) dans la colonne ÉTAT (STATUS) = accepté ; pour tout autre état, la vue des détails (Details) explique comment résoudre le problème (How to fix it). Les données de suivi apparaissent de 10 min à 1 h après l’envoi ; les suivis de plus de 7 jours ne sont disponibles qu’en CSV et peuvent mettre jusqu’à une heure à être générés.

Si vous ne trouvez pas du tout le message dans vos journaux, le problème se situe en amont de la livraison : l’envoi n’a jamais eu lieu (flux en pause, erreur d’API, adresse présente dans la liste de suppression, filtre ou règle côté expéditeur). Vérifiez le code de réponse de la plateforme d’envoi avant d’incriminer le serveur de réception.

---

Procédure A — Message non livré (rebond / rejet, 5xx)

Symptôme : les journaux de l’expéditeur montrent un échec permanent, ou l’expéditeur a reçu un NDR. Le serveur de réception a refusé le message purement et simplement.

Le signal discriminant est le texte du rejet, pas le seul code numérique — lisez la réponse SMTP complète et le code d’état étendu (classe RFC 3463 : 5.1.x adressage, 5.7.x politique/sécurité). Orientez selon ce que dit le texte :

Branches 5xx propres à chaque fournisseur (les rejets pour réputation ou contenu qui sortent du tableau ci-dessus) :

• Gmail — le catalogue complet des codes 421/550-5.7.x, avec la correction de chacun, se trouve dans Erreurs SMTP de Gmail et dépannage. Les recommandations de Gmail sur la non-remise signalent aussi : l’envoi de plus de 500 messages par jour ou d’un message à plus de 500 destinataires (limites des comptes Gmail personnels), un destinataire inexistant, un destinataire dont l’espace de stockage est plein, un HELO/EHLO mal formé.
• Microsoft — 550 5.7.606-649 Access denied, banned sending IP [x.x.x.x] → utilisez le portail de retrait de liste sur sender.office.com (canaux d’escalade de Microsoft). Pour la couche de diagnostic des en-têtes, du SCL et du BCL, voir fonctionnement interne du filtrage de Microsoft ; la liste complète des codes NDR est la page de Microsoft « Email non-delivery reports in Exchange Online ».
• Yahoo — catalogue des codes dans Codes d’erreur SMTP de Yahoo.
• Passerelles B2B / d’entreprise (Proofpoint, Mimecast, Barracuda, locataires M365) — des systèmes de réputation et des portails de retrait de liste entièrement différents ; voir délivrabilité vers les passerelles B2B.

---

Procédure B — Message retardé / reporté (4xx, « Delayed », bloqué en file d’attente)

Symptôme : le message n’est pas encore livré mais n’a pas échoué définitivement — la file d’attente de l’expéditeur affiche 4xx/421, ou Postmark affiche Delayed (le serveur distant a demandé d’attendre ; Postmark réessaie environ toutes les 10 minutes pendant 12 heures au plus pour la plupart des domaines, avant de déclarer un rebond). C’est le serveur de réception qui dit « pas maintenant », et tout le diagnostic porte sur le pourquoi et le pour combien de temps.

Les reports de remise ont quatre causes courantes, qui semblent identiques au départ mais appellent des réponses différentes :

L’erreur à ne pas commettre : répondre à un report de remise pour réputation en rendant les nouvelles tentatives plus agressives. Insister auprès d’un fournisseur qui vous reporte pour cause de réputation transforme un blocage temporaire en blocage définitif. Le test qui distingue la limitation de débit du pré-blocage consiste à voir si le report disparaît quand vous ralentissez (limitation de débit) ou persiste pendant que le tableau de bord se dégrade (réputation).

Propre à Microsoft : host xxxx.outlook.com [x.x.x.x]: 451 4.7.550 Access denied, please try again later = Microsoft a restreint temporairement l’IP parce qu’il a détecté une activité suspecte et qu’il l’évalue. La restriction est levée automatiquement une fois le trafic jugé correct — réduisez le volume et laissez l’évaluation se faire ; n’escaladez pas immédiatement.

Les reports de remise d’OTP et d’emails transactionnels méritent un traitement particulier : pour l’utilisateur, un mot de passe à usage unique (OTP) reporté est un OTP raté, même si SMTP le considère comme en cours d’acheminement. Si les emails transactionnels partagent un flux ou une IP avec le marketing et que le volume marketing déclenche une limitation de débit, l’OTP hérite du report — c’est l’argument en faveur de la séparation des flux (le transactionnel sur son propre sous-domaine ou son propre pool), et on le diagnostique en rapprochant les horodatages des reports d’OTP des pics d’envoi marketing.

---

Procédure C — Accepté, mais arrivé dans le dossier spam ou le courrier indésirable

Symptôme : les journaux indiquent Delivered / 250, mais le message se trouve dans le dossier spam ou le courrier indésirable (ou dans un onglet Gmail que l’expéditeur considère comme « pas la boîte de réception »). C’est le problème de placement, et c’est de loin la demande la plus fréquente adressée à un consultant. Il n’y a ici aucun signal SMTP — le serveur de réception a accepté le message puis a pris une décision d’acheminement après acceptation —, si bien que les tests discriminants sont les tableaux de bord, les en-têtes et les tests sur liste de test, pas les codes de réponse.

C-1. Délimiter d’abord l’échec

Le test préliminaire le plus précieux est de savoir si le problème touche un seul fournisseur ou tous : il coupe en deux tout l’espace des hypothèses.

• Tous les fournisseurs → cause côté expéditeur. Un problème d’authentification, de contenu, de liste ou de réputation que tous les filtres voient. Commencez par l’authentification et le contenu.
• Un seul fournisseur → réputation ou filtre de ce fournisseur. Passez à la branche du fournisseur (C-3). Un message placé en boîte de réception chez Yahoo mais classé en spam chez Gmail n’a pas un problème de contenu ; c’est un problème de réputation ou de personnalisation propre à Gmail.

Établissez le périmètre par un test de placement en boîte de réception sur liste de test chez plusieurs fournisseurs (Litmus, Validity/Everest, GlockApps, Mailgun) — mais tenez compte de ses limites : les adresses de test n’ont aucun historique d’engagement avec vous, elles passent donc à côté de la personnalisation par utilisateur et donnent des résultats plutôt pessimistes (voir l’honnêteté de la mesure du placement et les distorsions du suivi). Recoupez les résultats du test sur liste de test avec Postmaster Tools et avec l’engagement réel par fournisseur.

C-2. Échelle de tests côté expéditeur (quand le message est en spam chez tous les fournisseurs)

Dans l’ordre — arrêtez-vous dès qu’un test révèle la cause :

1. Authentification — examinez les en-têtes d’un message arrivé en courrier indésirable. Authentication-Results: doit afficher spf=pass dkim=pass et l’alignement DMARC (le domaine From correspondant au domaine DKIM d= ou au domaine Return-Path). Les messages non authentifiés sont signalés comme à haut risque par tous les grands fournisseurs et sont éliminatoires au regard des règles de Gmail et de Yahoo pour les expéditeurs de gros volumes. Vérifiez que SPF respecte la limite de 10 requêtes DNS, que DKIM est vérifié et qu’un Return-Path personnalisé est en place pour l’alignement. Voir DMARC.
2. Taux de plaintes — le signal le plus dommageable. Le seuil opérationnel de Postmark : un taux de plaintes supérieur à 0,1 % (1 pour 1 000) annonce une baisse de délivrabilité ; Google impose un plafond strict de 0,3 % (voir Exigences de Gmail envers les expéditeurs). Consultez les données de plaintes par fournisseur dans GPT / SNDS-JMRP.
3. Taux de rebonds — des taux élevés d’adresses invalides trahissent des pratiques de liste dignes d’un spammeur. Le plafond opérationnel de Postmark est de moins de 5 % de rebonds définitifs (ne jamais dépasser 10 %) ; la cible plus stricte de Klaviyo est de moins de 1 % de rebonds au total, et le seuil de Postmark pour une chauffe d’IP saine est de moins de 2 % — l’ensemble des valeurs, avec leurs sources, figure dans le tableau de référence des seuils. Rebonds élevés → problème de qualité de la liste qui pèse sur la réputation.
4. Contenu — passez le message exact dans un outil de vérification basé sur SpamAssassin (Postmark Spam Check : score cible inférieur à 5, négatif c’est mieux) et dans mail-tester. Déclencheurs courants : raccourcisseurs d’URL (bit.ly) au lieu de liens à votre marque ; messages composés uniquement d’images ou images trop lourdes ; HTML cassé ou incomplet ; domaines de liens et d’images qui ne correspondent pas au domaine From ; lien de désabonnement absent ou cassé. Si une modification du modèle a précédé la baisse, revenez en arrière progressivement (en retirant un élément à la fois) pour isoler le déclencheur. Voir contenu et design.
5. Réputation — vérifiez la réputation des domaines et des adresses IP dans les tableaux de bord des fournisseurs et par des interrogations DNSBL. Une note dégradée ici signifie que la cause est un historique accumulé, et non ce seul message → rétablissement après incident.

C-3. Branches de placement propres à chaque fournisseur (quand le message est en spam chez un seul fournisseur)

C-4. Microsoft « arrivé dans le courrier indésirable » — la procédure spécifique

La démarche documentée par Microsoft pour un faux positif : (1) confirmer que le message a été livré (dans le suivi des messages, ÉTAT = Remis (Delivered), et non bloqué) ; (2) faire signaler le message à Microsoft par le destinataire comme faux positif, pour analyse ; (3) vérifier que l’expéditeur n’annonce pas d’IP non routable et ne connaît pas d’échec de DNS inverse ; (4) vérifier la transparence du nom d’expéditeur et de l’objet, et la cohérence des domaines de redirection (tous les liens vers un seul domaine, et non éparpillés entre unsubscribe.bulkmailer.com / profile.excite.com / options.yahoo.com) ; (5) pour un problème de réputation systémique, passer par SNDS et le support aux expéditeurs.

---

Procédure D — Message « introuvable » (accepté, ni en boîte de réception ni en spam)

Symptôme : les journaux indiquent Delivered, mais le destinataire ne le trouve nulle part — ni dans la boîte de réception, ni dans le dossier spam. C’est le cas le plus difficile à diagnostiquer, parce que le serveur de réception a signalé un succès. Hypothèses, par ordre de probabilité :

1. Il est dans le dossier spam ou le courrier indésirable, et le destinataire n’a pas regardé — l’explication la plus fréquente d’un message « introuvable ». Faites chercher le destinataire dans tous les dossiers (y compris les onglets Gmail Promotions, Notifications et Réseaux sociaux, la boîte Prioritaire et l’onglet Autres d’Outlook, le courrier indésirable). Puis suivez la procédure C.
2. Filtré ou supprimé silencieusement après acceptation — le fournisseur a accepté puis écarté le message (filtrage de réputation agressif). Le tableau de bord du fournisseur et un suivi des messages (Microsoft) révèlent un verdict de filtrage postérieur à l’acceptation. C’est un problème de réputation → procédure C-3 / rétablissement après incident.
3. Règle côté client / transfert — une règle de boîte de réception de l’utilisateur a déplacé ou supprimé le message, ou un transfert défaillant l’a perdu. Premier geste de tri recommandé par Microsoft : faire vérifier à l’utilisateur Outlook sur le web — si le message s’y trouve mais pas dans son client de bureau ou mobile, le problème vient du client ou de l’application, ou d’une règle locale, pas de la livraison. Lancez l’Assistant Support et récupération de Microsoft (Support and Recovery Assistant) pour les problèmes Outlook qui ne touchent qu’un utilisateur.
4. Livré à la mauvaise adresse — un alias ou une faute de frappe qui correspond par hasard à une boîte valide. Confirmez l’adresse exacte du destinataire dans vos journaux.
5. Incident de service — avant une enquête approfondie, vérifiez l’état de santé du service du fournisseur (Centre d’administration Microsoft 365 → Intégrité du service (Service health) ; pages d’état des fournisseurs). Un service de réception dégradé retarde ou achemine mal les messages dans toute l’organisation, et ne demande aucune correction côté expéditeur.

Un seul utilisateur ou plusieurs est la bifurcation clé de la procédure D : un seul destinataire sans message = problème de client, de règle ou d’adresse (outils ci-dessus). Plusieurs destinataires sans message chez un même fournisseur = réputation ou filtrage (procédure C). Plusieurs chez tous les fournisseurs = authentification ou incident côté envoi.

---

Bibliothèque de scénarios (procédures composées)

Des tickets concrets et la branche que chacun emprunte :

---

Escalader auprès du fournisseur (quand le libre-service est épuisé)

Menez les procédures jusqu’à une hypothèse précise et étayée avant d’ouvrir un canal auprès d’un fournisseur : le support des fournisseurs ferme les tickets qui arrivent sans diagnostic. Apportez : l’IP ou les adresses IP et le domaine d’envoi, le texte exact du rejet SMTP ou du NDR, des exemples d’en-têtes (Authentication-Results, X-Forefront-Antispam-Report), des captures d’écran des tableaux de bord (GPT/SNDS), la date de début du problème et ce que vous avez modifié à ce moment-là. La carte des canaux — formulaire d’escalade de Google pour les expéditeurs de gros volumes et sa condition d’éligibilité de 0,3 % sur 7 jours, portail de retrait de liste de Microsoft (sender.office.com) ou support aux expéditeurs, support aux expéditeurs de Yahoo, icloudadmin@ d’Apple — se trouve dans Canaux d’escalade et de levée des restrictions et Canaux d’escalade de Microsoft. Chaque canal ne règle qu’une partie des problèmes : les portails de retrait de liste lèvent les blocages d’IP, pas les problèmes de contenu ou de plaintes, qui ne se corrigent d’eux-mêmes qu’une fois les pratiques de l’expéditeur modifiées.

Voir aussi

• Surveillance et remédiation de la réputation — la pile de surveillance continue qu’interrogent ces procédures, et la procédure de retrait de liste.
• Rétablissement après un incident de réputation — le guide d’intervention lorsque le diagnostic conclut à une atteinte systémique à la réputation.
• Pratiques d’infrastructure d’envoi — le cadre en 5 volets de Postmark (authentification/contenu/engagement/réputation/infrastructure) vers lequel mènent ces arbres de symptômes.
• Réglage de la livraison du MTA et Valeurs de référence par fournisseur — la mise en forme du trafic et l’espacement des tentatives en réponse aux reports de remise de la procédure B.
• Erreurs SMTP de Gmail et dépannage · Fonctionnement interne du filtrage de Microsoft · Codes d’erreur SMTP de Yahoo — les catalogues de codes et d’en-têtes par fournisseur.
• Canaux d’escalade et de levée des restrictions — où va ensuite un problème diagnostiqué côté fournisseur.
• Codes d’état étendus · Notifications d’état de livraison — pour décoder le texte de rebond ou de NDR que lit la procédure A.