Je vais partir d’une évidence que j’ai trop souvent vue ignorée : chaque bounce est un coût, immédiat et différé. Immédiat, parce que vous payez un volume d’envoi qui n’atterrira jamais. Différé, parce qu’un taux de rebonds élevé plombe votre réputation d’expéditeur, dégrade votre placement en boîte de réception, et finit par réduire vos revenus marketing.

Quand je prends un compte en main, je ne commence ni par l’objet, ni par la créa. J’ouvre les logs et je regarde les bounces : types, causes, domaines touchés, répartition par source d’acquisition. C’est le bilan de santé le plus honnête d’une stratégie emailing.

Ce guide est le pilier d’une série de cinq articles. Ici, je couvre la vue d’ensemble : comprendre ce qu’est un bounce, distinguer les catégories, lire les codes, mesurer l’impact business, connaître les seuils tolérés et les risques de blacklistage, puis installer des pratiques durables pour réduire les bounces à la source et dans le temps. Je renvoie, quand il est nécessaire de rentrer dans les détails, vers les autres volets de la série.

L’objectif est simple : vous donner un plan opérationnel complet que vous pouvez lancer dès aujourd’hui.


Pourquoi le bounce email est un problème majeur

Un bounce, c’est un échec de remise. Vu de loin, on pourrait croire que cela ne concerne « que » un message. En réalité, c’est un signal système que les filtres, les FAI et vos futurs destinataires traitent très sérieusement. Et c’est un problème de taille pour trois raisons :

  1. Hygiène de base
    Un hard bounce dit : « cette adresse n’existe pas ». Envoyer vers des adresses inexistantes, c’est indiquer que votre collecte est mal contrôlée ou que votre base est vieillie. Les FAI n’aiment pas les expéditeurs qui ne contrôlent pas leur hygiène.
  2. Risque de contagion
    Un pic de bounces entraîne du throttling (ralentissement), des soft bounces à répétition, puis du placement en spam. Vous perdez l’inbox, donc l’ouverture, donc le clic, donc le revenu. C’est une chaîne de pertes.
  3. Effet P&L
    Au-delà du « taux », c’est un enjeu financier. Un bounce rate qui passe de 0,8 % à 3 % sur un million d’envois mensuels se traduit, chez la plupart de mes clients, par des milliers d’euros de CA perdus, rien qu’à cause d’une baisse de l’exposition en boîte de réception.

Je le dis aux équipes dirigeantes comme aux marketers : les bounces sont un KPI business, pas un détail d’ESP.


Chiffres clés

Je donne ici des repères concrets (objectifs que je vise et que j’observe sur des comptes sains). Ce ne sont pas des dogmes, mais des indices utiles pour se situer.

  • Bounce total (hard + soft) : viser < 2 % en rythme de croisière. Dès que le total dépasse 2 % plusieurs campagnes de suite, je déclenche un plan d’hygiène (collecte + cadence + gabarit).
  • Hard bounce : viser < 1 %. Plus on s’éloigne de 0, plus on révèle un problème de collecte (typos, domaines invalides, adresses obsolètes) ou d’import (CRM « vieillissant »).
  • Soft bounce : surveiller par domaine. Un soft ponctuel n’est pas grave, mais une tendance persistante (4.7.0/throttling, 4.4.x/timeouts) impose d’étaler et de réduire la cadence pour le domaine concerné.
  • Spam rate (plaintes) : < 0,3 % absolu, objectif < 0,1 %. (Je le mentionne parce que bounces et plaintes voyagent ensemble : une base mal tenue rebondit et reçoit plus de plaintes.)

Impact type sur une campagne de 1 000 000 d’emails (ordre de grandeur à partir de chiffres réalistes que j’observe régulièrement) :

  • Passer de 3,5 % à 0,8 % de bounces → +9 points d’inbox rate → +20 k€ à +30 k€ de CA selon votre mix et vos taux de conversion (Je reviens sur les détails de ce calcul plus bas).

Autrement dit : gagner des points d’hygiène rapporte plus que d’augmenter la pression d’envoi.


BounceStrike est la solution pour réduire ses bounces

