Je l’ai appris parfois dans la douleur : le bounce est souvent le premier domino d’une catastrophe de délivrabilité. Quand vos hard bounces montent et que les softs s’accumulent, les FAI (Gmail, Outlook, Yahoo…) et les systèmes anti-spam commencent à vous regarder de travers. La suite est prévisible : ralentissements, rejets, hausse des plaintes, et, dans le pire des cas, listing sur une ou plusieurs listes noires (blacklists).

Ce billet est volontairement focalisé sur le lien entre un taux de bounce élevé et le blacklistage, avec une approche très opérationnelle : comment les FAI détectent les « mauvais » expéditeurs, quels seuils on peut considérer comme acceptables, comment fonctionnent les principales blacklists (Spamhaus, Barracuda, SpamCop…), ce qui se passe quand on y est, comment en sortir pas à pas, et surtout comment prévenir (réduire les bounces avant envoi).

Je ne reviens pas sur les codes SMTP, qui sont déjà traités dans un autre article, n’hésitez pas à vous mettre à jour avant d’attaquer celui-ci.

Comment les FAI détectent les mauvais expéditeurs

Je résume la logique comme je l’explique à mes clients : les boîtes de réception scorent votre réputation d’après un faisceau d’indices. Un taux de hard bounces élevé en fait partie, au même titre que :

  • Taux de plaintes (utilisateurs qui cliquent « spam »). Chez Gmail et Yahoo, rester < 0,3 % est devenu une exigence publique pour les expéditeurs volumétriques ; en pratique je vise < 0,1 % pour garder de la marge.
  • Présence sur des blacklists externes (IP ou nom de domaine) : par exemple les listes Spamhaus (SBL / XBL / PBL / DBL) ou la BRBL de Barracuda. Ces listes sont consultées en temps réel via DNS (DNSBL) pendant la transaction SMTP.
  • Erreurs techniques récurrentes (authentification, DNS, TLS) et patterns de cadence (pics soudains, débit trop agressif par domaine) détectés côté FAI.
  • Engagement : ouvertures, clics, réponses, « placement en boîte de réception » manuel par l’utilisateur.
  • Spamtraps : adresses pièges disséminées pour détecter les envois sans permission ; en toucher est un très mauvais signal.
  • Feedback loops : Yahoo (CFL), Microsoft (JMRP + SNDS). Ces boucles renvoient (totalement ou partiellement) les plaintes pour vous permettre de retirer les mécontents.

Pourquoi les bounces pèsent-ils lourd ? Parce qu’ils racontent votre hygiène de base : collecte douteuse, listes anciennes, saisies erronées, absence de vérification… Si vous envoyez régulièrement vers des adresses qui n’existent pas ou des domaines invalides, c’est un marqueur de risque, et un raccourci vers le blacklistage.

Seuils de bounce tolérés

Aucun FAI sérieux ne publie un « seuil officiel » de bounces au-delà duquel vous êtes blacklisté. Mais il existe des repères de marché utiles pour se calibrer :

  • Total bounce (hard + soft) : visez < 2 % ; au-delà, je déclenche un plan d’hygiène immédiat. Plusieurs sources et études industrielles convergent autour de ce chiffre.
  • Hard bounces (adresses invalides, user unknown) : < 1 % en routine ; certains ESP tolèrent jusqu’à 5 % avant de parler de « risque » accru, mais j’essaie de rester nettement en dessous.
  • Soft bounces : je surveille la tendance par domaine. Un soft ponctuel n’est pas grave ; des softs récurrents (4.7.0 throttling, 4.4.1 timeout) imposent d’étaler et de réduire la cadence par domaine.

À côté de ça, le taux de spam (plaintes) est devenu non-négociable : < 0,3 % (seuil de tolérance Gmail/Yahoo) et, dans mes modèles, objectif < 0,1 %. Une hausse des bounces nourrit souvent les plaintes, car l’hygiène de liste et la pertinence vont de pair.

Fonctionnement des listes noires (Spamhaus, Barracuda…)

DNSBL 101

Les DNS-based blocklists (DNSBL) sont des zones DNS consultées par les serveurs de messagerie pendant la réception. On interroge la liste avec l’IP (ou le domaine) de l’expéditeur ; si c’est listé, le serveur bloque ou score plus sévèrement. Deux grandes familles :

  • Listes IP : IP expéditrices repérées pour spam ou mauvais comportement (SBL, XBL, CSS chez Spamhaus ; BRBL chez Barracuda ; SCBL chez SpamCop).
  • Listes domaines/URLs : domaines présents dans le contenu ou utilisés comme expéditeurs, associés à des campagnes nuisibles (DBL chez Spamhaus).

