Soft bounce vs hard bounce email : délivrabilité SMTP

Comprendre la différence entre soft bounce vs hard bounce email revient à maîtriser une règle SMTP : 4xx = « réessayer plus tard », 5xx = « cette adresse est partie ». Un soft bounce génère 4xx, l'infrastructure réessaie. Un hard bounce ramène 5xx, votre liste doit s'actualiser en minute. Se tromper accélère l'érosion de votre réputation de domaine plus que presque n'importe quelle autre erreur.

Les codes SMTP, critère unique de classification

Chaque rebond de livraison génère un code SMTP à trois chiffres. Le premier chiffre est le seul que votre système de gestion des rebonds doit exploiter.

4xx = condition temporaire : le serveur destinataire a accepté la connexion, traité le message, puis a décidé de ne pas le livrer à cet instant. 5xx = condition permanente : le serveur dit à votre infrastructure « arrête de cibler cette adresse ».

Cette bifurcation est de niveau infrastructure. Votre application ne doit pas décoder le texte diagnostique pour trancher ; le premier chiffre suffit.

Les 2ème et 3ème chiffres affinent le diagnostic. Un 452 signale une boîte saturée. Un 550 indique l'absence de l'adresse. Un 421 révèle l'indisponibilité momentanée du serveur. La plupart des classifieurs de rebonds cartographient ces sous-codes en événements internes, mais la séparation 4xx/5xx reste le pivot principal. Si votre pipeline traite tous les 4xx comme réessayables et tous les 5xx comme terminaux, vous couvrez environ 95 % des cas de production correctement.

Causes des rebonds temporaires et fenêtres de réessai

Les scénarios 4xx les plus courants rencontrés en infrastructure email de production, par fréquence décroissante :

Boîte pleine (452) : le quota du destinataire est épuisé. La plupart des ESP réessaient pendant 24 à 72 heures avant de passer en erreur permanente. Ce code est surreprésenté sur les boîtes personnelles ; il est rare en adresses B2B en isolation.

Greylisting (451) : le serveur MTA destinataire diffère temporairement les expéditeurs inconnus pour prévenir le spam. Un réessai 10 à 30 minutes plus tard réussit généralement. C'est une phase normale du premier envoi depuis un nouveau domaine ou une nouvelle IP, non un indicateur de dégradation de la liste en soi.

Serveur temporairement indisponible (421) : le serveur distant est hors ligne, rate-limite, ou surchargé. Réessayez avec un backoff exponentiel. La plupart repartent dans quelques heures ; si cela persiste plusieurs jours pour le même domaine, le domaine lui-même peut être en difficulté.

Message trop volumineux (552/554 variante temporaire) : le mail dépasse la limite de taille du serveur pour cette boîte. Réessayer sans réduire la charge sera infructueux ; routez vers une queue dédiée et alertez l'expéditeur.

Fenêtres de réessai standards en production : premier réessai après 5 minutes, puis 30 minutes, puis 2 heures, puis 6 heures, puis 24 heures. Après 5 jours sans livraison réussie, la convention SMTP est de générer un rapport de non-livraison (NDR) et de retourner le message à l'expéditeur. Votre ESP respecte cette fenêtre de 5 jours ou la réduit selon sa politique ; vérifiez votre configuration.

Métriques à tracker : le ratio de rebonds temporaires résolus au premier réessai contre ceux demandant plus de trois tentatives. Une liste saine résout la plupart des 452 et 421 en deux réessais maximum. Une persistance élevée sur plusieurs cycles est un signal d'investigation par segment.

Les trois patterns de rebond permanent rencontrés en pipeline

5xx ne forme pas une classe homogène. Les sous-codes révèlent des actions différentes après suppression.

Adresse inexistante (550/551) : le domaine existe mais la partie locale ne correspond à aucune boîte réelle. C'est le rebond dur le plus courant en produits grand public : erreurs de frappe à l'inscription, comptes fermés, adresses valides supprimées il y a six mois. Supprimez immédiatement. Il n'existe aucun chemin de récupération.

Domaine inexistant ou sans service de mail (550/553/554) : la résolution MX a échoué, ou le domaine refuse explicitement tout courrier entrant. Supprimez au niveau du domaine, pas uniquement l'adresse. Tous les autres contacts sur ce domaine sont également inatteignables ; une requête au niveau domaine surfaces bien plus vite que d'attendre que chacun rebondisse individuellement.

Bloqué définitivement par politique (550/5.7.1) : le serveur dispose d'une politique-blocage contre votre domaine ou IP d'envoi. Plus rare mais opérationnellement sérieux, car il affecte potentiellement une classe d'adresses dans une organisation complète. Croisez avec vos logs de réputation IP avant de décider si vous supprimez l'adresse déclenchante ou si vous escaladez auprès de votre équipe délivrabilité.

Une subtilité qui génère des bugs en production : certains MTA retournent des 4xx pour ce qui sont effectivement des conditions permanentes. Un domaine expiré et redirigé vers une page parking peut retourner 450 pendant des semaines en attendant la destruction progressive des enregistrements MX. Traitez comme candidate pour statut hard-bounce toute adresse retournant 4xx sur cinq tentatives consécutives en deux semaines, indépendamment du préfixe SMTP.

Quand les rebonds temporaires deviennent effectivement permanents

La frontière nette entre 4xx et 5xx s'efface en conditions de production réelle. Trois patterns doivent déclencher la logique de suppression identique à un hard bounce bien que le code reste en plage 4xx.

D'abord : rebonds répétés de boîte pleine sans engagement préalable. Si une adresse n'a jamais ouvert, cliqué, et rebondit 452 cinq fois en 30 jours, la boîte est quasi certainement abandonnée. Continuer les tentatives hausse votre taux de rebond sans perspective d'activation réaliste. Traitez comme dur.

