Hard bounce, soft bounce : codes SMTP et règle de retrait

Gmail renvoie la même boîte pleine sous deux codes opposés : un 452 4.2.2 temporaire et un 552 5.2.2 définitif quand le compte est aussi inactif (documentation Google Workspace, consultée en octobre 2026). Le premier est un soft bounce, le second un hard bounce, pour une même boîte pleine selon qu’elle est active ou inactive. Un hard bounce (rebond dur) est un refus permanent : le message ne sera pas livré tant que l’adresse ou le message ne change pas. Un soft bounce (rebond doux) est un échec temporaire que le routeur retente. Règle de retrait : supprimez l’adresse au premier hard bounce et retirez-la au 3e soft bounce consécutif, sur 3 envois étalés sur au moins 14 jours. La suite décortique un NDR ligne à ligne et rattache chaque seuil chiffré à sa source.

Hard bounce et soft bounce : comparaison point par point

Les valeurs de la ligne « Nouvelle tentative » viennent de la RFC 5321 (sections 4.2.1 et 4.5.4.1). Les routeurs fixent ensuite leur propre durée d’abandon, consultable dans leur documentation.

Quels codes SMTP séparent un hard bounce d’un soft bounce ?

Un code 4xx annonce un échec temporaire (soft bounce), un code 5xx un échec permanent (hard bounce) : le premier chiffre de la réponse SMTP fixe la classe.

Le détail se trouve dans l’enhanced status code, défini par la RFC 3463 (janvier 2003). Il compte trois champs séparés par des points : classe, sujet, détail. La classe vaut 2 (succès), 4 (échec temporaire persistant) ou 5 (échec permanent). Le sujet désigne la zone en cause. Le 1 vise l’adresse, le 2 la boîte, le 3 le système de messagerie, le 4 le réseau, le 5 le protocole, le 6 le contenu, le 7 la sécurité et la politique.

Le code 5.1.1 se lit donc ainsi : échec permanent (5), problème d’adresse (1), partie gauche de l’arobase invalide (1). La RFC réserve ce code aux échecs permanents. Le catalogue complet des réponses est dans le guide des codes de réponse SMTP. Le détail des cas 550 5.4.1 et 552 se lit dans les codes d’erreur SMTP, un par un.

Lire un NDR ligne à ligne : l’exemple du 550 5.1.1

Le NDR (non-delivery report) est un message au format DSN, décrit par la RFC 3464, renvoyé à l’expéditeur. L’exemple ci-dessous est reconstitué : les champs suivent la RFC 3464 et le diagnostic reprend le texte que Google documente pour le 550 5.1.1. Adresses et hôte expéditeur sont fictifs.

Reporting-MTA: dns; smtp.routeur-exemple.com
Final-Recipient: rfc822; prenom.nom@gmail.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550 5.1.1 The email account that you tried to reach does not exist.

• Reporting-MTA nomme le serveur qui rédige le rapport : ici votre routeur.
• Final-Recipient donne l’adresse en échec. C’est la clé de rapprochement avec votre liste.
• Action: failed indique que la livraison a échoué définitivement.
• Status: 5.1.1 est l’enhanced status code : le 5 classe l’échec en permanent, le 1.1 désigne une boîte inexistante.
• Remote-MTA identifie le serveur qui a refusé, ici l’entrée MX de Gmail.
• Diagnostic-Code recopie la réponse brute du serveur : le 550 de la couche SMTP, puis le 5.1.1, puis le texte lisible. Google invite à vérifier la faute de frappe ou l’espace en trop.

Le même rapport pour une boîte qui se remplit change trois lignes, d’après le texte Google pour le 452 4.2.2 :

Action: delayed
Status: 4.2.2
Diagnostic-Code: smtp; 452 4.2.2 The recipient's inbox is out of storage space.