Spamhaus (référence majeure)

  • SBL (Spamhaus Blocklist) : IP sources de spam ou d’abus structurés ; listing très impactant. La sortie nécessite d’avoir corrigé la cause et implique souvent votre opérateur réseau/ISP.
  • XBL / CSS : IP compromise (malware) et sources combinées de spam ; souvent corrélées à une infection ou à un mauvais usage d’infra.
  • PBL (Policy Blocklist) : plages IP qui ne doivent pas envoyer en direct (ex : accès résidentiels). Être sur PBL n’est pas une « sanction » ; cela impose d’envoyer via relais authentifié.
  • DBL (Domain Blocklist) : domaines à mauvaise réputation (URI dans vos emails, domaines d’envoi). Très utilisé en complément des listes IP.
  • ZEN : agrégat des listes IP (SBL+XBL+PBL+CSS) pour simplifier les requêtes côté serveurs.

Barracuda (BRBL)

La BRBL est une liste IP maintenue par Barracuda Central. L’inscription/désinscription est en grande partie automatisée, et il existe un formulaire de demande de retrait (utilisé par beaucoup d’équipes IT).

SpamCop (SCBL)

La SCBL (SpamCop) liste des IP signalées par ses utilisateurs ; la désinscription est automatique après un délai (si les signalements cessent). Utile à surveiller pour détecter des fuites de collecte ou des compromissions.

S’il fallait retenir une chose : les listes ne se valent pas toutes. Spamhaus est très influente ; un SBL/DBL se répercute chez de nombreux destinataires. BRBL peut surtout gêner en B2B (appliances), SCBL est souvent transitoire. Les FAI combinent leurs propres signaux (plaintes, engagement, auth) avec ces listes tierces.

Conséquences d’un blacklistage (testé et approuvé…)

Quand un client tombe sur SBL/DBL, le film est toujours le même :

  1. Chute brutale de la délivrabilité sur certains domaines : rejets 550/554 dès RCPT TO ou DATA.
  2. Réputation dégradée : même les domaines qui ne consultent pas la blacklist « fautive » détectent l’anomalie via l’augmentation des rejets et des plaintes.
  3. Effet d’entraînement : plus vous forcez, plus vous accumulez de signaux négatifs (softs 4.7.0, plaintes), ce qui élargit le problème.
  4. Impact business immédiat : campagnes suspendues, emails transactionnels en retard si l’infra est partagée, équipes commerciales à court de leads, support saturé.

Cas vécu, un lundi matin évidement : un SaaS B2B listé sur DBL à cause d’un domaine de tracking partagé avec un partenaire douteux. En 48 h : -60 % d’ouvertures sur Yahoo/Outlook, hausse de 5.7.1 « policy ». La remédiation (détails plus bas) a permis un retour à la normale en une semaine, mais la semaine a coûté plus cher que 6 mois d’hygiène préventive car pendant ce temps les inscriptions étaient bloquées par la confirmation d’email…

Plan opérationnel pour sortir d’une blacklist

La règle d’or : corriger la cause avant de demander la sortie. Une demande précipitée = risque de relisting.

1. Identifier précisément la liste et la cause

  • Utiliser l’outil de reputation check de Spamhaus (IP & Domain Reputation Checker) ou les pages de lookup des autres listes.
  • Lire le ticket/libellé : SBL (abuse structuré), DBL (domaine associé à spam/phishing), PBL (politique), BRBL (IP suspecte)…

2. Corriger en profondeur

  • Si SBL/CSS/XBL (IP) : vérifier authentifications (SPF/DKIM/DMARC), logs, absence d’envoi non autorisé, malware, open relay, snowshoe. Une IP compromise = nettoyage + preuves.
  • Si PBL : sortir du direct-to-MX et passer par un relai authentifié ; une IP d’accès résidentiel n’a pas vocation à envoyer directement.
  • Si DBL (domaine) : retirer/rediriger les liens problématiques, assainir la collecte (pas de co-registration sauvage), isoler un domaine de tracking sain.
  • Si BRBL : vérifier les flux, retirer les segments douteux, corriger les erreurs techniques (rDNS, HELO, TLS) avant de solliciter le formulaire.

3. Demander le retrait selon la procédure

  • Spamhaus SBL : l’opérateur réseau/ISP qui gère l’IP doit solliciter la levée (c’est écrit noir sur blanc). Fournir preuves et plan de prévention.
  • Spamhaus DBL : système de self-service si éligible ; sinon ticket avec justification et éléments probants.
  • SpamCop : arrêt des signalements ⇒ désinscription automatique en ~24 h.
  • Barracuda BRBL : formulaire dédié ; réponse souvent rapide si les preuves sont solides.

4. Pendant l’instruction : plan de continuité

  • Stopper les envois marketing vers les domaines les plus impactés ; prioriser les transactionnels sur une route saine (autre IP / autre domaine authentifié).
  • Segmenter fort : ne garder que les contacts récents et engagés.
  • Réduire la cadence par domaine ; étaler dans le temps pour éviter les 4.7.0.

5. Après la levée : reconquérir la réputation

  • Warm-up ciblé : volume graduel, d’abord sur très engagés, par domaine.
  • Surveillance quotidienne : Google Postmaster (spam rate, réputation IP/domaine), SNDS Microsoft, CFLYahoo/JMRP.

Mon astuce : documentez un « pack preuves » (screenshots de corrections DNS, journaux de nettoyage, détail des sources de collecte retirées, avant/après sur vos bounces et plaintes). Ça accélère les échanges et évite les relistings.

