Mon e-mail a rebondi une fois, mais est passé quand je l'ai renvoyé. Que s'est-il passé ?

Seul le diagnostic d'origine peut le dire. La mise en liste grise (greylisting) — un serveur rejette temporairement la première tentative d'un expéditeur inconnu — est une possibilité, mais la limitation de débit, un souci de DNS ou de réseau, et la simple charge du serveur se comportent pareil. Votre serveur d'envoi réessaie normalement de lui-même après un rejet temporaire 4xx ; un incident isolé qui s'est réglé ne demande donc généralement aucune action. Si cela se répète, envoyez le diagnostic complet à votre fournisseur d'e-mail.

Un rebond veut-il dire que mon adresse e-mail est bloquée ou compromise ?

En général, non. Un rebond isolé reflète le plus souvent une adresse de destinataire, sa boîte mail, une politique ou un problème temporaire. Les ennuis côté expéditeur peuvent apparaître comme des réponses 4xx ou 5xx mentionnant l'authentification, les limites de débit, la réputation, le DNS inverse ou le contenu. Le vrai signal d'alerte est ailleurs : des rebonds pour des messages que vous n'avez jamais envoyés, ou une soudaine avalanche de rebonds — vérifiez votre dossier Envoyés et l'activité du compte, et contactez votre fournisseur ; ce schéma suggère une usurpation, du backscatter ou un abus du compte, sans être pour autant la preuve d'une intrusion.

Pourquoi votre e-mail a rebondi (et ce que vous pouvez corriger)

Un rebond est une notification d’état de livraison générée quand un système de messagerie n’a pas pu remettre votre message. Il arrive sous la forme d’un message « Delivery Status Notification » ou « Mail Delivery Failed » ; il peut citer la réponse SMTP du serveur destinataire, ou signaler un échec de DNS, de routage ou de connexion rencontré côté envoi avant même d’atteindre le destinataire. À l’intérieur se trouve généralement le meilleur indice disponible sur ce qui a mal tourné — apprenez à le lire et la plupart des rebonds cessent d’être mystérieux. Deux vérifications avant tout : confirmez que l’avis concerne un message que vous avez réellement envoyé (les faux « rebonds » existent — ne cliquez pas sur les liens de messages inattendus), et si le message avait plusieurs destinataires, regardez quelle adresse a échoué : l’état de livraison est propre à chaque destinataire, et les autres l’ont peut-être bien reçu.

Échecs permanents contre reports temporaires

La première chose à identifier : la réponse était-elle définitive, ou une invitation à réessayer ?

Rejet permanent (codes 5xx) — le côté destinataire a refusé la requête telle quelle : la boîte mail n’existe pas, le message a été refusé par une politique, ou il était trop gros. Votre serveur le signale comme un échec ; renvoyer le même message tel quel n’aidera pas.
Report temporaire (codes 4xx) — pas un échec final. La boîte mail est pleine, le serveur est occupé, ou vous êtes en liste grise. Votre serveur d’envoi met le message en file et réessaie de lui-même ; il peut vous envoyer un avis de « livraison retardée », et ce n’est que si les tentatives s’épuisent qu’il envoie un échec définitif — qui peut encore citer la condition 4xx d’origine. La durée des tentatives dépend de la configuration du serveur d’envoi ; ne supposez donc pas un délai fixe et ne renvoyez pas sans arrêt à la main.

Lire le code SMTP

Deux choses comptent : le code de base à trois chiffres (commence-t-il par 4 ou par 5) et le code d’état détaillé (comme 5.1.1 ou 4.2.2), plus le texte de diagnostic complet — c’est ce détail, pas le simple numéro, qui identifie le problème. Ne traitez pas des numéros voisins comme interchangeables : 452 (« stockage insuffisant » temporaire, réessai) et 552 (refus permanent de quota ou de taille) sont des issues différentes malgré leur ressemblance. Certains avis sont trop vagues pour un diagnostic à eux seuls ; l’étape suivante, ce sont alors les journaux de votre fournisseur.

550 5.1.1 Recipient address rejected: User unknown   → destination mailbox doesn't exist (permanent)
452 4.2.2 Mailbox full / over quota                   → temporary: recipient inbox full, retry
552 5.2.2 Mailbox full / over quota                   → permanent refusal: contact the recipient
552 5.2.3 / 5.3.4 Message too large                   → permanent: shrink it or share the file another way
421 / 451  Try again later / temporarily deferred      → greylisting, rate limits, or server busy (temporary)
4xx/5xx ... SPF/DKIM/DMARC ...                         → an authentication result contributed
554 ... blocked using a blocklist ...                  → a reputation or policy check rejected it
Connection timed out                                  → no response in time — cause not yet known

