Lire un bounce email : les codes, et ce qu’ils disent

Ce qu’est un bounce, et les deux moments où il se produit

Le mot est emprunté au courrier papier, et c’est la mauvaise image. Rien ne revient en arrière. Un message est transmis de serveur en serveur, et le dernier qui le détient encore et ne parvient pas à s’en débarrasser écrit un nouveau message — adressé à vous, au sujet de l’ancien — et l’envoie à la place. Tout ce que vous pouvez apprendre se trouve dans ce rapport, et le rapport ne vaut que ce que vaut la machine qui l’a écrit.

Il peut être produit à deux moments très différents, et les distinguer constitue l’essentiel du diagnostic. Deux autres issues ressemblent à des échecs de votre point de vue, et n’en sont pas :

Donc « ça a rebondi » désigne deux choses. L’une est une erreur que votre propre logiciel vous a montrée, l’autre est une lettre qu’une machine inconnue vous a écrite, et seule la seconde contient un rapport à lire. Le reste de ce guide porte sur ce rapport.

Où se trouve vraiment la raison

Un rapport de non-remise est un message en trois parties, et cette forme est fixée depuis la RFC 3464. La première partie est l’excuse, écrite pour un humain par la machine la plus proche de vous. La deuxième est le bloc lisible par une machine, la seule partie qui contienne des faits. La troisième est votre message d’origine, ou seulement ses en-têtes, pour que vous puissiez savoir lequel a échoué.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

Lisez la partie du milieu dans cet ordre :

Final-Recipient:

Quelle adresse a échoué. Un rapport peut porter un bloc par destinataire, donc pour un message envoyé à plusieurs personnes, c’est ainsi que vous savez duquel il s’agit — et les autres sont peut-être bien arrivés.

Action:

failed signifie un bounce. delayed est un avertissement indiquant qu’un serveur essaie encore et n’a renoncé à rien ; vous pouvez encore recevoir un second rapport disant que cela a fonctionné. relayed et delivered ne sont pas du tout des échecs, et sont faciles à prendre pour tels.

Status:

Le code d’état étendu — trois nombres, destinés à être lus par un logiciel plutôt que par vous. C’est la partie comparable d’un fournisseur à l’autre, ce que les phrases ne sont jamais.

Diagnostic-Code:

La ligne qui compte. C’est la réponse propre au serveur distant, citée mot pour mot, portant son code de réponse et la phrase que son administrateur a bien voulu écrire. Tout ce qui précède n’est qu’un récit ; ceci est l’original.

Remote-MTA:

Quel hôte l’a dit. Cela vaut un coup d’œil chaque fois que l’échec concerne le routage : un nom d’hôte que vous ne reconnaissez pas signifie généralement que le courrier du domaine part vers un endroit inattendu, ou vers un endroit qui n’était sa destination que par le passé.

La phrase tout en haut du rapport n’est pas une preuve. C’est votre propre serveur sortant qui l’écrit, dans la formulation que son logiciel utilise par défaut, au sujet d’un échec qu’il ne fait que transmettre. Deux excuses identiques peuvent surmonter deux lignes Diagnostic-Code: totalement sans rapport, ce qui explique pourquoi un bounce lu à partir du haut est si souvent mal compris.

Les deux nombres, et le chiffre qui décide

Un refus s’écrit ainsi, et ce sont trois éléments distincts réunis par des espaces :

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

Le 550 est le code de réponse : trois chiffres, définis par SMTP lui-même dans la RFC 5321, et la partie dont le protocole a besoin pour décider de la suite. Le 5.1.1 est le code d’état étendu de la RFC 3463, ajouté parce que trois chiffres ne suffisaient pas à tout exprimer. Tout ce qui suit est du texte libre, écrit par qui gère ce serveur, et normalisé par absolument rien.

Les deux nombres commencent par le même chiffre, et ce chiffre est le verdict :

Le second nombre est le sujet — quel genre de chose a mal tourné. C’est le moyen le plus rapide de situer un code que vous n’avez jamais vu :

Bounce définitif (hard bounce)

Un 5. L’adresse est erronée, disparue, ou refusée par principe, et renvoyer le même message ne change rien. Les expéditeurs en masse retirent une adresse de leur liste dès le premier, parce que persister est exactement ce qui fait brider un domaine d’envoi partout à la fois.

Bounce temporaire (soft bounce)

Un 4. Une boîte pleine, un serveur occupé, un refus de politique temporaire. Il est réessayé sans l’aide de personne et arrive généralement ; vous n’en entendez parler que si les tentatives s’épuisent d’abord.

Aucun des deux termes ne figure dans une quelconque spécification. Ce sont les raccourcis de l’industrie de l’envoi pour ce premier chiffre, qui, lui, y figure — et ce raccourci vaut la peine d’être connu, car tout outil de délivrabilité qu’on vous confiera un jour s’exprime dans ces termes.

Les codes que vous rencontrerez réellement

Il y en a des dizaines dans le registre que tient l’IANA, et une douzaine environ dans la vie courante. Ceux-ci couvrent quasiment tous les bounces que quiconque lit :