Deuxièmement : greylisting persistant sans résolution. Le greylisting se résout au réessai pour les expéditeurs légitimes. Si la même adresse se défère systématiquement au-delà de 48 heures, vous êtes soit bloclisté soit vous envoyez à un spam trap. Aucune des deux justifie des tentatives additionnelles ; les cycles de réessai aggravent la casse réputationnelle.

Troisièmement : codes 4xx exclusifs à votre domaine d'envoi. Si d'autres expéditeurs joignent l'adresse avec succès mais vos envois se voient systématiquement différés, le problème est votre réputation expéditeur, non l'état de la boîte. Réessayer plus agressivement empirera.

Règle opérationnelle à encoder : après trois rebonds temporaires sans résolution, placez l'adresse en état de suppression probatoire. Arrêtez les emails de cycle de vie. Gardez-la éligible pour les emails transactionnels critiques (réinitialisation mot de passe, alerte facturation) jusqu'à confirmation de l'inatteignabilité.

Logique de suppression : retirer vs parquer vs réessayer

Tout événement de rebond ne justifie pas suppression intégrale de votre store de contacts. Le bon appel dépend du type et de l'historique d'engagement du contact.

Hard bounce 5xx (tout engagement préalable) -- Suppression immédiate, pas de réessai.

4xx, premier occurrence (engagement actif) -- Réessai selon calendrier, pas de suppression.

4xx, trois occurrences ou plus (sans engagement préalable) -- Suppression probatoire.

4xx, cinq occurrences ou plus (tout engagement) -- Traiter comme hard bounce.

4xx boîte pleine uniquement (LTV élevé ou transactionnel) -- Réessai hebdo pendant 30 jours.

La distinction entre « retirer » et « parquer » importe en pratique. Une adresse retirée tombe du store complètement. Une adresse parquée subsiste avec statut supprimé : vous pouvez encore la requêter, la surfer sur un dashboard de santé, et la réactiver si le contact s'inscrit à nouveau. Pour les flux transactionnels critiques, parking est le bon appel. Pour les listes de prospection froide, retrait est plus net.

Point opérationnel : quelle que soit l'action, enregistrez-la avec le code SMTP et le timestamp comme motif de suppression. Événements de suppression sans motif explicite sont quasi impossibles à auditer plus tard quand vous voulez comprendre pourquoi une cohorte s'est noircie entre deux campagnes.

Seuils de taux de rebond qui modifient le comportement ISP

Le chiffre de 2 % de taux de rebond qui circule comme norme industrie est un plancher, non une cible. Les seuils qui comptent sont plus granulaires.

Gmail et Outlook communiquent les taux de spam par expéditeur via Google Postmaster Tools et Microsoft SNDS respectivement. Ces dashboards n'exposent pas directement votre taux de rebond, mais les deux signaux sont fortement corrélés. Un taux de rebond soutenu au-delà de 2 % précède quasi invariablement une montée du taux de spam placement visible dans ces outils, typiquement avec un décalage de 3 à 5 jours.

Seuils pratiques à monitorer par domaine d'envoi :

• Sous 0,5 % : plage normale. Aucune action corrective requise.

• 0,5 à 1,5 % : surveillance étroite. Investiguer les motifs de rebond par segment ; typiquement quelques cohortes avec qualité de donnée dégradée.

• 1,5 à 2,5 % : pause la campagne et investigate avant reprise. La plupart des ESP commencent un rate-limiting automatisé dans cette plage.

• Au-delà de 2,5 % : arrête l'envoi. Nettoie les segments avant redémarrage. À ce niveau, certains ISP filtrent déjà les messages vers spam ou reportent les connexions à la passerelle.

Détail opérationnel souvent oublié : les taux de rebond se calculent contre les tentatives de livraison, non la taille totale de la liste. Si vous segmentez lourdement et envoyez uniquement aux abonnés engagés, votre décompte absolu baisse mais le taux calculé peut ne pas varier proportionnellement. Tracez nombre absolu et taux par envoi. Les pics de nombre absolu sont souvent le signal d'alerte plus précoce, en particulier après import de liste ou campagne de ré-engagement.

Lecture des signaux de rebond dans votre trace de livraison

Les événements de rebond doivent apparaître dans votre trace de livraison avec la même finesse que les opens et les clics. S'ils n'y figurent pas, votre observabilité a une brèche.

Minimum requis : chaque événement rebond enregistre timestamp, code réponse SMTP, message diagnostique complet du serveur distant, IP d'envoi, domaine receveur, et ID du contact. Le domaine receveur est fréquemment omis et fréquemment nécessaire. Quand un domaine commence à retourner 550 5.7.1 sur plusieurs contacts, vous voulez détecter ce pattern au niveau domaine avant qu'il n'endommage votre score de réputation sur le domaine d'envoi complet.

Avec ces données modélisées correctement, trois vues couvrent la plupart des besoins de monitoring rebond : un taux de rebond quotidien par domaine d'envoi, un taux de conversion soft-to-hard par cohorte (combien des rebonds 4xx d'aujourd'hui rebondissent toujours en 10 jours), et une table de fréquence de rebond au niveau domaine pour capturer les suppressions organisationnelles avant qu'elles ne s'amplifient.

Le but n'est pas un taux de rebond zéro. Cela ne s'atteint pas sur une liste qui croît. Le but est un pipeline de traitement des rebonds qui classe avec précision à la première réponse SMTP, supprime au seuil correct, et surface les signaux révélant un problème systémique avant que celui-ci n'escalade en incident de délivrabilité.