Événements de livraison et diagnostic

Chaque message que traite un ESP passe par une suite d’états, et chaque changement d’état est un événement que la plateforme enregistre et peut transmettre en continu au client. Ce flux d’événements est la télémétrie brute qui sous-tend tout diagnostic de délivrabilité : taux de rebonds et de plaintes, estimations de placement en boîte de réception par fournisseur, analyse des retards et score d’engagement sont tous des agrégations de ce flux. Cet article décrit la taxonomie des événements qu’émet un ESP ou un MTA, en prenant l’Event Webhook de SendGrid comme exemple de référence entièrement spécifié, puis présente les couches de rapports, de diagnostic des retards et de score d’engagement construites par-dessus.

Pour les seuils qu’alimentent ces événements et les mesures correctives qu’ils déclenchent, voir Indicateurs et valeurs de référence de la délivrabilité ; pour les parcours de diagnostic pas à pas, voir Procédures de dépannage de la livraison. Cet article est la couche d’instrumentation sous-jacente à ces deux articles.

La taxonomie des événements

Les événements se répartissent en trois familles : les événements de livraison (ce que le système d’envoi et les serveurs de réception ont fait du message), les événements d’engagement (ce qu’a fait le destinataire) et les événements de compte (changements de statut au niveau de la plateforme). L’Event Webhook de SendGrid les publie en JSON ; les noms sont des libellés propres à l’éditeur, mais toute infrastructure d’envoi produit des états équivalents.

Événements de livraison

Les distinctions de sens qu’un opérateur doit avoir intégrées :

• deferred ≠ bounce. Un report de remise est un refus temporaire que la plateforme continue de retenter ; il ne devient un rebond que lorsque les nouvelles tentatives sont épuisées. Des reports persistants sont la signature classique d’une limitation de débit (voir Diagnostic des retards et de la latence).
• bounce ou blocked. SendGrid code les deux sous l’événement bounce et les distingue par le champ type : type: "bounce" = rebond définitif (permanent, par exemple une adresse qui n’existe pas) ; type: "blocked" = rebond temporaire (rejet temporaire lié à la réputation, au contenu ou à un problème technique). Dans le rapport Bounces & Blocks de l’interface, un Bounce désigne une adresse email invalide (qui n’a jamais existé ou a été désactivée), tandis qu’un Block signifie que le message a été rejeté pour des « content and reputation issues or technical failures » (problèmes de contenu et de réputation ou défaillances techniques). Un blocage est un signal du récepteur sur vous, pas sur l’adresse : il peut disparaître une fois le problème de réputation ou de contenu corrigé. Voir Listes de blocage DNS et zones Spamhaus.
• dropped est auto-infligé ou protecteur. La plateforme a supprimé l’envoi avant la transmission. La plupart des abandons sont sains (supprimer une adresse connue comme mauvaise protège la réputation) ; un pic d’abandons pour des raisons inattendues (modèle invalide, quota dépassé) signale un défaut côté expéditeur, pas un problème de récepteur. La portée des suppressions est traitée dans Architecture des listes de suppression.
• delivered ≠ boîte de réception. delivered est publié sur le 250 OK du serveur de réception. À ce stade, le récepteur peut encore diriger le message vers la boîte de réception, le mettre en file d’attente, le classer en spam ou en courrier indésirable, le supprimer sans rien dire ou (Gmail) le ranger dans un onglet, et la plateforme d’envoi ne reçoit aucun autre signal sur tout cela. La seule preuve en aval est l’engagement du destinataire (ouverture, clic). Un taux de livraison élevé avec un engagement quasi nul est l’empreinte d’un classement en spam. C’est pourquoi le placement en boîte de réception ne peut être qu’estimé (tests sur liste de test, tableaux de bord postmaster des fournisseurs), jamais lu directement dans le flux de livraison. Voir Distorsions du suivi et de la mesure et Surveillance de la réputation.

Classification des rebonds

Pour les événements bounce, SendGrid ajoute un champ bounce_classification qui range l’échec SMTP dans une cause sur laquelle un opérateur peut agir :

Les catégories Content et Reputation sont celles qui alimentent le score de qualité de l’engagement (voir plus bas) comme signal d’alerte précoce, car elles indiquent que le récepteur vous juge, et non que l’adresse est mauvaise.

Événements d’engagement