Le rapport delayed prévient que le routeur réessaie encore. Un détail change la lecture d’un dashboard. Une notification finale peut afficher Action: failed avec un Status: 4.2.2. La RFC 3463 définit la classe 4 comme une condition temporaire qui a provoqué l’abandon ou le retard de l’envoi. Le routeur a renoncé après ses tentatives, sans refus définitif du serveur. Ce cas se classe en soft bounce épuisé.

Table de décision : du code à l’action

Les libellés viennent de la documentation Google Workspace sur les erreurs SMTP de Gmail et des définitions de la RFC 3463.

La dernière ligne est la plus coûteuse à mal lire. Un 5.7.26 signifie, d’après Google, que le message est bloqué faute d’authentification (SPF ou DKIM) ou parce que la politique DMARC du domaine le rejette. L’adresse est valide : c’est votre domaine qui échoue. La suppression de ces contacts vide la liste sans régler la cause. Le greylisting relève de la ligne 4.7.x : le serveur refuse volontairement le premier essai d’un expéditeur inconnu. Le second passe.

Bounce synchrone et asynchrone : quand le refus arrive

Un refus synchrone tombe pendant la session SMTP. Le serveur répond 550 5.1.1 à la commande RCPT TO (ou à la fin de DATA) : votre routeur connaît le résultat avant de fermer la connexion et il n’y a aucun NDR à attendre.

Le bounce asynchrone suit un autre trajet. Le serveur répond d’abord 250 et prend le message en charge. Si la livraison échoue ensuite en interne, la RFC 5321 (section 6.1) lui impose de rédiger une notification. Elle part à l’adresse de retour avec un expéditeur vide : la commande MAIL FROM contient alors <> (section 3.6.3), ce qui évite les boucles de notifications. Ce NDR atterrit dans la boîte de bounces de votre domaine, parfois plusieurs jours après l’envoi, au format DSN décrit plus haut. Pour votre liste, la conséquence est directe : un rebond asynchrone n’apparaît pas dans le compte rendu immédiat de l’envoi. Il se rattache à l’adresse par le champ Final-Recipient, puis suit les mêmes règles qu’un refus synchrone : hard bounce, retrait immédiat. Un routeur qui ne lit pas cette boîte de retour laisse ces adresses en circulation et gonfle le taux de rebond de la campagne suivante.

Selon leur configuration, les domaines catch-all produisent ce second cas : ils acceptent toute adresse pendant la session SMTP puis trient le courrier derrière. Une adresse inexistante peut alors repartir en NDR différé ou disparaître sans aucune réponse. Aucun code reçu pendant la session ne permet de l’anticiper. Ne figez donc le taux de rebond d’une campagne qu’après la fenêtre d’abandon de votre routeur. Traitez aussi le silence d’un domaine catch-all comme une information incomplète. Les emails non livrables regroupent ces cas limites, avec la manière de les trier.

Pièges de lecture : le 5xx à conserver et le cache de suppression

Le premier chiffre classe le rebond et ne dit rien de la validité de l’adresse. Les familles 5.7.x décrites plus haut portent souvent un 5 sur des contacts valides.

Deux autres pièges faussent la lecture. Le répondeur automatique prouve que le message est arrivé dans la boîte : il ne compte pas comme rebond. Le classer en soft bounce ferait sortir un contact actif. Le cache de suppression joue dans l’autre sens : une adresse placée dans la liste de suppression interne du routeur n’est plus envoyée, même si la boîte a été recréée entre-temps. Un contact qui jure ne rien recevoir alors que son adresse est valide se cherche d’abord dans cette liste. Le même réflexe vaut après une correction de faute de frappe : la nouvelle adresse est inconnue du routeur et passe. L’ancienne, mal écrite, reste en suppression. Elle ne ressortira jamais d’un export de rebonds. Rapprochez donc les deux lignes avant de conclure qu’un contact a été perdu.

Règle de retrait : combien d’envois, sur quelle durée

