Je le répète souvent à mes clients : en emailing, un bon marketeur surveille ses ouvertures, un excellent marketeur surveille ses bounces. Parce que c’est là que se jouent vos coûts réels, votre réputation d’expéditeur et, in fine, vos revenus.
Dans la série d’articles que je consacre aux bounces, celui-ci est le plus “pratique” : j’y passe en revue les 10 causes les plus fréquentes que je rencontre dans les comptes que j’audite, avec à chaque fois ce que c’est, le type de bounce le plus probable (hard vs soft), ce que je fais pour éviter que ça arrive, et parfois un cas réel pour rendre les choses concrètes.
Je n’entre pas ici dans la jungle des codes SMTP, ni dans l’analyse détaillée des impacts de délivrabilité ou du blacklistage. L’objectif est simple : vous donner un diagnostic immédiat et des gestes barrières efficaces, sans détour.
1. Adresses invalides ou inexistantes (typos, user unknown)
Qu’est ce que c’est : des adresses qui n’existent pas ou plus : fautes de frappe (“gmial.com”, “yaho.fr”), caractères illégaux, ou boîtes supprimées. C’est la cause n°1 que je vois, surtout après des imports massifs.
Type de bounce : presque toujours hard (définitif).
Comment l’éviter :
- Je bloque les erreurs à la source : validation de la syntaxe, vérification de l’existence d’un MX côté domaine, détection de typos courantes (avec proposition de correction).
- Je privilégie un double opt-in quand c’est cohérent avec l’usage.
- J’ajoute une vérification temps réel avant d’insérer l’adresse en base (sans envoyer d’email test).
- Je surveille les imports CRM : un import “vintage” = nettoyage préalable obligatoire.
Cas réel : après une refonte de formulaire, un client a vu ses hard bounces chuter de 1,8 % à 0,4 % en 3 semaines, simplement grâce à la suggestion automatique “voulez-vous dire @gmail.com ?” et à un contrôle MX léger côté front.
2. Domaines inexistants ou mal orthographiés (NXDOMAIN / pas de MX)
Qu’est ce que c’est : l’adresse semble correcte, mais le domaine n’existe pas ou ne sait pas recevoir de mails (pas d’enregistrement MX). C’est la petite sœur du point 1, mais côté domaine plutôt que côté local-part.
Type de bounce : hard le plus souvent.
Comment l’éviter :
- Validation côté formulaire : DNS lookup du domaine et MX obligatoire.
- Liste de typos fréquentes sur les domaines (gmial, hotmial, outlok…).
- Blocage des domaines expirés connus (je maintiens une mini-liste interne mise à jour lors des audits).
- Pour les intégrations partenaires : je pose un contrat qualité sur les domaines fournis (taux max d’invalides, sinon retour à l’envoyeur).
Cas réel : une campagne B2B internationale explosait à 3 % de hard. En segmentant par domaine, 80 % des bounces venaient d’un seul pays où l’import comportait des domaines mal translittérés. Correction du mapping → retour sous 0,6 %.
3. Comptes fermés / Turnover B2B (user unknown, account disabled)
Qu’est ce que c’est : en B2B, le turnover crée des boîtes fermées. L’adresse était valide, elle ne l’est plus. En B2C, ça arrive aussi quand une boîte gratuite est abandonnée.
Type de bounce : hard.
Comment l’éviter :
- Hygiène trimestrielle : je repasse un coup de vérif sur les segments inactifs ou dormants.
- Pour les cycles longs (nurturing à 6-12 mois), j’insère une étape de réactivation (mini-campagne ultra légère) avant les gros envois.
- Je surveille le taux de hard par source : s’il grimpe après un salon ou un partenariat, c’est souvent un lot “tiède” devenu froid.
- J’automatise la suppression immédiate post-hard pour ne pas réinsister.
Cas réel : une base B2B “prestige” (comités de direction) présentait 2,2 % de hard bounces. L’hygiène ciblée sur les contacts >18 mois sans ouverture a ramené le taux sous 0,8 % en un mois.
4. Boîte pleine (mailbox full)
Qu’est ce que c’est : le destinataire a saturé sa boîte. Rien de dramatique : c’est une condition temporaire.
Type de bounce : soft.
Comment l’éviter :
- Retries avec backoff (ex. 15 min → 1 h → 4 h → 12 h → 24 h), puis arrêt.
- Seuil de bascule : si la boîte reste pleine au fil de plusieurs campagnes, je désactive l’adresse.
- J’évite les pièces jointes lourdes (voir cause #6) qui aggravent ce problème.
- Je priorise les emails transactionnels sur la file en cas de ressources limitées.
Cas réel : une séquence d’onboarding SaaS voyait 0,9 % de soft “mailbox full”. En supprimant les pièces jointes et en hébergeant les guides en ligne, on a divisé le phénomène par 3.
5. Throttling / Rate limiting côté domaine destinataire
Qu’est ce que c’est : le serveur du destinataire ralentit ou limite la cadence d’arrivée. Vous envoyez trop vite, ou votre réputation ne justifie pas un débit élevé. C’est l’un des soft bounces les plus mal compris.
Type de bounce : soft (temporaire), mais qui peut s’envenimer si vous insistez.
Comment l’éviter :
- Warm-up progressif des nouveaux domaines/IP (je commence petit, j’augmente par paliers).
- Cadence par domaine : je plafonne les envois pour les gros FAI (gmail/outlook/yahoo) selon les réactions observées.
- J’étale les campagnes en fenêtres (plutôt que tout en 10 minutes).
- Je surveille le taux de soft par domaine : s’il monte, je baisse la cadence pour ce domaine uniquement.
Cas réel : un e-commerçant envoyait 400k emails en 7 minutes. Résultat : vagues de softs chez deux FAI majeurs. En étalant sur 2 h et en paramétrant un débit spécifique à ces FAI, le soft bounce est passé de 1,6 % à 0,2 %.
6. Message trop volumineux (pièces jointes, images, HTML lourd)
Qu’est ce que c’est : votre email dépasse les limites acceptées (poids total, pièces jointes trop grosses) ou il est “lourd” à traiter (HTML surchargé, gros GIFs).
Type de bounce : soft le plus souvent (“message too large”), parfois refus définitif selon politiques.
Comment l’éviter :
- Zéro pièce jointe sur les campagnes : j’héberge en ligne (PDF, vidéo) et je lie.
- Compression des images, pas d’animations énormes.
- Version texte propre et concise.
- Minification HTML de base (sans casser le design).
- Tests systématiques sur échantillon de domaines avant les gros envois.
Cas réel : une newsletter hebdo passait de 1,8 Mo à 420 Ko après optimisation (images + minification). Les softs “too large” ont disparu, et les temps de rendu ont été divisés par 2 sur mobile.
7. Greylisting (réessayer pour prouver sa légitimité)
Qu’est ce que c’est : certains serveurs appliquent un greylisting : ils rejettent temporairement un premier envoi venant d’un expéditeur inconnu, attendant un second essai pour s’assurer que vous êtes un vrai serveur.
Type de bounce : soft (par définition…).
Comment l’éviter :
- Implémenter des retries intelligents (backoff, nombre limité).
- Maintenir une identité stable : même domaine d’envoi, signatures cohérentes, PTR/HELO propres.
- Éviter les changements incessants d’IP ou de domaine qui vous remettent “inconnus” à chaque fois.
- Warm-up progressif sur les domaines sensibles.
Cas réel : sur un programme B2B, la mise en place d’un simple retry à +20 min puis +2 h a converti 70 % des greylistings en livraisons réussies, sans rien changer d’autre.
8. Blocages politiques et adresses “role-based” (policy rejection)
Qu’est ce que c’est : certains domaines appliquent des politiques strictes : rejets des adresses “role-based” (info@, sales@, support@), refus d’emails si l’authentification est douteuse, ou si l’expéditeur n’est pas autorisé. Ce n’est pas un jugement de votre contenu, c’est une règle “maison”.
Type de bounce : souvent hard (rejet ferme des role-based) ; parfois soft si la politique prévoit une seconde chance.
Comment l’éviter :
- Politique claire vis-à-vis des role-based : les autoriser ou non, selon votre modèle (je les mets souvent en risqueavec un traitement spécifique).
- Alignement SPF/DKIM/DMARC (je reste à haut niveau ici ; l’article “codes” détaillera).
- Utiliser un domaine d’envoi crédible et stable (pas de bricolage).
- Prévoir un opt-in explicite pour les adresses partagées (comités, génériques).
Cas réel : une base B2B contenait 15 % de role-based. En les isolant avec un contenu plus “institutionnel” et une cadence réduite, on a fait baisser les bounces associés de moitié tout en gardant un ROI positif sur ce segment.
9. Filtrage antispam agressif (contenu, URLs, réputation)
Qu’est ce que c’est : votre message est refusé parce qu’il ressemble à du spam : trop de liens de tracking, redirections en chaîne, mots/structures déclencheurs, liens pointant vers des domaines mal réputés. Ce n’est pas un simple placement en spam : c’est un rejet côté serveur.
Type de bounce : hard ou soft selon politique.
Comment l’éviter :
- Épurer le tracking : moins de redirections, pas d’URL raccourcies douteuses.
- Contenu sobre : ratio texte/images sain, pas de murs de liens.
- Cohérence expéditeur ↔ contenu ↔ landing (éviter les dissonances).
- Surveiller la réputation des domaines de destination (pages d’atterrissage, CDN, liens externes).
- Tester sur un panel de domaines avant d’arroser toute la base.
Cas réel : une campagne B2C voyait des rejets “policy spam”. Le coupable : un raccourcisseur d’URL public mal noté. En remplaçant par des liens directs (ou un shortener de confiance), l’erreur a disparu immédiatement.
10. Problèmes d’infrastructure côté expéditeur (DNS, TLS, identités)
Qu’est ce que c’est : des pannes ou incohérences chez vous : DNS qui flanche, signatures qui expirent, mauvaise résolution d’un enregistrement, reverse DNS absent, négociation TLS qui échoue. Vu de l’extérieur, ça ressemble à un expéditeur mal configuré.
Type de bounce : généralement soft (temporaire), mais certaines politiques peuvent passer en hard si l’incohérence est persistante.
Comment l’éviter :
- Surveillance simple (uptime DNS, validité des clés, résolution des enregistrements, latence SMTP).
- TTL adaptés (ni trop court, ni absurdes) et redondance DNS.
- PTR/HELO alignés, certificats TLS à jour.
- Procédures de rollback : si une modif casse la chaîne, je peux revenir en arrière vite.
Cas réel : un changement de DNS provider mal séquencé a créé un pic de soft bounces pendant 40 minutes. Alerte, rollback, puis re-déploiement propre en heures creuses : plus aucun incident depuis.
Bonus : la collecte “cracra” (partenaires, jeux concours, emails jetables)
Qu’est ce que c’est : j’ouvre un carton de leads “partenaires” et je trouve un mélange d’adresses jetables, de doublons, de role-based et d’emails obsolètes. Ce n’est pas une cause technique unique, mais un terrain qui favorise la plupart des causes 1 à 9.
Type de bounce : mix hard + soft.
Comment l’éviter :
- Contrat qualité avec les partenaires (taux d’invalides max, preuve d’opt-in, droit d’audit).
- Filtre jetables (domains list) + score de risque à l’ingestion.
- Honeypots et signaux anti-bot sur les jeux concours.
- Quarantaine des lots douteux : pas d’envoi massif avant validation.
Cas réel : sur un partenariat d’affiliation, 12 % des adresses étaient jetables. En imposant la vérification temps réel à la source, le partenaire a purgé en amont et nous avons divisé les hard bounces par 5.
Ma checklist “quoi faire tout de suite”
- Verrouiller la validation au formulaire (syntaxe + domaine + typos).
- Activer une vérification temps réel et scorer les adresses risquées.
- Mettre en place des retries limités et intelligents pour les softs.
- Supprimer automatiquement toute adresse en hard (zéro réessai).
- Limiter la cadence par domaine quand les softs montent.
- Alléger les gabarits (pas de pièces jointes lourdes, images optimisées).
- Surveiller l’infra (DNS, identités, TLS) avec alertes basiques.
- Segmenter vos imports (ne jamais envoyer “plein pot” sans test).
- Maintenir un tableau par domaine et par source d’acquisition.
- Documenter en interne qui fait quoi quand un pic de bounce arrive.
Récapitulatif des gestes barrières
| Cause | Type | Geste barrière |
|---|---|---|
| Adresses invalides / typos | Hard | Validation + double opt-in + vérif temps réel |
| Domaines inexistants / pas de MX | Hard | Contrôle MX + typos domaine |
| Comptes fermés / turnover | Hard | Hygiène trimestrielle + réactivation avant envoi |
| Boîte pleine | Soft | Retries + seuil de désactivation |
| Throttling / rate limiting | Soft | Warm-up + cadence par domaine + étalement |
| Message trop volumineux | Soft/Hard | Compression, liens, HTML sobre |
| Greylisting | Soft | Retries + identité stable |
| Blocages politiques / role-based | Hard/Soft | Politique role-based + authentifications alignées |
| Filtrage antispam (contenu / URLs) | Hard/Soft | Tracking épuré + domaines fiables |
| Pépins d’infra expéditeur | Soft/Hard | Monitoring DNS/TLS + PTR/HELO propres |
Les erreurs à éviter
- Relancer une adresse hard bouncée “au cas où” : vous abîmez votre réputation.
- Envoyer au même débit à tout le monde : adaptez par domaine.
- Empiler les redirections de tracking : simplifiez la chaîne.
- Changer d’IP/domaine tous les quatre matins : la stabilité paye.
- Importer sans tester : toujours un échantillon d’abord.
Comment je me sers de BounceStrike
Tout ce que je viens de décrire, je l’ai packagé pour le rendre simple à opérer au quotidien. C’est précisément le rôle de BounceStrike et de son moteur de vérification Predator™ v2 que j’utilise dans mes propres flux.
Concrètement, voilà ce que vous pouvez activer en quelques heures :
- Vérification en temps réel à la source (API/Widget) : on bloque les typos, les domaines sans MX, les adresses inexistantes et une grande partie des role-based si vous le souhaitez.
- Détection avancée des domaines “catch-all” : plutôt que de blacklister à l’aveugle, Predator™ v2 évalue le risque de délivrabilité, cas par cas.
- Nettoyage par lots pour vos imports : sortie enrichie avec statut (valide/invalide) et motif normalisé.
- Normalisation universelle des bounces : quels que soient vos ESPs, on mappe les retours vers une API unique (utile pour automatiser vos décisions hard/soft sans perdre de temps).
- Connecteurs API pour brancher vos CRM/ESP sans friction.
- Conformité européenne : traitement des données, hébergement et pratiques alignées.
Si vous voulez que je regarde votre stack et que je vous rende un plan d’action en 48 h (collecte, gabarits, cadence, infra), on peut démarrer sur un échantillon de votre base. Essayez BounceStrike sur vos 10 000 prochains emails : vous verrez exactement où naissent vos bounces et comment les neutraliser avant qu’ils n’existent.
Les bounces ne sont pas une fatalité. Dans 8 cas sur 10, la cause est prévisible et évitable avec des garde-fous simples : valider à la source, vérifier en temps réel, alléger les messages, cadencer par domaine, surveiller l’infra, et décider vite (hard = suppression, soft = retries limités). Ce qui fait la différence, c’est votre discipline et la clarté des signaux.
Alors si je peux vous donner un conseil : prenez ces 10 causes, faites un mini audit maison (par domaine, par source, par type de bounce), et corrigez une chose par semaine. En 1 à 2 mois, vous n’aurez plus du tout le même rapport aux bounces, ni les mêmes coûts. Et si vous voulez accélérer la trajectoire, vous savez ce qu’il reste à faire : BounceStrike.
