Un courriel n'est pas arrivé : comment trouver pourquoi

« Le client dit qu'il n'a rien reçu. » C'est le message de soutien le plus fréquent, et la réponse est rarement « Duva ne l'a pas envoyé ». Le plus souvent, le courriel a été envoyé, puis il a été refusé, retardé ou classé ailleurs par le serveur du destinataire. Cet article vous apprend à retrouver ce qui s'est passé, et à ne pas confondre les trois cas.

Avant tout, un principe : un service d'envoi accepte votre courriel, puis le transmet au serveur du destinataire. C'est ce serveur qui l'accepte, le classe ou le refuse. Aucun service ne contrôle la boîte de réception, le filtre antipourriel ni les délais, et aucun ne peut promettre qu'un courriel arrivera. Ce qu'on peut faire, c'est lire ce que le serveur du destinataire a répondu.

Étape 1 : retrouver le message

Chaque envoi par l'API renvoie un identifiant (msg_...). Gardez-le dans votre base, à côté de la commande ou de l'utilisateur concerné : c'est la façon la plus rapide de répondre à une plainte. Vous pouvez aussi ajouter des métadonnées à l'envoi (un numéro de commande, par exemple), qui reviennent dans les événements et les webhooks.

Sans identifiant, cherchez le message par destinataire dans le tableau de bord, ou lisez le journal des événements du domaine.

Étape 2 : lire le statut du destinataire

GET /v1/{domaine}/messages/{id} donne le statut du message et de chacun de ses destinataires. Un message est envoyé en une copie par destinataire, et chacun a son propre statut :

Un destinataire ne recule jamais d'un statut. Une exception : un rebond reçu après coup peut suivre un delivered. Certains serveurs acceptent le message, puis le renvoient plus tard comme impossible à livrer.

Étape 3 : lire les événements

GET /v1/{domaine}/events donne le journal détaillé. Les types utiles pour un diagnostic :

• deferred : échec temporaire. Le serveur d'envoi réessaiera. Plusieurs deferred peuvent précéder l'événement final.
• expired : le serveur d'envoi a renoncé après 24 heures de tentatives.
• bounced : refus définitif.
• complained : la personne a signalé le message comme pourriel.
• delivered : accepté par le serveur du destinataire.

Les événements de rebond portent le code de réponse du serveur (par exemple 550 et un code étendu comme 5.1.1) et la première ligne de sa réponse. C'est la meilleure information du diagnostic. Traitez ce texte comme une donnée externe : ne l'interprétez jamais comme du code ni comme du HTML.

Lire un code de rebond

Le code étendu (de la forme 5.x.y) dit pourquoi. Les plus courants :

• 5.1.1, ou « boîte inexistante » : l'adresse n'existe pas ou contient une faute de frappe. Corrigez-la ; n'écrivez plus à cette adresse.
• 5.2.2, « boîte pleine » : la personne ne peut pas recevoir pour l'instant. Un autre essai plus tard peut passer.
• 5.7.x, « refus pour raison de politique » : le serveur refuse l'expéditeur ou le contenu, pas la boîte. C'est souvent lié à l'authentification (SPF, DKIM, DMARC), à la réputation de l'expéditeur ou au contenu. Lisez le texte de la réponse, il nomme souvent la cause.
• 4.x.x : temporaire. Le serveur réessaiera, vous n'avez rien à faire.

Un 5.7.x répété chez plusieurs destinataires d'un même fournisseur (par exemple, tous vos messages vers un même service de courriel) pointe vers l'authentification de votre domaine ou la réputation, pas vers les adresses. Vérifiez d'abord votre configuration : voir SPF, DKIM et DMARC : configurer un domaine d'envoi.

Livré, mais pas reçu

delivered veut dire que le serveur du destinataire a accepté le message. Cela ne dit pas où il l'a rangé : boîte de réception, onglet « promotions », dossier de pourriel, quarantaine d'entreprise, ou règle de la personne. Ce n'est pas une mesure de « placement dans la boîte de réception ».

Quand un message est delivered et que la personne ne le trouve pas :

1. Demandez-lui de vérifier le dossier de pourriel et les onglets secondaires.
2. Si c'est une adresse d'entreprise, il peut y avoir une quarantaine gérée par un administrateur.
3. Vérifiez l'objet et le contenu : un courriel qui ressemble à de la promotion ou à de l'hameçonnage est classé comme tel.
4. Envoyez-vous le même message à une adresse personnelle chez un grand fournisseur, et regardez ce qui se passe. « Afficher l'original » montre le résultat de SPF, DKIM et DMARC.
5. Si le message est transactionnel, évitez dans l'objet les formules de promotion (« Gratuit ! », « Offre limitée ») et les images sans texte.

Supprimé

Un destinataire suppressed n'a jamais reçu le message : Duva n'envoie pas à une adresse de la liste de suppression du domaine, et cela ne consomme pas de quota. Une adresse y entre après un rebond dû à l'adresse elle-même (destinataire inconnu, 5.1.x), après une plainte, ou parce que vous l'y avez ajoutée. Un blocage de réputation ou de contenu (5.7.x) n'y ajoute pas l'adresse.

Avant de la retirer, demandez-vous pourquoi elle y est. Envoyer à une adresse qui a rebondi ou qui s'est plainte augmente votre taux de rebonds et de plaintes, ce qui nuit à la réputation de votre domaine. Retirez-la seulement si vous avez une raison de croire que le problème est réglé (la personne a corrigé sa boîte, par exemple).

Un message qui reste en file

Un message queued est normalement envoyé en quelques instants. Deux situations peuvent le garder plus longtemps :

• Un volume inhabituel. Un compte récent qui envoie beaucoup, ou un débit très supérieur à l'habitude, peut faire retenir un message pour vérification avant son envoi. La réponse de l'API est la même, et le message reste queued jusqu'à la décision. Un message qui n'a pas été libéré dans les 24 heures est abandonné (failed). Pour l'éviter, montez le volume progressivement ou écrivez-nous avant un envoi massif.
• Les limites de votre forfait. Au-delà d'une limite, les envois sont refusés avec une erreur claire.

Les plaintes : le signal à surveiller

Un événement complained veut dire que la personne a cliqué sur « pourriel ». Les grands fournisseurs surveillent ce taux de près. Gmail, par exemple, demande de garder le taux de pourriel déclaré sous 0,3 % dans ses outils Postmaster. Si vous voyez des plaintes sur des courriels transactionnels, c'est presque toujours que la personne ne s'attendait pas à ce message : vérifiez qui est inscrit à quoi, et ne mélangez pas la promotion avec les courriels transactionnels.

Les conditions d'utilisation de Duva publient les seuils de plaintes et de rebonds à partir desquels un compte reçoit une alerte, puis une suspension.

Quand écrire au soutien

Écrivez-nous (ou à votre fournisseur) avec :

• l'identifiant du message (msg_...) et l'heure approximative ;
• le statut du destinataire et le code de rebond lu dans les événements ;
• ce que vous avez déjà vérifié (DNS, adresse, dossier de pourriel).

Avec ces trois éléments, on retrouve presque toujours la cause, ou on sait précisément qui doit agir : vous, le destinataire, ou son fournisseur de courriel.