J’ai construit BounceStrike pour assainir la collecte et normaliser la lecture des bounces, parce que je passais trop de temps à construire des API custom pour chaque client. L’objectif était de faire l’API la plus performante et la plus simple à la fois, avec notamment :

  • Vérification en temps réel (API) : syntaxe, domaine, MX, typos courantes, jetables, adresses à risques.
  • Normalisation universelle des motifs SMTP : on transforme 550 5.1.1No such userunknown recipient en une erreur simple et actionnable (user_unknown = hard).
  • Cadence par domaine : blocage dynamiques si un FAI montre des signes de throttling.

Mais je ne vais pas en dire plus pour le moment, je reviens à la fin de ce guide sur les avantages à passer par BounceStrike.


Qu’est-ce qu’un bounce email ?

Définition

Un bounce est un message de non-remis. L’email n’est pas arrivé (ou pas accepté) par le serveur du destinataire. On distingue deux grandes familles :

  • Hard bounce : échec définitif (adresse inexistante, domaine invalide, politique ferme).
  • Soft bounce : échec temporaire (boîte pleine, serveur indisponible, throttling, message trop lourd, greylisting).

La nuance n’est pas superflue : elle dicte quoi faire (supprimer vs retenter) et quelles causes investiguer (collecte vs cadence/gabarit/infra).

Différences entre hard bounce et soft bounce

Je ne réécris pas l’article entier ici, j’y ai consacré un guide dédié : « Hard bounce vs Soft bounce ». Retenez simplement :

  • Hard = stop netanalyse de la source (collecte, import, partenaire), correction à la source.
  • Soft = retries limités avec backoffcadence par domaineallègement si le message est trop lourd, bascule en inactif si récurrence.

Les causes principales

Causes techniques

  • Problèmes d’infrastructure expéditeur : DNS instable, SPF/DKIM/DMARC mal alignés, PTR/HELO incohérents, TLS expiré. Symptômes : 4.4.x (timeouts), 5.7.x (policy/auth).
  • Message trop volumineux : pièces jointes lourdes, GIFs massifs, HTML gonflé → 5.3.4 (souvent) ou soft « message too large ».
  • Throttling / Rate limiting : envoi trop rapide vers un domaine → 4.7.0421, vagues de softs.
  • Greylisting : refus volontaire du premier essai par le serveur destinataire pour vérifier la persistance → softs qui passent au 2ᵉ essai.
  • Routage / réseau : 4.4.1 (timeout), 4.4.2 (connection), 5.4.1 (routing failed).

Causes liées à la qualité de la base

  • Adresses invalides : typos (gmial.com), domaines sans MX, syntaxe cassée.
  • Comptes fermés : turnover B2B, boîtes personnelles abandonnées.
  • Co-registration agressive / partenaires : leads « tièdes » ou non consentis, emails jetables, adresses role-based non souhaitées (info@, contact@) si votre politique l’exclut.
  • Absence de sunset policy : inactifs prolongés, bases historiques non entretenues.

Causes liées au contenu

  • Tracking « bruyant » : trop de redirections, URL raccourcies douteuses → suspicion spam/policy.
  • Ratio texte/images déséquilibré : lourd à scanner, plus fragile côté filtres.
  • URLs externes à mauvaise réputation : landing ou CDN mal notés.

Pour une revue actionnable et des « gestes barrière » par cause, vous pourrez en savoir plus dans un autre article de la série consacré aux causes les plus courantes de bounce email.


Lire et interpréter les codes SMTP

Les codes SMTP sont votre GPS. Vous n’avez pas besoin de tout mémoriser : il faut savoir les reconnaîtreles classer, et décider.

Exemples courants

  • 5.1.1 / 550 user unknown → Hard. Adresse inexistante. Action : suppression + traçage de la source.
  • 4.2.2 mailbox full → Soft par défaut. Action : retries (3–5), puis gel si récurrent.
  • 5.2.1 mailbox disabled → HardAction : suppression.
  • 4.7.0 try again later / throttled → SoftAction : réduire cadence pour ce domaine.
  • 5.3.4 message too big → Souvent hard (politique ferme). Action : alléger + test isolé (pas de retries en masse).
  • 5.7.1 not authorized / policy → Hard (politiques). Action : revoir auth/URLs/tracking.
  • 5.7.26 unauthenticated / DMARC/SPF/DKIM → Hard tant que non corrigé. Action : aligner SPF/DKIM/DMARC.