Pour un hard bounce, le délai est nul. Klaviyo supprime ces profils automatiquement. Mailchimp nettoie l’adresse de l’audience (pages d’aide consultées en octobre 2026). Les 5.7.x font exception : ils visent votre configuration. Une faute de frappe à la collecte se corrige à la source, avec un double opt-in.

Pour un soft bounce, appliquez quatre règles :

• Comptez un rebond par envoi. Les tentatives d’un même routeur, étalées sur plusieurs jours, ne comptent que pour un.
• Retirez l’adresse au 3e soft bounce consécutif, sur des envois distincts.
• Nous conseillons 14 jours au moins entre le premier et le troisième rebond, afin de séparer une boîte durablement hors service d’une panne passagère chez le destinataire. Ce délai est un choix éditorial : aucune norme ne l’impose.
• Remettez le compteur à zéro dès qu’un envoi est livré.

Application : une adresse en 452 4.2.2 aux campagnes des 2 et 9 octobre puis du 23 sort de la liste le 23. À trois campagnes envoyées du 2 au 4 octobre, elle reste : trois rebonds en 2 jours relèvent d’une seule panne et l’adresse n’a pas encore franchi les 14 jours exigés.

Cette règle de retrait est une recommandation éditoriale. Les routeurs publient des seuils différents. MailerLite indique dans son guide des bounces qu’une adresse qui rebondit 3 fois d’affilée est convertie en hard bounce et devient inactive. Mailchimp convertit un soft bounce en hard bounce après 7 rebonds pour une adresse sans activité d’abonné. Pour un contact avec activité antérieure, la limite monte à 15. L’adresse est ensuite nettoyée (aide officielle Mailchimp, consultée en octobre 2026). Klaviyo applique un seuil plus haut : d’après sa page d’aide « Suppressed profiles » (mise à jour le 30 mars 2026), le profil est supprimé après plus de 7 soft bounces consécutifs. Seuls ceux des 2 dernières années entrent dans le décompte. La même adresse peut donc survivre à 7 rebonds dans un outil et sortir au 3e dans l’autre. Dans un routeur permissif, sortez l’adresse vous-même par un segment d’exclusion.

La durée dépend aussi de votre rythme d’envoi. Le décompte se fait par envoi : une campagne hebdomadaire atteint le 3e rebond en 3 semaines, une campagne mensuelle en 3 mois. Une fréquence trop basse retarde donc le retrait : à un envoi par mois, une adresse morte reste dans la liste un trimestre.

Seuils de bounce : ce que mesure chaque pourcentage

Les seuils à retenir sont 2 % et 5 % pour les rebonds, 0,3 % pour le spam signalé. Ils ne mesurent pas la même chose.

Le premier, 2 %, est un repère de la profession pour le taux de rebond (MailerLite). Le deuxième, 5 %, est une limite contractuelle : la politique anti-spam de MailerLite se réserve de suspendre un compte et d’enquêter au-delà de 5 % de bounces ou de 0,2 % de plaintes.

Le troisième, 0,3 %, vient de Google et porte sur autre chose : le taux de spam affiché dans Postmaster Tools, c’est-à-dire la part de messages que les destinataires signalent comme indésirables. Depuis le 1er février 2024, tous les expéditeurs vers Gmail doivent le maintenir sous 0,3 %. Google recommande de rester sous 0,10 %.

Rebond et signalement sont deux mesures distinctes : le routeur compte les premiers, Postmaster Tools les seconds. Une liste peut afficher 1,5 % de bounces, sous les 2 %, avec 0,05 % de spam et ne franchir aucun seuil. L’inverse existe aussi : 0,4 % de spam avec 0,2 % de bounces dépasse la règle de Google. Le seuil de 2 % s’applique à la moyenne d’une campagne : sur 10 000 envois, il représente 200 rebonds au total. Une seule vague de hard bounces sur une liste ancienne suffit à le franchir. Pour ramener un taux de rebond élevé sous le repère de 2 %, voir la gestion du taux de rebond.

