Je vais être franc : on ne “règle” pas le problème des bounces, on le prévient et on l’entretient. Dans tous les comptes que j’ai repris, les chutes spectaculaires de hard/soft bounces n’ont jamais été dues à un grand nettoyage unique, mais à une routine.
Une routine en trois temps : avant la campagne, pendant l’envoi, après la campagne, qui installe une hygiène de longue durée. C’est cette cadence, plus que n’importe quel hack isolé, qui stabilise la réputation d’expéditeur, sécurise le placement en boîte de réception et, in fine, protège les revenus.
Cet article est le pilier d’une série consacrée à la vérification et à la gestion de base. Ici, je détaille quand et comment vérifier efficacement : la préparation, la surveillance en temps réel (monitoring), l’après campagne, la fréquence idéale et l’outillage (API, automatisations). J’y glisse ce que j’ai appris sur le terrain, avec des cas vécus.
Mon objectif est que vous repartiez avec un runbook complet, activable dès cette semaine, qui fera mécaniquement baisser vos bounces sans sacrifier la croissance.
Vérification avant une campagne
Avant une campagne importante, je passe systématiquement par une pré-vérification (preflight). C’est la ligne Maginot contre les hard bounces (adresses inexistantes, domaines invalides, boîtes désactivées) et une bonne partie des softs (boîte pleine chronique, throttling prévisible si on arrose un domaine trop vite, etc.).
Le périmètre à vérifier :
- Imports volumineux (CRM, partenaires, événements) : je ne lance jamais un envoi massif sans pré-vérification des adresses.
- Relances d’anciens segments (inactifs prolongés) : plus l’ancienneté est grande, plus le risque d’obsolescence augmente.
- Changements de setup (nouveau domaine d’envoi, nouvelle IP, migration ESP) : on minimise le risque en assainissant le socle.
Ce que j’évalue concrètement :
- Validité syntaxique (RFC) : évite les erreurs triviales.
- Domaine et MX : vérifie que le domaine est apte à recevoir du mail.
- Typos courantes :
gmial.com
,yaho.fr
, etc., avec suggestion de correction. - Jetables et “trash mails” : filtre les domaines temporaires.
- Role-based (info@, sales@…) selon politique : soit exclus, soit orientés vers un scénario à part.
- Catch-all et score de risque : un domaine qui accepte tout (catch-all) n’est pas forcément “bon” ; je le marque comme risqué, pas comme invalide.
- Historique local : l’adresse a-t-elle déjà hard-bouncé chez vous ? Si oui, elle ne revient pas.
La méthode (simple et efficace) :
- Exporter le segment avec des métadonnées utiles (source d’acquisition, date de collecte, dernier open/click).
- Vérifier en lot via un outil spécialisé (j’utilise BounceStrike forcément, mais n’importe quelle solution sérieuse fonctionne à condition qu’elle fournisse status + raison).
- Restituer en trois catégories actionnables : valide, risqué, invalide.
- Décider :
- Valide → envoi normal.
- Risqué → soit parcours de confirmation (double opt-in léger), soit cadence réduite + contenu sobre.
- Invalide → exclusion ferme.
Pour les volumétries : orchestrer par domaine
Le même volume n’a pas le même impact sur tous les FAI. Avant un gros shoot, je profile la répartition par domaine (gmail/outlook/yahoo + top domaines B2B de votre fichier). Puis j’applique un plafond d’envoi par domaine et un étalement temporel. Résultat : moins de 4.7.0
(throttling), moins de softs, et des courbes de remise plus régulières.
Mon expérience avec un client :
Un e-commerçant voulait relancer 600 000 contacts endormis. Pré-vérification : 9,1 % invalides et 13,7 % risqués. Au lieu d’envoyer en “plein pot”, on a :
- exclu les invalides,
- basculé les risqués dans un tunnel de reconfirmation,
- étalé l’envoi des valides sur 48 h par domaine.
Résultat : hard < 0,7 %, soft maîtrisés, et un Inbox Rate en hausse de 8 points la semaine suivante. Sans ce preflight, on aurait probablement cassé la réputation IP/domaine pour des semaines.
Vérification pendant l’envoi (monitoring en temps réel)
C’est le maillon le plus sous-estimé. Beaucoup d’équipes préparent très bien avant, mais pilotent à vue pendant. Or les bounces se lisent en direct, et c’est là que vous pouvez éviter l’emballement (files saturées, vagues de 4.7.0
, plaintes qui montent).
Les signaux à suivre en live :
- Flux d’événements SMTP/ESP : acceptations, temporisations, rejets par code (3 chiffres + Enhanced Status Codes).
- Bounces par domaine et par minute : si un domaine passe au rouge, on ralentit lui, pas toute la campagne.
- Latence de remise : quand la file d’attente s’allonge, c’est souvent un pré-signal de throttling.
- Taux de soft
4.7.0 / 421
: à partir d’un seuil (ex. > 2–3 % sur les 10 dernières minutes), je baisse la cadence pour ce domaine. - Erreurs de taille (
5.3.4
) ou boîte pleine (4.2.2
) : j’anticipe un envoi plus léger sur les prochains lots.
L’automatisation comme rempart décisionnel :
Je mets en place des règles automatiques (“si… alors…”) :
- Hard (
5.x.x
clairement “adresse/domaine”) → suppression immédiate de l’adresse cible, log de la source. - Soft (
4.x.x
) → backoff (ex. +15 min, +1 h, +4 h, +12 h, +24 h) avec un maximum de tentatives (3–5). - Throttling (
4.7.0
) → réduction dynamique de débit par domaine (pas globalement). - Message trop volumineux (
5.3.4
) → pause ciblée pour remplacer le gabarit lourd par une version allégée sur la suite du flux.
Orchestration opérationnelle :
- Queues par domaine : techniquement, je sépare les files de traitement par FAI. C’est la clé pour moduler sans punir tout le monde.
- Fenêtres d’envoi : certains domaines absorbent mieux à certaines heures. Si je vois qu’un FAI est “raide” le matin, j’étale plus l’après-midi.
- Priorisation transactionnelle : en période de tension (p. ex. gros lancement), je priorise les transactionnels sur une route plus propre, afin que l’activité critique ne pâtisse pas d’un marketing trop “bruyant”.
Un cas vécu ce mois-ci…
Une newsletter hebdomadaire voyait des pics de 4.7.0
chez deux FAI à chaque lundi 8h30. En mettant en place un monitoring minute et un débit plafond par domaine, plus une variante gabarit léger poussée automatiquement quand le taux de soft dépassait 2 % sur 10 minutes, on a ramené les softs 4.7.0
de 1,9 % à 0,3 %. L’équipe n’a pas “senti” la différence… mais la réputation, si.
Vérification après la campagne (nettoyage post-envoi)
L’après-campagne, c’est l’entretien. On transforme les signaux reçus en actions sur la base et en retours aux équipes.
Ce que je fais systématiquement :
- Normalisation des bounces
Les textes varient (“user unknown”, “no such user”…). Je mappe tout vers une dizaine de motifs standard (ex.user_unknown
,domain_not_found
,mailbox_full
,throttled
,message_too_large
,policy_block
,auth_failed
). Cette taxonomie évite de se perdre dans la jungle sémantique des messages d’erreur. - Décision automatique par motif
user_unknown
/domain_not_found
/mailbox_disabled
→ suppression immédiate (hard).mailbox_full
→ grâce (soft) avec réessais limités ; si récurrence sur plusieurs campagnes, bascule en inactif.throttled
→ ajustement des plafonds par domaine dans la configuration d’envoi.message_too_large
→ correction gabarit + test isolé, pas de relance massive.policy_block
/auth_failed
→ boucle vers l’infra (SPF/DKIM/DMARC, liens, tracking) avant tout nouvel envoi.
- Feedback par source d’acquisition
Je publie un mini-rapport “bounces par source” (site, partenaire, salon, import). C’est souvent là qu’émergent les fuites (un partenaire qui “pousse” des adresses jetables, un formulaire trop permissif). - Mises à jour de la base
- Statut suppression pour les hard.
- Statut à requalifier pour softs récurrents.
- Tagging risque pour les domaines catch-all détectés.
- Documentation & playbooks
Un incident = une page (cause, action, prevention). Ça évite de revivre le même épisode trois mois plus tard.
Heureusement, grâce à BounceStrike, vous évitez les étapes longues et fastidieuses de normalisation et de décision. C’est l’API qui s’occupe de tout.
Un autre cas que j’ai rencontré :
Après une campagne trimestrielle B2B, on voyait 0,6 % de user_unknown
concentrés sur des contacts venant d’un partenariat. Le rapport post-campagne a suffi à réviser le contrat : preuve d’opt-in obligatoire, vérification à la source côté partenaire. Le trimestre suivant, user_unknown
: 0,1 %.
Fréquence idéale de nettoyage
Il n’y a pas de dogme, mais il y a des cadences qui fonctionnent. Je conseille une approche hybride : un socle régulier, des accélérations en cas de signaux.
Mon cadre général :
- En continu (à la source) : vérification en temps réel sur tous les formulaires. C’est la meilleure dépense de prévention que vous puissiez faire.
- Avant chaque campagne volumétrique : preflight (lot) sur le segment ciblé, surtout si l’on rouvre des inactifs.
- Mensuel : mini-nettoyage sur les nouveaux contacts à faible engagement (ex. aucun open/click à 30 jours).
- Trimestriel : revalidation d’un échantillon des inactifs prolongés ; purge progressive via sunset policy.
- Ad hoc : dès qu’un indicateur passe au-dessus d’un seuil (ex. hard > 1 % sur 2–3 campagnes, soft
4.7.0
en hausse sur un domaine), je déclenche un nettoyage ciblé.
Les facteurs d’ajustement :
- B2C vs B2B : en B2C, les adresses personnelles “tournent” plus ; en B2B, le turnover (départs/arrivées) crée des hard plus “brutaux” après 6–12 mois.
- Canal d’acquisition : concours, promo agressive = cadence de nettoyage plus courte.
- Pays/FAI : certains environnements sont plus stricts ; je réduis l’intervalle si je vois des softs fréquents sur un FAI donné.
Outils et API pour automatiser
Je vais droit au but : sans API, la vérification reste artisanale. Avec l’API, elle devient un réflexe, invisible pour votre équipe.
Les briques techniques utiles :
- Validation front (formulaire)
- Syntaxe (regex robuste compatible RFC, pas les regex “jouets”).
- DNS/MX check (attention aux timeouts côté front : mieux vaut un service qui répond vite).
- Suggestions de typos (“gmail.com ?”).
- Honeypot + limites de vitesse pour bots.
- API de vérification en temps réel (serveur)
- Entrée :
email
, contexte (ip
,user_agent
,source
). - Sortie : status (
valid
|risky
|invalid
),reason
,risk_score
,advice
(accept
|confirm
|reject
). - Latence < 150 ms pour ne pas casser l’UX.
- Tolérance aux domaines catch-all (ne pas classer “invalid” par défaut ; préférer un score).
- Entrée :
- Batch preflight (avant envoi)
- Upload CSV → traitement distribué → CSV enrichi.
- Webhook de fin de job + rapport (taux par source/domaine).
- Webhook de bounces (pendant/après)
- Réception des événements (3 chiffres + Enhanced Codes).
- Mapping automatique vers la taxonomie.
- Règles (suppression hard, backoff soft, etc.) exécutées en ligne.
- Tableaux de bord
- Bounces par domaine et par source.
- Courbe
4.7.0
(throttling) minute par minute. - CA/1000 inboxés (pour parler “business”).
Quelques garde-fous :
- Respect des politiques de vérification : pas de ping agressif des serveurs sans considération. Préférez des méthodes non intrusives et/ou des prestataires qui gèrent proprement les dialogues SMTP.
- Rate limiting : ne saturez pas les vérifications (front/back).
- Logs détaillés mais sobres : on journalise le minimum utile (RGPD oblige), on pseudonymise quand c’est possible.
- Idempotence : traiter deux fois la même réponse ne doit pas casser l’état (ex. suppression déjà faite).
Le cas BounceStrike :
Sur un média qui recevait beaucoup d’inscriptions organiques, l’ajout de l’API en temps réel de BounceStrike (syntax+MX+typos+jetables) a bloqué 2–3 % d’adresses problématiques à la source. Six semaines plus tard, le hard rate sur les campagnes d’acquisition a été divisé par 3,8. Le tout sans charge de travail supplémentaire côté marketing.
Si vous souhaitez essayer : on peut démarrer par vos 2 formulaires principaux, brancher un Preflight sur votre prochaine campagne volumique, et activer le filtre pour que les bounces commencent à décider à votre place pendant l’envoi. L’idée n’est pas d’ajouter du dev ou des process ; c’est de déplacer le travail au bon moment (avant / pendant / après) et d’en automatiser 90 %.
La baisse durable des bounces n’est ni un coup d’éclat, ni un coup de chance. C’est un rythme : vérifier avant (preflight + à la source), surveiller pendant (monitoring + pare-chocs), nettoyer après (postflight + retour à la collecte), puis recommencer. C’est ce rythme, installé dans vos outils et vos rituels, qui vous sort des montagnes russes et vous offre une courbe de réputation stable, un Inbox Rate qui tient, et des revenus plus prévisibles.
Retenez trois gestes :
- Bloquer en amont (formulaires + preflight) tout ce qui deviendra un hard demain.
- Agir en direct (throttling par domaine, backoff intelligent) pour ne pas transformer un incident en crise.
- Apprendre après (normaliser les bounces, corriger la source, documenter) pour que l’incident n’arrive plus.
C’est exactement ce que je démocratise avec BounceStrike : un processus avant / pendant / après qui vous permet de faire le ménage sans difficulté, et qui se concrétise dans la seule métrique qui compte au final : plus d’emails livrés en boîte de réception, moins de coûts, plus de chiffre.