Procédures de dépannage de la livraison

Quand un client ou un tableau de bord signale un problème de livraison, partez du symptôme et lancez le test qui distingue les causes probables. Chaque procédure ci-dessous donne ce test et indique où mène chaque résultat.

Une liste de contrôle vous dit ce qui est vrai en matière de réputation, de contenu ou d’infrastructure. Le diagnostic fonctionne autrement : vous réduisez les causes possibles un test à la fois. Les procédures sont écrites pour qu’une personne ou un agent automatisé puisse en suivre une depuis le début et s’arrêter à la première branche qui correspond.

Les procédures renvoient à des contenus plus détaillés : les catalogues de codes d’erreur de Gmail et de Yahoo et les codes d’état étendus, la pile de surveillance de la réputation, le fonctionnement interne du filtrage de Microsoft et la carte des canaux d’escalade. Quand le diagnostic révèle une atteinte systémique, le rétablissement après un incident de réputation explique la suite.

Étape 0 : le message a-t-il été accepté ?

Tout problème de livraison relève de l’une de deux catégories très 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. N’appliquez pas 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 propre MTA ou 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 par API (le modèle Postmark) : un événement Delivered signifie que le serveur distant a renvoyé 250 2.0.0 OK. Delivered signifie l’acceptation, et non le placement en boîte de réception : le message peut encore être classé en spam ou supprimé plus tard. Processed signifie que le message a été remis au MTA d’envoi et attend le verdict du serveur distant. Queued signifie que la plateforme a accepté le message mais ne l’a pas encore envoyé. Vérifiez si le compte ou le flux est en pause pour des taux de rebonds ou de plaintes élevés, et consultez la page d’état de la plateforme.
• Microsoft 365 côté destinataire : lancez un suivi des messages (message trace) dans le Centre d’administration Exchange, puis Flux de messagerie, puis Suivi des messages. L’état Delivered dans la colonne STATUS signifie que le message a été accepté. Pour tout autre état, la vue Details donne une explication « 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 s’est produit avant la livraison : l’envoi n’a jamais eu lieu. Les raisons courantes sont un flux en pause, une erreur d’API, une adresse présente dans la liste de suppression, ou un filtre ou une règle côté expéditeur. Vérifiez le code de réponse de la plateforme d’envoi elle-même avant d’incriminer le serveur de réception.

---

