Événements de livraison et diagnostic

Lorsque vous devez savoir ce qui est arrivé à un message, ou pourquoi une campagne donne de mauvais résultats, la réponse commence dans le flux d’événements. Chaque message que traite un fournisseur de services de messagerie (ESP) passe par une suite d’états. Chaque changement d’état est un événement que la plateforme enregistre et peut vous transmettre en continu.

Les taux de rebonds et de plaintes, les estimations du placement en boîte de réception par fournisseur, l’analyse des retards et les scores d’engagement sont tous construits à partir de ces événements. L’Event Webhook de SendGrid sert ci-dessous d’exemple de référence, car il est entièrement spécifié. Après les événements viennent les rapports, le diagnostic des retards et le score d’engagement construits sur eux.

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 un diagnostic pas à pas, voir Procédures de dépannage de la livraison. Les deux s’appuient sur les données décrites ici.

La taxonomie des événements

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

Événements de livraison

Les distinctions qu’un opérateur doit bien connaître :

• Un report de remise n’est pas un rebond. Un report est un refus temporaire que la plateforme continue de retenter. Il ne devient un rebond que si les nouvelles tentatives sont épuisées. Des reports persistants sont le signe classique d’une limitation de débit (voir Diagnostic des retards et de la latence).
• bounce et blocked sont différents. SendGrid enregistre les deux comme un événement bounce et les distingue par le champ type. type: "bounce" est un rebond définitif, qui est permanent (par exemple, l’adresse n’existe pas). type: "blocked" est un rebond temporaire : un rejet temporaire à cause de la réputation, du contenu ou d’un problème technique. Dans les rapports 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 le jugement du serveur de réception sur vous, et non sur l’adresse, et il peut disparaître une fois corrigé le problème de réputation ou de contenu qui en est la cause. Voir Listes de blocage DNS et zones Spamhaus.
• Un abandon, c’est la plateforme qui vous protège, ou votre propre erreur. La plateforme a supprimé l’envoi avant la transmission. La plupart des abandons sont sains, car supprimer une adresse connue comme mauvaise protège la réputation. Un pic d’abandons pour des raisons inattendues (un modèle invalide, un quota dépassé) signale un défaut côté expéditeur, et non un problème chez le serveur de réception. Architecture des listes de suppression explique la portée des suppressions.
• Livré ne veut pas dire en boîte de réception. delivered est publié quand le serveur de réception répond 250 OK. Ensuite, le serveur de réception peut encore placer le message en boîte de réception, le mettre en file d’attente, le classer dans le dossier spam ou le courrier indésirable, le supprimer sans rien dire ou (chez Gmail) le ranger dans un onglet, et la plateforme d’envoi ne reçoit aucun autre signal sur tout cela. La seule preuve ultérieure est l’engagement du destinataire (ouvertures et clics). Un taux de livraison élevé avec un engagement quasi nul est le signe typique de messages classés en spam. C’est pourquoi le placement en boîte de réception ne peut être qu’estimé, par des tests sur liste de test et les tableaux de bord postmaster des fournisseurs, et jamais lu directement dans les événements 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 catégorie de cause sur laquelle un opérateur peut agir :

Les catégories Content et Reputation alimentent le score de qualité de l’engagement (voir plus bas) comme alerte précoce, car elles montrent que le serveur de réception vous juge, et non que l’adresse est mauvaise.

Événements d’engagement

Deux précautions évitent que les événements d’engagement vous induisent en erreur :

• 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 une personne. Excluez ces ouvertures de toute mesure réelle de l’engagement. Le préchargement des images de Gmail déclenche aussi des ouvertures sans personne. Voir Distorsions du suivi et de la mesure et Interactions non humaines.
• spamreport est votre signal de plainte. C’est la partie de la feedback loop du fournisseur que voit l’expéditeur. 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 donne l’action, par ordre de gravité croissante :

Pour la façon dont un opérateur d’ESP détecte et contient ces problèmes et applique l’é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 ensemble de champs communs et des champs propres à chaque événement. Ce sont les champs que vous mettez en correspondance pour répondre à la question « qu’est-il arrivé à ce message ? ».

SendGrid recommande de ne jamais placer de données personnelles dans category ou unique_args. La plateforme peut utiliser ces champs pour ses opérations internes, ils ne peuvent pas être masqués, et ils peuvent être conservés 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, puis deferred une ou plusieurs fois, puis delivered, puis open. Une autre agrège par event, bounce_classification et domaine de réception pour trouver quel fournisseur rejette quelle catégorie de messages.