Pourquoi c’est important pour diagnostiquer

Parce qu’un 5.1.1 n’appelle pas la même réponse qu’un 4.7.0. Un mauvais diagnostic = une mauvaise réaction : réessayer un hard abîme votre réputation ; « purger » une base alors que vous êtes simplement throttled vous fait perdre du chiffre pour rien.

Retrouvez la grille complète, les familles de codes et une méthode de normalisation dans mon guide des codes SMTP liés aux bounces.


Impact sur la délivrabilité et le business

Perte de réputation, revenus et engagement

Un taux de bounces élevé est interprété par les FAI comme un indicateur d’expéditeur à risque. Vous perdez des points de réputation, vous ratez l’inbox, vos ouvertures chutent, vos clics suivent, et votre CA baisse. Je formalise l’impact ainsi :

Revenu = (Emails envoyés × (1 − Bounce rate) × Inbox rate) × Open rate × CTOR × Conv × Panier

Le bounce rate inverse la première parenthèse, mais il alimente aussi un plus faible Inbox rate, ce qui met une double pression sur la chaîne.

Je vous passe les calculs ici mais si vous aimez les cas chiffrés, rendez-vous sur cet article de la série consacré à l’impact des bounces les performances.

Taux de bounce et risque de blacklistage

Plus vos bounces montent (surtout les hard), plus vous risquez les plaintes et les politiques de rejet, et vous finissez par toucher des listes noires (Spamhaus, Barracuda, SpamCop…). Ce n’est pas « un bannissement internet », mais pour certains business, c’est un mur.

Les seuils pratiques que j’utilise comme garde-fous : bounce total < 2 %hard < 1 %plaintes < 0,3 % (objectif < 0,1 %). Au-dessus, je change le rythme d’envoi, je nettoie, je durcis la collecte.

Pour comprendre le processus de listing/delisting, les différences entre SBL/DBL/BRBL et les plans de sortie, jetez un oeil à cet autre article : comment éviter le blacklistage de vos emails.


Comment réduire durablement les bounces

Vous pouvez faire baisser un bounce rate en une semaine en coupant large. L’enjeu, c’est de tenir durablement sans sacrifier la croissance. Ma méthode tient en trois axes complémentaires : pré-envoinettoyage réguliervérification en temps réel à la collecte.

1. Vérification d’emails pré-envoi (pré-vérification par lots)

Objectif : empêcher l’entrée en campagne d’adresses qui rebondiront à coup sûr (hard) ou très probablement (risque fort). On gagne immédiatement des points de réputation et de placement.

Quand :

  • Avant un gros import CRM ou partenaire.
  • Avant de relancer un segment dormants (> 12–18 mois).
  • En routine mensuelle ou trimestrielle sur les segments à fort volume.

Comment :

  1. Export CSV de l’univers à envoyer (id_contact, email, source, date_collecte, dernier_open, dernier_click).
  2. Passage dans un moteur de vérification (syntaxe, domaine, MX, jetables, catch-all, score de risque).
  3. Restitution enrichie : status (valid/risqué/invalide), reason (user_unknown, domain_not_found…), advice (send, confirm, exclude).
  4. Split des destinataires :
    • Valid → envoi normal.
    • Risque → soit parcours de confirmation (double opt-in, friction légère), soit envoi limité (cadence réduite + contenu léger) selon votre modèle.
    • Invalide → exclusion/suppression.

Mon expérience :
Un e-commerçant relançait 420 k adresses dormantes « d’un coup ». Pré-vérification : 7,8 % invalides, 12,4 % à risque. On a sorti les invalides, mis les « risques » dans un parcours de confirmation. Résultat : bounce total < 1,1 % (au lieu d’un carnage à > 5 %), et un inbox rate en hausse de 8 points sur la campagne suivante.