550 5.1.1 « User unknown » — le système de destination dit que cette boîte mail n’existe pas. Souvent une faute de frappe — mais la boîte a aussi pu être supprimée ou renommée ; si l’adresse a l’air correcte, procurez-vous une adresse à jour ou joignez la personne autrement plutôt que de renvoyer à l’aveugle. Un échec permanent courant, et souvent réparable de votre côté.
452 contre 552, boîte pleine — la version 4xx est temporaire : votre serveur réessaie et le destinataire peut faire de la place. La version 5xx est un refus permanent : joignez le destinataire autrement. Si le diagnostic dit plutôt que le message est trop gros (5.2.3/5.3.4), celui-là est pour vous : compressez ou retirez les pièces jointes, ou utilisez un lien de partage de fichiers — l’encodage rend un fichier envoyé par e-mail plus gros que l’original.
421 / 451 « deferred » — temporaire. La liste grise rejette délibérément une première tentative et accepte généralement le réessai ; les serveurs chargés reportent aussi pendant les pics. Laissez le réessai automatique travailler — mais guettez un éventuel avis d’échec définitif, car un 4xx invite à réessayer sans promettre l’acceptation.
SPF, DKIM ou DMARC mentionnés — un résultat d’authentification ou une politique a contribué au rejet. Cela peut vouloir dire des enregistrements DNS, mais aussi un service d’envoi non autorisé dans votre SPF, une signature DKIM coupée ou mal alignée, ou un saut de transfert — lisez donc le diagnostic complet avant de toucher à quoi que ce soit. Si vous modifiez le DNS : n’ajoutez jamais un deuxième enregistrement SPF (mettez à jour l’existant), et vérifiez que la signature DKIM est activée pour le sélecteur publié. Le conseil n° 8, serveur mail sécurisé, couvre la configuration.
554 bloqué / listé — un contrôle de réputation ou de politique a rejeté le message. Identifiez exactement ce qui est listé — une adresse IP, un domaine, autre chose — et si la liste est publique (avec une procédure de retrait publiée) ou s’il s’agit de la politique propre au destinataire. Corrigez d’abord la cause de fond ; certaines inscriptions expirent ensuite d’elles-mêmes, d’autres demandent une demande de retrait.
Connection timed out — aucune réponse SMTP n’est arrivée à temps. Cela peut venir du serveur de destination, du DNS, du routage, d’un pare-feu ou de votre propre service d’envoi — le délai dépassé, en soi, ne le dit pas. Laissez les réessais se dérouler ; si cela devient définitif ou se répète, remettez le diagnostic à votre fournisseur d’e-mail.

Qui répare quoi

Le diagnostic vous dit généralement qui est le mieux placé pour agir — comme guide, pas comme loi :

Vous : corrigez une adresse mal tapée, réglez l’authentification de votre service d’envoi (avec précaution — voir plus haut), évitez les schémas d’envoi qui déclenchent les filtres, allégez les messages trop gros.
Le destinataire : une boîte pleine, un serveur qui rejette ou hors ligne, un filtre trop agressif de son côté. Appelez-le et laissez-le régler ça.
Votre fournisseur d’e-mail : routage, réputation, listes de blocage, DNS inverse, soucis de serveur partagé. Si vous envoyez via une boîte mail gérée, la fonction e-mail d’un site web ou une plateforme de newsletter, c’est le fournisseur qui contrôle l’adresse IP d’envoi et tout retrait de liste — donnez le diagnostic complet à son assistance plutôt que d’essayer de vous délister vous-même.
Personne — attendez : liste grise et reports temporaires se règlent généralement au réessai automatique.

Lisez d’abord le code détaillé et le texte de diagnostic : vous saurez généralement s’il faut corriger une adresse, impliquer votre fournisseur ou simplement laisser le réessai faire son travail — et quand l’avis est trop vague pour trancher, c’est le duo diagnostic + journaux de votre fournisseur qui répond.

Ce qu’il faut faire

Confirmez d’abord que le rebond correspond à un message que vous avez réellement envoyé, puis trouvez le code — le numéro 4xx/5xx, l’état détaillé (par exemple 5.1.1) et le texte de diagnostic — et regardez à quel destinataire il s’applique.
Un 4xx est un report temporaire — le serveur d’envoi réessaie de lui-même ; attendez, mais guettez un avis d’échec définitif.
Un 550 « User unknown » : cherchez la faute de frappe ; si l’adresse a l’air correcte, demandez-en une à jour au destinataire par un autre canal.
L’authentification est mentionnée ? Lisez le diagnostic complet avant de changer le DNS — pas de deuxième enregistrement SPF, corrigez la configuration existante, ou confiez-la à la personne qui gère votre messagerie.
Boîte pleine : le temporaire se réessaie tout seul, le permanent veut dire contacter le destinataire. Message trop gros : allégez-le ou partagez un lien. Délai dépassé : laissez les réessais courir, remontez à votre fournisseur d’e-mail si cela se répète.
Rebond de liste de blocage : identifiez ce qui est listé, corrigez la cause, puis suivez les consignes actuelles de cette liste — via votre fournisseur d’e-mail s’il contrôle l’adresse IP d’envoi.