Précautions sur l’engagement (essentielles pour ne pas être induit en erreur par le flux) :

• Ouvertures par des machines. SendGrid renseigne sg_machine_open: true lorsque l’ouverture a été générée par Apple Mail Privacy Protection (MPP) et non par un humain. Ces ouvertures doivent être exclues de toute mesure réelle de l’engagement. Le préchargement des images de Gmail déclenche de même des ouvertures sans humain. Voir Distorsions du suivi et de la mesure et Interactions non humaines.
• spamreport est votre signal de plainte. C’est la moitié, côté expéditeur, de la feedback loop du fournisseur ; un taux de spamreport soutenu est la donnée d’entrée la plus dommageable pour la réputation. Voir Feedback loops de plaintes.

Événements de compte

SendGrid émet account_status_change lorsque la plateforme modifie la situation d’un compte pour des raisons de conformité (phishing, taux de spam élevés, « other bad behavior »). Le champ type porte l’action, par ordre de gravité croissante :

Pour le point de vue de l’opérateur d’ESP (détection, confinement et échelle des sanctions), voir Comptes compromis, Surveillance des envois sortants et Architecture multi-tenant.

Champs de la charge utile des événements

Le JSON du webhook comporte un socle commun et des champs propres à chaque événement. C’est le vocabulaire du diagnostic : les champs que l’on met en correspondance pour répondre à la question « qu’est-il arrivé à ce message ? ».

Note opérationnelle : SendGrid recommande de ne jamais placer de données personnelles dans category / unique_args : la plateforme peut s’en servir pour ses opérations internes, elles ne peuvent pas être masquées et elles peuvent être conservées longtemps.

Une requête de diagnostic typique joint tous les événements qui partagent un même sg_message_id et les trie par timestamp pour reconstituer l’historique complet d’un message (processed → deferred×N → delivered → open), ou agrège par event + bounce_classification + domaine de réception pour trouver quel fournisseur rejette quelle catégorie de messages.

Rapports de délivrabilité

Agréger le flux d’événements dans un tableau de bord de diagnostic correspond au modèle « Deliverability Insights » (SendGrid : Stats → Deliverability Insights). Les données ont environ 48 heures de retard sur le temps réel. Le rapport présente quatre vues :

Le choix de conception décisif est la segmentation par fournisseur de messagerie. Un taux de livraison global de 95 % peut masquer un blocage total chez un fournisseur ; la réputation se joue fournisseur par fournisseur, donc le diagnostic et le rétablissement aussi (voir Surveillance de la réputation et Réglages de référence par fournisseur). Les seuils d’interprétation publiés par SendGrid pour cette vue :

Ces seuils concordent avec les seuils multisources de Indicateurs et valeurs de référence de la délivrabilité (le consensus ≤ 0,1 % de plaintes / < 5 % de rebonds, et la limite de violation de 0,3 % chez Gmail et Yahoo).

Diagnostic des retards et de la latence

« Retard » peut désigner deux choses très différentes, et les confondre égare le diagnostic :

1. Retard côté récepteur (reports de remise, limitation de débit). Le message a quitté la plateforme, mais c’est le récepteur qui le retient : liste grise, limitation de débit ou « try again later ». Cela se traduit par des événements deferred avec un compteur attempt croissant et une response 4.x.x. La plateforme réessaie selon un calendrier ; SendGrid retente les messages reportés pendant 72 heures au maximum, après quoi le message est converti en rebond. Des reports persistants concentrés chez un seul fournisseur = vous dépassez la tolérance de débit ou de volume de ce fournisseur : le remède est d’adapter le trafic au récepteur (réduire la concurrence ou le débit, étaler l’envoi sur davantage d’heures), pas de multiplier les tentatives. Voir Réglage de la livraison par le MTA et Liste grise (RFC 6647).

2. Retard côté plateforme ou à l’injection (bloqué en Processing). Le message n’atteint jamais un récepteur : il reste à l’état processed. SendGrid documente plusieurs causes :

• Restriction de volume sur une nouvelle adresse IP dédiée : un plafond de volume s’applique pendant les 3 premiers jours sur une nouvelle IP dédiée pour prévenir les abus ; montez en charge en suivant le processus de chauffe d’IP.
• Mise en attente pour conformité : l’envoi d’un compte en cours d’examen, ou sur lequel une activité inhabituelle a été détectée, est suspendu jusqu’à confirmation par l’équipe Compliance.
• Engorgement de la file d’attente du MTA : un volume d’envoi très élevé peut accumuler les messages dans la file d’attente du MTA sortant ; mettez l’envoi en pause ou mettez une autre IP en service.
• Suspension des comptes dormants : les comptes sans aucune connexion sont suspendus automatiquement.