Bonnes pratiques :

  • Zéro pièces jointes sur la première relance (gabarit léger).
  • Cadence par domaine (étalement) si vous réactivez un gros volume.
  • Tracking simple (éviter les chaînes de redirection) pour ne pas ajouter un obstacle.

2. Nettoyage régulier (hygiène continue)

Objectif : ne pas « laisser vieillir » la base jusqu’au prochain grand ménage. Mieux vaut un peu, souvent qu’un grand nettoyage punitif.

Rythme :

  • Trimestriel minimum pour la plupart des verticales B2C.
  • Semestriel possible en B2B si la collecte est stricte et le cycle plus lent.

Méthode :

  • Revalidation des segments dormants (ex. > 12 mois sans ouverture).
  • Sunset policy : retrait progressif des inactifs ; on baisse la pression, on tente une campagne de réactivation ciblée (contenu très utile, incitation claire), puis on retire.
  • Suppression automatique post-hard : une adresse hard bouncée sort immédiatement (hors rares exceptions documentées).

Tableau de bord utile :

  • Bounce (total/hard/soft) par domaine et par source d’acquisition.
  • Part d’inactifs prolongés.
  • CA/1000 inboxés (pour relier hygiène et revenu, et justifier les choix).

3. Intégration API en temps réel (à la source de collecte)

Objectif : bloquer en amont les adresses qui deviendraient des hard demain, corriger les typos au moment de la saisie, et freiner les bots et emails jetables.

Où l’intégrer :

  • Formulaires d’inscription, de téléchargement de livre blanc, de compte client, de commande, de support.
  • Flux partenaires (leadgen) : imposer la vérification à la source, côté partenaire, avant l’ingestion.

Ce que je contrôle en temps réel :

  • Syntaxe (RFC) + domaines + MX.
  • Typos courantes (gmail/gmial, outlook/outlok) avec suggestion « Voulez-vous dire… ? ».
  • Jetables et domaines temporaires.
  • Role-based si votre politique les limite (info@, sales@).
  • Score de risque (catch-all, patterns suspects), avec seuils d’acceptation/confirmation/refus.

Exemple de logique :

scssCopierModifier
if not isValidSyntax(email): reject("Adresse invalide")
elif not hasMX(email.domain): suggestFixOrReject()
elif isDisposable(email.domain): askAltEmailOrReject()
elif isRoleBased(email) and policy.blockRoleBased: sendDOIOrReject()
elif riskScore >= threshold_confirm: requireDoubleOptIn()
else: accept()

Résultat type : Sur un site média, l’API a bloqué ~2,6 % d’adresses invalides/jettables à la source. Trois mois plus tard, le hard rate des campagnes d’acquisition a été divisé par 4, et l’inbox rate a gagné 6–9 points selon les FAI.


(Bonus) Orchestration et décisions :

Réduire les bounces n’est pas qu’un tri à l’entrée. C’est aussi bien réagir quand un rebond arrive. Deux éléments clés :

Normaliser les motifs :

Chaque ESP a sa poésie : « no such user », « user unknown », « unknown recipient ». Je mappe tout vers 15–25 motifs maison : user_unknown (hard), domain_not_found (hard), mailbox_full (soft), throttled (soft), message_too_large(hard par défaut), policy_block (hard), auth_failed (hard)…

Ça permet une règle par motif, pas 50 variantes floues.

Décider automatiquement :

  • Hard → suppression/quarantaine immédiate, traçage de la source, correction à la source.
  • Soft → retries (3–5, backoff 15 min → 1 h → 4 h → 12 h → 24 h), cadence par domaine si throttle, allègementsi taille.
  • Bascule prudente sur 5.2.2 (mailbox full capitalisée) et 5.3.4 (taille) → test isolé après correctif, pas de ré-inondation.

Comprendre l’effet domino