Procédure A : message non livré (rebond ou 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 qui distingue les causes est le texte du rejet, et non le seul code numérique. Lisez la réponse SMTP complète et le code d’état étendu (classe RFC 3463 : 5.1.x pour l’adressage, 5.7.x pour la politique ou la sécurité). Orientez selon ce que dit le texte :

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

• Gmail : Erreurs SMTP de Gmail et dépannage présente le catalogue complet des codes 421 et 550-5.7.x, avec une correction pour chacun. Les recommandations de Gmail sur la non-remise citent aussi l’envoi de plus de 500 messages par jour ou d’un message à plus de 500 destinataires (les limites des comptes Gmail personnels), un destinataire qui n’existe pas, un destinataire dont l’espace de stockage est plein, et un HELO ou EHLO mal formé.
• Microsoft : pour 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 le diagnostic à partir des en-têtes, du niveau de confiance spam (SCL) et du niveau de plainte en nombre (BCL), voir le fonctionnement interne du filtrage de Microsoft. La liste complète des codes NDR de Microsoft figure dans son guide « Email non-delivery reports in Exchange Online ».
• Yahoo : le catalogue des codes se trouve dans Codes d’erreur SMTP de Yahoo.
• Passerelles B2B et d’entreprise (Proofpoint, Mimecast, Barracuda, clients M365) : elles utilisent 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é ou 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 ou 421, ou Postmark affiche Delayed : le serveur distant a demandé d’attendre, et Postmark réessaie la plupart des domaines toutes les ~10 min pendant 12 heures au plus avant de déclarer le rebond. Le serveur de réception dit « pas maintenant », et le diagnostic porte sur le pourquoi et le pour combien de temps.

Les reports de remise ont quatre causes courantes. Elles semblent identiques au départ, et chacune appelle une réponse différente :

L’erreur critique à éviter est de répondre à un report de remise pour réputation en réessayant plus agressivement. Insister auprès d’un fournisseur qui vous reporte pour réputation transforme un blocage temporaire en blocage définitif. Pour distinguer une limitation de débit d’un blocage qui s’annonce, ralentissez. Une limitation de débit disparaît quand vous ralentissez. Un problème de réputation persiste, et le tableau de bord se dégrade.

Microsoft : host xxxx.outlook.com [x.x.x.x]: 451 4.7.550 Access denied, please try again later signifie que Microsoft a temporairement restreint l’adresse 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é acceptable. Réduisez le volume, laissez l’évaluation se faire, et n’escaladez pas immédiatement.

Les reports de remise de mots de passe à usage unique (OTP) et d’autres emails transactionnels demandent un traitement particulier. Pour l’utilisateur, un mot de passe à usage unique reporté a échoué, même si SMTP le considère toujours comme en cours d’acheminement. Si le courrier transactionnel partage un flux ou une adresse IP avec le courrier marketing, et que le volume marketing déclenche une limitation de débit, l’OTP est reporté lui aussi. C’est l’argument en faveur de la séparation des flux, avec le courrier transactionnel sur son propre sous-domaine et son propre pool. Pour le diagnostiquer, comparez les horodatages des reports d’OTP avec les heures 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 ou 250, mais le message se trouve dans le dossier spam ou le courrier indésirable, ou dans un onglet Gmail que l’expéditeur ne compte pas comme la boîte de réception. C’est le problème de placement, et c’est la demande la plus fréquente que reçoit un consultant en délivrabilité. Il n’y a aucun signal SMTP : le serveur de réception a accepté le message puis a décidé où l’acheminer. Les tests qui distinguent les causes sont les tableaux de bord, les en-têtes et les tests sur liste de test, et non les codes de réponse.

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

Le test préliminaire le plus précieux consiste à savoir si le problème touche un seul fournisseur ou tous les fournisseurs. La réponse coupe les causes possibles en deux :

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

Établissez le périmètre avec un test sur liste de test ou de placement en boîte de réception chez plusieurs fournisseurs (Litmus, Validity/Everest, GlockApps, Mailgun), en gardant ses limites à l’esprit. Les adresses de test n’ont aucun historique d’engagement avec vous, si bien qu’elles passent à côté de la personnalisation propre à chaque utilisateur et donnent des résultats plutôt pessimistes (voir les limites de la mesure du placement et les distorsions du suivi). Comparez les résultats du test avec Postmaster Tools et avec l’engagement réel chez chaque fournisseur.

C-2. Tests côté expéditeur (quand le courrier arrive en spam chez tous les fournisseurs)

Lancez-les dans l’ordre, et 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 correspond au domaine DKIM d= ou au domaine du Return-Path). Tous les grands fournisseurs signalent le courrier non authentifié comme à haut risque, et les règles de Gmail et de Yahoo pour les expéditeurs de gros volumes l’excluent. 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. C’est le signal le plus dommageable. La règle opérationnelle de Postmark est qu’un taux de plaintes supérieur à 0,1 % (1 pour 1 000) annonce une baisse de délivrabilité, et Google impose un plafond strict de 0,3 % (voir Exigences de Gmail envers les expéditeurs). Consultez les données de plaintes pour chaque fournisseur dans GPT et dans SNDS et JMRP.
3. Taux de rebonds. Un taux élevé d’adresses invalides ressemble aux pratiques de liste d’un spammeur. Le plafond opérationnel de Postmark est un taux de rebonds définitifs inférieur à 5 %, et jamais supérieur à 10 %. La cible plus stricte de Klaviyo est un taux de rebonds total inférieur à 1 %, et le taux sain de Postmark pendant la chauffe est inférieur à 2 %. L’ensemble des valeurs, avec l’attribution de chaque chiffre, figure dans le tableau de référence des seuils. Des rebonds élevés orientent vers un problème de qualité de la liste qui abîme la réputation.
4. Contenu. Passez le message exact dans un outil de vérification fondé sur SpamAssassin (la cible de Postmark Spam Check est un score inférieur à 5, et un score négatif est meilleur) et dans mail-tester. Les déclencheurs courants sont les raccourcisseurs d’URL (bit.ly) au lieu de liens à votre marque, les messages composés uniquement d’images ou avec des images trop lourdes, un HTML cassé ou incomplet, des domaines de liens et d’images qui ne correspondent pas au domaine From, et un lien de désabonnement absent ou cassé. Si un changement de modèle a précédé la baisse, revenez en arrière pas à pas, en retirant un élément à la fois, pour isoler le déclencheur. Voir contenu et design.
5. Réputation. Vérifiez la réputation du domaine et des adresses IP dans les tableaux de bord des fournisseurs et par des interrogations DNSBL. Une mauvaise note ici signifie que la cause est un historique accumulé, et non ce seul message. Voir rétablissement après incident.

C-3. Branches de placement pour chaque fournisseur (quand le courrier arrive en spam chez un seul fournisseur)

C-4. Microsoft : la procédure pour le courrier arrivé dans le courrier indésirable

Microsoft documente cette démarche pour un faux positif :