Bounces, réputation d’expéditeur et blocklists

Un envoi vers une liste ancienne fait remonter des 5.1.1 dans le rapport de campagne. Chaque 5.1.1 prouve qu’une adresse a été collectée, puis jamais revérifiée : le rapport de campagne dresse alors l’inventaire de ce que la liste a perdu depuis la collecte. Pour lire la tendance, comparez le nombre de 5.1.1 par envoi sur trois campagnes successives. Une courbe qui monte signale une liste qui vieillit, une courbe plate un problème ponctuel d’import. Le suivi passe par Postmaster Tools côté Gmail (le taux de spam y est comparé au plafond de 0,3 %) et par le suivi du Sender Score pour la note de l’adresse IP.

Sur une IP neuve en montée en charge, chaque 5.1.1 pèse plus lourd : Google demande de démarrer avec des destinataires engagés, ce qu’une liste non nettoyée contredit. La méthode est décrite dans l’échauffement d’une IP.

Les spam traps (adresses piégées) se cachent dans les listes anciennes ou achetées et peuvent mener aux blocklists. Les spam traps et honeypots sont expliqués à part. Une fois sur Spamhaus ou une autre liste, la sortie passe par une demande auprès du gestionnaire, dont la marche à suivre est décrite pour délister une blocklist. Le tri entre blocklists à surveiller ou à ignorer indique lesquelles méritent une alerte.

Causes en amont à traiter dès la collecte

Les listes achetées concentrent les adresses invalides et les pièges : le premier envoi y produit un pic de hard bounces, d’où un taux de rebond qui dépasse tous les repères. Le double opt-in élimine les fautes de frappe et les faux emails à l’inscription. Un nom de domaine expiré ou sans enregistrement MX produit un 5.1.2. Les refus 5.7.x d’authentification se règlent côté SPF, DKIM et DMARC, dont la version DKIM2, en cours de normalisation au groupe de travail DKIM de l’IETF (datatracker.ietf.org, consulté en octobre 2026), vise à améliorer la valeur des notifications de non-remise. Un contenu ou un objet d’email jugé suspect déclenche le même type de refus de politique, sans que l’adresse soit en cause.

Questions fréquentes sur les rebonds

Faut-il supprimer une adresse après un seul soft bounce ?

Non. Un soft bounce isolé vient souvent d’une boîte pleine ou d’une panne passagère. Comptez-le dans votre règle : retrait au 3e rebond consécutif sur des envois étalés sur 14 jours au moins. Le compteur repart de zéro dès qu’un message est livré.

Un hard bounce peut-il redevenir valide ?

Oui, dans de rares cas : boîte recréée ou faute de frappe corrigée. Le routeur garde l’adresse en suppression et n’essaie plus. Retirez-la de cette liste au cas par cas, sur confirmation du contact.

Combien de temps un routeur retente-t-il un soft bounce ?

La RFC 5321 recommande au moins 30 minutes entre deux essais et une durée d’abandon d’au moins 4 à 5 jours. Chaque routeur applique sa propre durée : vérifiez-la dans sa documentation avant de calculer un taux de rebond final.

Vérifier la liste avant l’envoi

Le filtrage après coup revient à envoyer une fois à chaque adresse morte : le hard bounce est déjà compté dans la campagne quand le routeur supprime le profil. La vérification en amont retire ces adresses avant le premier envoi. Un vérificateur contrôle le domaine et l’existence de la boîte : exactement ce que le 5.1.1 et le 5.1.2 sanctionnent après coup. Les outils de vérification d’emails sont comparés dans un guide. L’entretien régulier d’une base de données propre évite que la liste ne reperde ce qu’elle a gagné.

Avant votre prochaine campagne, passez un échantillon de la liste dans l’outil de vérification de liste email de CaptainVerify et comparez le résultat à votre taux de hard bounce actuel.