Des codes en dehors de cette liste existent, et chacun signifie quelque chose, mais un code que vous n’avez jamais vu auparavant est presque toujours un .7. — la politique de quelqu’un, décrite dans ses propres mots sur la ligne d’à côté.

Ce qui peut et ne peut pas rebondir sur une adresse temporaire

Presque rien — et cela vaut la peine d’être précisé, car trois des choses que les gens décrivent ici comme un bounce n’en sont pas :

« Utilisateur inconnu » ne peut pas se produire

Le serveur accepte tous les noms sur ses domaines publics. anything@grabmail.io est une adresse valide avant même que quiconque ne l’ait tapée, parce qu’il n’existe aucune liste de boîtes contre laquelle la vérifier — donc un 5.1.1 venant de GrabMail n’est pas une chose qui existe. Comment le mail temporaire fonctionne en dessous détaille le mécanisme en entier.

L’expiration n’est pas un bounce

Un message est supprimé 5 jours après son arrivée, et à ce moment-là, le serveur expéditeur a reçu 250 depuis longtemps et a oublié tout l’échange. Personne n’est prévenu, parce que rien n’a échoué : le message a été distribué, puis supprimé plus tard. Combien de temps dure une boîte est le guide pour cette moitié-là.

Un formulaire qui refuse l’adresse n’est pas un bounce

Aucun courrier n’a jamais été envoyé. Le site a comparé le domaine à une liste et rejeté le formulaire ; rien n’a jamais atteint un serveur de messagerie, et il n’y a rien à lire. Pourquoi les formulaires d’inscription bloquent le mail jetable est un problème différent, avec des réponses différentes.

Le silence n’est pas un bounce non plus

Si quelque chose que vous attendiez n’est jamais arrivé et que personne ne vous a envoyé de rapport, l’échec — s’il y en a eu un — s’est produit du côté de l’envoi, là où vous ne pouvez pas le voir. Le courrier qui ne se présente pas passe en revue les causes dans l’ordre où il vaut la peine de les vérifier.

Il ne reste donc qu’un seul refus authentique, et c’est le plafond de taille. Un serveur expéditeur qui annonce la taille à l’avance est repoussé immédiatement, avant qu’un seul octet ne soit stocké :

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Un expéditeur qui n’annonce pas la taille reçoit la même réponse à la fin du message à la place, une fois que les octets ont été comptés pour lui. Dans les deux cas, le code est 5.3.4, rien n’est stocké, et une vraie personne en est informée par son propre système de messagerie — ce qui est la raison même de refuser à la porte plutôt que d’accepter puis de jeter.

Il n’existe ni formule ni en-tête qui relève ce plafond, et aucun bounce pour quoi que ce soit d’autre ici : pas de quota entrant, pas de limite de débit, pas de refus parce que quelqu’un utilise déjà ce nom. Sur un domaine partagé, deux personnes qui tapent le même nom partagent simplement la boîte, ce qui est une propriété de confidentialité plutôt que de livraison.

Les bounces sur un domaine que vous venez de pointer ici

Pointer un domaine vers une boîte catch-all tient en un seul enregistrement DNS, et presque tous les bounces qu’il produit appartiennent à l’heure qui entoure le changement, plutôt qu’à la configuration elle-même. Il y a cinq cas, et ils se distinguent nettement les uns des autres :

1. Avant que l’enregistrement n’existe. Un domaine sans MX ni enregistrement d’adresse de repli renvoie aux expéditeurs 5.4.4 ou 5.1.2 : il n’y a nulle part où livrer, et rien qui vaille la peine d’être réessayé.
2. Pendant que le changement se propage. Les expéditeurs qui ont déjà consulté l’enregistrement conservent l’ancienne réponse jusqu’à l’expiration de son TTL. Un bounce dans cette fenêtre nomme l’ancien hôte sur la ligne Remote-MTA:, ce qui est précisément ce qui permet de le distinguer d’un enregistrement que vous avez mal configuré.
3. Une fois qu’il s’est propagé. Tous les noms sur le domaine sont acceptés, si bien que « utilisateur inconnu » cesse aussi d’y être possible. Un seul enregistrement, priorité 10, pointant vers smtp.grabmail.io, et rien d’autre à publier pour que le courrier arrive.
4. Si le domaine publiait auparavant un MX nul. Les domaines parqués portent souvent l’enregistrement qui signifie « ce domaine ne reçoit jamais de courrier ». Les expéditeurs qui l’ont mis en cache répondent 5.1.10 jusqu’à son expiration, quoi que vous ayez publié depuis.
5. Si le domaine envoie aussi du courrier. Un 5.7.26 sur du courrier sortant n’a rien à voir avec tout cela — c’est votre propre SPF ou DMARC qui ne couvre pas ce qui a envoyé le message. Le guide receive-only est le cas strict ; un domaine qui envoie aussi a besoin, à la place, du déploiement progressif ordinaire.

Lire l’enregistrement répond à presque tout cela avant que quiconque ait à lire un bounce :

$ dig +short MX yourdomain.com