Prévention : réduire les bounces avant envoi

C’est ici que tout se joue. Ma « protection » anti-blacklistage tient en 9 leviers, tous mesurables :

1. Validation à la source

  • Syntaxe + existence domaine + MX.
  • Suggestions de typos (gmail.com vs gmial.com).
  • Double opt-in quand la pression commerciale est forte.
  • En B2B, format d’adresse (prénom.nom@) : je corrige autant que possible avant stockage.

2. Vérification temps réel & nettoyage périodique

  • API de validation (sans ping actif) au moment de la saisie.
  • Nettoyage trimestriel des segments dormants, surtout si cycle de vente long.

3. Politiques hard/soft claires

  • Hard = suppression immédiate.
  • Soft = retries limités (backoff), bascule en inactif si répétition sur plusieurs campagnes.

4. Cadence par domaine

  • Étaler les envois, plafonner pour les FAI sensibles.
  • Réduire automatiquement quand les softs 4.7.0 montent.

5. Gabarits allégés

  • Pas de pièces jointes lourdes ; images compressées ; HTML sobre.
  • Liens directs (éviter raccourcisseurs publics douteux).

6. Authentification & alignement

  • SPF + DKIM obligatoires, DMARC publié et aligné (exigence explicite chez Gmail/Yahoo depuis 2024 pour gros émetteurs).

7. Surveillance postmaster

  • Google Postmaster Tools (spam rate < 0,3 % ; viser < 0,1 %).
  • SNDS/JMRP (Microsoft) ; CFL (Yahoo) : retirer rapidement les plaignants.

8. Sécurité & infrastructure

  • rDNS/PTR cohérent, HELO propre, TLS à jour, pas de fuite d’IP résidentielles (PBL).

9. Maitrise des sources

  • Clauses qualité sur les partenaires (preuve d’opt-in, taux d’invalides max).
  • Quarantaine des imports : test sur échantillon avant envoi de masse.

Un jour, un e-commerçant international était listé BRBL + softs à la chaîne sur Yahoo/Outlook. On a cassé le flux en deux (transactionnel vs marketing), réduit la cadence par domaine, nettoyé 1,8 % d’adresses douteuses via la vérif en temps réel, corrigé un SPF incomplet. Résultat : delist BRBL en 24 h, retour de la réputation Gmail en « Low → Medium » en 72 h, puis « High » en 10 jours, sans perdre les emails critiques.

Ce que je surveille en continu

Vous pouvez rapidement mettre en place un tableau de bord minimal avec :

  • Bounce total, hard, soft (par domaine et source d’acquisition).
  • Spam rate Gmail (Postmaster) + plaintes via JMRP/CFL.
  • Réputation IP/domaine (Postmaster, SNDS).
  • Listings (Spamhaus IP/Domain checker, Barracuda lookup, SpamCop).

Ma checklist pour une sortie de crise (presque) sans stress

  1. Stopper l’envoi massif sur les domaines impactés.
  2. Identifier la liste (SBL/DBL/BRBL/SCBL) + récupérer le texte/numéro de ticket.
  3. Corriger la cause (collecte, lien, IP compromise, PBL/direct-to-MX…) avec preuves.
  4. Demander le retrait via la procédure officielle (SBL via ISP ; DBL self-service/ ticket ; BRBL formulaire ; SCBL attente/assainissement).
  5. Isoler les transactionnels sur route propre ; réchauffer progressivement après délistage.
  6. Installer les garde-fous pour ne pas y retourner (validation à la source, cadence par domaine, monitoring Postmaster/SNDS/CFL).

BounceStrike peut vous aider à ne jamais vivre un blacklistage

Je voulais une solution différente des concurrents : pas un outil « magique », mais un outil français vraiment performant et abordable. L’une des principales force de BounceStrike est la multitude des blacklists qui sont surveillées quotidiennement. Nous sommes les seuls à intégrer dans notre algorithme toutes les blacklists, même celles des FAI français comme Orange par exemple.

Si vous avez un lancement critique à venir ou si vos bounces flirtent déjà avec la zone rouge, vous pouvez tester sur votre prochain envoi pilote (ex : 50 000 adresses sur 3 FAI majeurs) en utilisant l’API.

Un taux de bounce élevé n’est pas qu’un problème d’esthétique de KPI. C’est un signal d’alerte que les FAI et les blocklists interprètent à juste titre comme un risque pour leurs utilisateurs. La bonne nouvelle, c’est que le chemin pour éviter le blacklistage est parfaitement actionnable :

  1. Mesurer proprement (par domaine, par source)
  2. Réduire les bounces avant envoi (validation, vérification, cadence)
  3. Surveiller la réputation et les plaintes (Postmaster/SNDS/CFL)
  4. Réagir avec méthode en cas de listing (corriger → prouver → demander la levée → réchauffer)

Chaque fois que j’ai appliqué ce cycle avec discipline, les bounces sont redevenus un non-sujet… et le mot « blacklist » n’est plus apparu que dans les runbooks. Si vous voulez que je vous accompagne sur une partie sensible, vous savez où me trouver.