Rapports de délivrabilité

Un tableau de bord de diagnostic construit à partir du flux d’événements suit le modèle « Deliverability Insights » (dans SendGrid, sous Stats, puis Deliverability Insights). Ses données ont environ 48 heures de retard sur le temps réel. Il comporte quatre vues :

Le choix de conception le plus important 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 est tenue séparément chez chaque fournisseur, donc le diagnostic et la correction doivent aussi se faire fournisseur par fournisseur (voir Surveillance de la réputation et Réglages de référence par fournisseur). SendGrid publie ces seuils pour lire cette vue :

Ces seuils concordent avec les seuils rassemblés à partir de plusieurs sources dans Indicateurs et valeurs de référence de la délivrabilité : le consensus de ≤0,1 % de plaintes et de <5 % de rebonds, et la limite de 0,3 % que Gmail et Yahoo traitent comme une violation.

Diagnostic des retards et de la latence

« Retard » peut désigner deux choses très différentes, et les confondre oriente le diagnostic dans la mauvaise direction.

1. Retard chez le serveur de réception (reports de remise et limitation de débit). Le message a quitté la plateforme, mais le serveur de réception le retient par une liste grise, une limitation de débit ou un « 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, puis transforme le message en rebond.

Des reports persistants concentrés chez un seul fournisseur signifient que vous dépassez ce que ce fournisseur accepte en débit ou en volume. Le remède est d’adapter le trafic à ce serveur de réception (réduire la concurrence ou le débit, étaler l’envoi sur davantage d’heures), et non de multiplier les tentatives. Voir Réglage de la livraison par le MTA et Liste grise (RFC 6647).

2. Retard sur la plateforme ou à l’injection (bloqué en Processing). Le message n’atteint jamais un serveur de réception ; il reste à l’état processed. SendGrid documente plusieurs causes :

• Une limite de volume sur une nouvelle adresse IP dédiée. Un plafond de volume s’applique pendant les 3 premiers jours sur une nouvelle adresse IP dédiée, pour prévenir les abus. Augmentez le volume progressivement avec le processus de chauffe d’IP.
• Une mise en attente pour conformité. Pour un compte en cours d’examen, ou sur lequel une activité inhabituelle a été détectée, l’envoi est suspendu jusqu’à confirmation par l’équipe Compliance.
• Un 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 adresse IP en service.
• La suspension d’un compte dormant. 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 d’ici là, ils deviennent des rebonds définitifs.

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

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

Diagnostiquez dans cet ordre. Vérifiez d’abord l’état event. processed indique un problème de plateforme ou de conformité ; deferred indique une limitation de débit par le serveur de réception ; delivered sans engagement indique le dossier spam, qui est un problème de placement et non de retard. N’utilisez les outils de latence de transport qu’une fois confirmé que le message quitte normalement la plateforme.

Score de qualité de l’engagement

Le niveau d’agrégation le plus élevé transforme 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, où un score plus élevé signifie un meilleur engagement et une meilleure délivrabilité. Le score permet à 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.

Un score n’est généré qu’avec le 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 du compte et de chaque sous-utilisateur.

Le score combine cinq composantes pondérées, qui sont les signaux d’é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 personnes qui veulent encore vos messages ?), de vraies ouvertures plutôt que des ouvertures par des machines chez les fournisseurs qui comptent, des rebonds permanents qui évoluent dans le mauvais sens, les rebonds de réputation et de contenu en particulier, et les plaintes. Un ESP peut utiliser ces scores pour répartir les sous-utilisateurs en pools d’adresses IP, signaler les expéditeurs peu performants à la surveillance des envois sortants, et décider quand faire passer des expéditeurs d’une infrastructure partagée à une infrastructure dédiée, ou l’inverse.

Voir aussi

• Procédures de dépannage de la livraison
• Indicateurs et valeurs de référence de la délivrabilité
• Codes d’état étendus (RFC 3463), pour lire le champ status
• Notifications d’état de livraison (RFC 3464), le format des rebonds asynchrones
• Distorsions du suivi et de la mesure, sur les raisons pour lesquelles les ouvertures et les clics induisent en erreur
• Réglage de la livraison par le MTA
• Feedback loops de plaintes (RFC 6449)
• Surveillance de la réputation