1. Confirmez que le message a été livré (dans le suivi des messages, STATUS = Delivered, et non bloqué).
2. Faites signaler le message à Microsoft par le destinataire comme faux positif, pour analyse.
3. Vérifiez que l’expéditeur n’annonce pas d’adresse IP non routable et n’échoue pas au DNS inverse.
4. Vérifiez que le nom d’expéditeur et l’objet sont transparents et que les domaines de redirection sont cohérents : tous les liens mènent à un seul domaine, et non à un ensemble dispersé comme unsubscribe.bulkmailer.com, profile.excite.com et options.yahoo.com.
5. Pour un problème de réputation systémique, passez 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 trouve le message 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. Les causes possibles, de la plus probable à la moins probable :

1. Le message est dans le dossier spam ou le courrier indésirable, et le destinataire n’y a pas regardé. C’est l’explication la plus fréquente. Faites chercher le destinataire dans tous les dossiers, y compris les onglets Gmail (Promotions, Notifications, Réseaux sociaux), les vues Prioritaire et Autres d’Outlook, et le courrier indésirable. Puis suivez la procédure C.
2. Le message a été filtré ou supprimé après acceptation. Le fournisseur l’a accepté puis l’a écarté par un filtrage de réputation agressif. Le tableau de bord du fournisseur et, chez Microsoft, un suivi des messages révèlent un verdict de filtrage postérieur à l’acceptation. C’est un problème de réputation : voir la procédure C-3 et le rétablissement après incident.
3. Une règle ou un transfert côté destinataire. Une règle de boîte de réception a déplacé ou supprimé le message, ou un transfert défaillant l’a perdu. Le premier geste de tri de Microsoft consiste à faire vérifier par l’utilisateur Outlook sur le web. Si le message s’y trouve mais pas dans l’application de bureau ou mobile, le problème vient de l’application ou d’une règle locale, et non de la livraison. Pour les problèmes Outlook qui ne touchent qu’un utilisateur, lancez l’Assistant Support et récupération de Microsoft (Support and Recovery Assistant).
4. Une livraison à la mauvaise adresse. Un alias ou une faute de frappe correspondait par hasard à une boîte valide. Confirmez l’adresse exacte du destinataire dans vos journaux.
5. Un incident de service. Avant une enquête approfondie, vérifiez l’état de santé du service du fournisseur (Centre d’administration Microsoft 365, puis Service health, ou la page d’état du fournisseur). Un service de réception dégradé retarde ou achemine mal le courrier dans toute l’organisation, et aucune correction n’est nécessaire côté expéditeur.

Un seul utilisateur ou plusieurs est la question clé de la procédure D. Si un seul destinataire n’a pas reçu un message, la cause est l’application de messagerie, une règle ou l’adresse (utilisez les outils ci-dessus). Si plusieurs destinataires chez un même fournisseur n’ont pas reçu de messages, la cause est la réputation ou le filtrage (procédure C). Si plusieurs destinataires chez tous les fournisseurs n’ont pas reçu de messages, la cause est l’authentification ou un incident côté envoi.

---

Bibliothèque de scénarios (exemples détaillés)

Des tickets concrets et la branche que chacun emprunte :

---

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

Avant d’ouvrir un canal auprès d’un fournisseur, suivez les procédures jusqu’à obtenir une hypothèse précise étayée par des preuves. Le support des fournisseurs ferme les tickets qui arrivent sans diagnostic. Apportez 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 ou SNDS, la date de début du problème, et ce que vous avez modifié autour de cette date.

Canaux d’escalade et de levée des restrictions et Canaux d’escalade de Microsoft recensent les canaux : le formulaire d’escalade de Google pour les expéditeurs de gros volumes et sa condition d’éligibilité (0,3 % sur 7 jours), le portail de retrait de liste de Microsoft (sender.office.com), distinct du support aux expéditeurs, le support aux expéditeurs de Yahoo, et l’adresse icloudadmin@ d’Apple. Chaque canal ne règle qu’une partie des problèmes. Les portails de retrait de liste lèvent les blocages d’IP. Ils ne règlent pas les problèmes de contenu ou de plaintes, qui ne se corrigent qu’une fois le comportement de l’expéditeur modifié.

Voir aussi

• Surveillance et remédiation de la réputation, y compris la procédure de retrait de liste
• Rétablissement après un incident de réputation
• Pratiques d’infrastructure d’envoi, sur le cadre en 5 volets de Postmark : authentification, contenu, engagement, réputation et infrastructure
• Réglage de la livraison par le MTA
• Valeurs de référence par fournisseur
• Erreurs SMTP de Gmail et dépannage
• Fonctionnement interne du filtrage de Microsoft
• Codes d’erreur SMTP de Yahoo
• Canaux d’escalade et de levée des restrictions
• Codes d’état étendus
• Notifications d’état de livraison