Je regroupe ici la logique que je présente aux comités de direction, car c’est souvent là que se jouent les budgets et la discipline d’exécution.

  1. Bounces → réputation (IP + domaine) en baisse → throttling + softs.
  2. Throttling → délais de remise, expérience dégradée → plaintes qui montent → spam et blacklists possibles.
  3. Spam/inbox → open/clic en baisse → CA qui chute.
  4. Réaction saine : réduire bounces à la source, étaler la cadence par domaine, nettoyer en continu, et relier chaque point d’inbox à un  (CA/1000 inboxés).

Solutions durables pour maintenir la délivrabilité

Vous pouvez copier-coller cette section dans votre runbook :

1. Collecte (à la source)

  • Validation syntaxique + MX + typos (suggestion « voulez-vous dire… ?»).
  • Filtre jetables + honeypots + contrôle de vitesse d’inscription (anti-bots).
  • Double opt-in sur les flux à forte incitation (cadeaux, remises).
  • Clauses qualité partenaires (preuve d’opt-in, seuil d’invalides max).

2. Pré-vérification (lots)

  • Avant import/relance massifs : scoring valid/risqué/invalide.
  • Parcours de confirmation pour les « risqués » (ou cadence limitée).
  • Exclusion fermée des invalides (hard évités).

3. Orchestration par domaine

  • Plafonds et étalement spécifiques (gmail/outlook/yahoo…).
  • Backoff discipliné sur softs (3–5 tentatives max).
  • Allègement si message too large.

4. Gabarits et tracking

  • Zéro PJ en campagne, images compressées, HTML sobre, version texte propre.
  • Moins de redirections de tracking, pas de shorteners publics douteux.

5. Identité & Auth

  • SPF + DKIM alignés, DMARC publié.
  • PTR/HELO cohérents, TLS à jour, DNS surveillé.
  • Stabilité des domaines/IP (pas de ping-pong incessant).

6. Gouvernance des bounces

  • Normalisation des motifs (15–25 clés).
  • Règles codées : hard = stop ; soft = backoff ; bascule si récurrents.
  • Seuils d’alerte et d’auto-ajustement (cadence par domaine).

7. Mesure qui compte

  • KPIs par domaine et par source.
  • CA/1000 inboxés comme North Star (lie délivrabilité ↔ revenu).
  • Feedback Loops (Microsoft, Yahoo) branchées pour retirer les plaignants.

Mettre l’hygiène au cœur du flux avec BounceStrike

Pour industrialiser durablement votre stratégie emailing sans subir les bounces, j’ai créé BounceStrike. Chaque email entrant ou sortant passe automatiquement par les bons checkpoints, sans effort.

Au cœur du système : Predator™ v2, notre API de vérification alimentée par l’IA. Elle analyse plus de 100 points de contrôle (contre une trentaine pour les concurrents) pour détecter les adresses à risque avec une précision inégalée : syntaxe, domaine/MX, adresses jetables, role-based, patterns suspects, historique de délivrabilité…

En pratique :

  • Vérification en temps réel sur vos formulaires pour bloquer les mauvais emails avant qu’ils ne rentrent.
  • Analyse batch de vos listes pour nettoyer vos envois avant expédition.
  • Rapports clairs avec recommandations exploitables immédiatement.

L’objectif est simple : mettre l’hygiène au cœur de votre pipeline et protéger votre délivrabilité, tout en maximisant vos revenus par email inboxé.


Comprendre et réduire les bounces n’est pas un « sujet d’expert ». C’est un levier de performance qui se joue sur des gestes simples, répétés : valider à la source, vérifier avant envoi, nettoyer en continu, orchestrer par domaine, alléger les messages, stabiliser l’identité, normaliser la lecture des bounces et automatiser les décisions évidentes. Faites-le, et vous verrez vos KPI se réaligner dans l’ordre logique : moins de bounces → meilleure réputation → plus d’inbox → plus d’ouvertures/clics → plus de revenu, à pression d’envoi constante.

Utilisez ce guide comme runbook pour les trois prochains mois. Et si vous voulez accélérer la mise en place, BounceStrike Pipeline Kit est là pour transformer ce plan en pipeline, avec des garde-fous techniques, des décisions codifiées et un tableau qui parle la seule langue qui compte au final : l’impact business.