La réponse devrait tenir en une ligne : la priorité, puis l’hôte, puis un point final. Tout le reste — deux lignes, un hôte inconnu, rien du tout — est le bounce que vous êtes sur le point de recevoir, avec trois minutes d’avance. Pointer votre propre domaine ici est la configuration complète, et les trois enregistrements qui arrêtent l’usurpation sont ce qu’il faut publier une fois que le courrier arrive.

Un bounce pour un message que vous n’avez jamais envoyé

Il arrive en ressemblant exactement à un rapport d’échec ordinaire, citant un message que vous n’avez jamais vu, adressé à un destinataire dont vous n’avez jamais entendu parler. Rien n’a été piraté. Quelqu’un a envoyé du courrier avec votre adresse inscrite dans l’enveloppe comme expéditeur, un serveur destinataire l’a accepté avant de découvrir qu’il ne pouvait pas le livrer, puis a fait ce qu’il fallait avec un message en échec : il a écrit un rapport et l’a posté à l’expéditeur qu’on lui avait donné. C’est-à-dire vous.

Cela s’appelle le backscatter, et ce que cela prouve vaut la peine d’être dit clairement : rien sur votre boîte aux lettres. Forger un expéditeur d’enveloppe ne demande d’accéder à rien du tout — c’est une seule ligne tapée dans une conversation. Qui que ce soit qui l’ait fait n’avait besoin que de votre adresse, rien de plus, et il se peut fort bien qu’il l’ait devinée.

Trois éléments le distinguent d’un vrai bounce en une dizaine de secondes :

• Le message renvoyé n’est pas le vôtre. La troisième partie du rapport porte l’original, ou du moins ses en-têtes. Si vous ne l’avez jamais écrit, vous ne l’avez pas envoyé, et tout le reste du rapport concerne le problème de quelqu’un d’autre.
• La chaîne Received: commence quelque part que vous n’avez jamais utilisé. Lisez-la de bas en haut : la ligne la plus basse est la machine qui a réellement injecté le message, et ce ne sera pas votre fournisseur. Lire un en-tête d’e-mail explique le sens de lecture, et pourquoi le bas est l’extrémité honnête.
• Les dates ne concordent pas. Le backscatter rapporte généralement un message envoyé des heures ou des jours avant que le rapport ne vous parvienne, sorti d’une file d’attente qui réessaie depuis la campagne de quelqu’un d’autre.

Il n’y a rien à réparer, et rien à répondre. Si l’adresse appartient à un domaine que vous possédez, publier SPF et DMARC le réduit de la seule façon qui fonctionne : un serveur destinataire qui vérifie la politique de l’expéditeur avant d’accepter refuse le faux pendant la conversation, et ne génère jamais de rapport pour personne. Trois enregistrements sur un domaine qui ne fait que recevoir en est la version la plus stricte, et de loin la plus facile à publier.

Un nom court sur un domaine public partagé en récolte davantage qu’une adresse privée, pour la même raison qu’il récolte plus de spam : il est facile à deviner, et un faussaire qui choisit des expéditeurs d’enveloppe ne vise personne en particulier. C’est du bruit au sujet de quelqu’un d’autre, et contrairement au spam, aucun bouton n’entraîne quoi que ce soit — ce que les commandes anti-spam font vraiment est le guide des boutons qui, eux, fonctionnent.

L’ordre dans lequel le lire

1. Déterminez quel genre vous avez sous les yeux. Une erreur dans votre propre application de messagerie au moment où vous avez appuyé sur envoyer est un refus. Un message de MAILER-DAEMON arrivé après coup est un rapport, et seul le rapport contient quelque chose à lire.
2. Vérifiez qu’il s’agit bien d’un message que vous avez réellement envoyé. La copie renvoyée se trouve dans la troisième partie. Si elle n’est pas de vous, c’est du backscatter, et vous en avez fini.
3. Ouvrez la source brute. L’excuse en haut est la formule toute faite de votre propre serveur, pas la raison, et le bloc lisible par une machine n’est affiché par défaut nulle part.
4. Trouvez Status: et lisez le premier chiffre. Un 4 est encore en cours de réessai et peut encore réussir de lui-même ; un 5 est définitif, et rien de plus ne se passera.
5. Lisez Diagnostic-Code:. C’est la phrase propre à l’autre bout, et le seul endroit où la règle qui vous a refusé est réellement nommée.
6. Situez le second chiffre. .1. c’est l’adresse, .2. la boîte, .4. le trajet, .7. la politique de quelqu’un. Cela suffit normalement à savoir de qui est le problème.
7. Agissez selon à qui appartient le problème. Un échec d’adressage se corrige en ayant la bonne adresse ; un échec de routage en corrigeant le DNS ; un échec de politique en satisfaisant la politique, ou en demandant à la personne de l’autre côté de consulter ses propres journaux — où le même refus est consigné bien plus longuement que ce qu’elle vous a envoyé.

Deux choses ne sont jamais la solution. Renvoyer le message sans le modifier après un 5 répète le même refus et, à force, endommage la réputation du domaine d’envoi partout à la fois. Et répondre au rapport ne joint personne : il vient d’un expéditeur d’enveloppe vide, ce qui est précisément la raison pour laquelle il a pu vous être livré en premier lieu.

Questions