Les messages restent en attente pendant 72 heures au maximum ; si le problème sous-jacent n’est pas résolu, ils deviennent des rebonds définitifs.

3. Latence de transport (intégration, réseau). Le message arrive lentement dans la plateforme. Les recommandations de SendGrid portent sur le débit et le chemin réseau :

• Utiliser les bibliothèques clientes officielles (C#, PHP, Ruby, Node.js, Python, Go, Java) plutôt que du code écrit à la main.
• Débit SMTP : jusqu’à 5 000 messages par connexion, jusqu’à 1 000 destinataires To: par message (via l’en-tête x-smtpapi).
• Ouvrir des connexions simultanées supplémentaires : au maximum ~10 connexions simultanées recommandées.
• Diagnostic réseau : hping / Test-NetConnection mesurent le temps de réponse et le TTL ; tout ce qui dépasse environ 150 ms de temps de réponse est un premier signal d’alerte. Le mode traceroute révèle la latence de chaque saut (surveillez les hausses brusques d’un saut à l’autre). Les analyseurs d’en-têtes (par exemple celui de Google) montrent le trajet du message de MTA en MTA et le temps passé à chaque étape ; Wireshark capture la conversation SMTP pour une inspection approfondie.

Ordre des opérations du diagnostic : vérifiez d’abord l’état event (processed → problème de plateforme ou de conformité ; deferred → limitation de débit par le récepteur ; delivered sans engagement → classement en spam, qui est un problème de placement et non de retard). Les outils de latence de transport ne s’appliquent qu’une fois confirmé que le message quitte normalement la plateforme.

Score de qualité de l’engagement

L’agrégation de plus haut niveau résume tout le flux d’événements en un seul score de santé. L’API Engagement Quality (SEQ) de SendGrid en est l’exemple de référence : elle renvoie un score de 1 à 5 (plus il est élevé, meilleurs sont l’engagement et la délivrabilité), destiné à permettre à un opérateur de classer les expéditeurs et les sous-utilisateurs à grande échelle et de repérer une dégradation avant qu’elle ne devienne un incident de réputation.

Conditions pour obtenir un score : suivi des ouvertures activé et ≥ 1 000 messages envoyés au cours des 30 derniers jours. Les scores sont conservés 90 jours au maximum. Les points de terminaison renvoient les scores au niveau du compte et par sous-utilisateur.

Le score se compose de cinq composantes pondérées ; ce sont exactement les signaux dérivés des événements décrits plus haut, condensés :

Cette conception montre ce qu’une plateforme considère réellement comme de la « qualité » : un engagement récent (écrivez-vous à des gens qui veulent encore vos messages ?), de vraies ouvertures (non générées par des machines) chez les fournisseurs qui comptent, des rebonds permanents qui évoluent dans le mauvais sens, les rebonds de réputation ou de contenu en particulier, et les plaintes. Un ESP peut utiliser ces scores de façon opérationnelle pour répartir les sous-utilisateurs en pools d’IP, signaler les expéditeurs peu performants à la surveillance des envois sortants, et conditionner le passage d’une infrastructure partagée à une infrastructure dédiée, dans un sens comme dans l’autre.

Voir aussi

• Procédures de dépannage de la livraison : les parcours de diagnostic pas à pas qui exploitent cette télémétrie
• Indicateurs et valeurs de référence de la délivrabilité : les seuils et les mesures correctives qu’alimentent ces événements
• Codes d’état étendus (RFC 3463) : lire le champ status
• Notifications d’état de livraison (RFC 3464) : le format de rebond asynchrone derrière les événements bounce
• Distorsions du suivi et de la mesure : pourquoi les ouvertures et les clics mentent (MPP, préchargement, scanners)
• Réglage de la livraison par le MTA : l’adaptation du trafic qui résout les reports persistants
• Feedback loops de plaintes (RFC 6449) : la source des événements spamreport
• Surveillance de la réputation : transformer les données d’événements par fournisseur en estimation du placement