Bounce, plainte et deferral : que faire avant que le spam gagne

Confondre un bounce, une plainte et un deferral dans vos journaux d'envoi conduit soit à détruire votre réputation sur des adresses mortes, soit à supprimer par erreur des contacts valides. La règle consiste à trier chaque code SMTP selon sa nature exacte : isolement immédiat pour les plaintes et bounces durs, réessais temporisés pour les deferrals. Mettez en place ces flux de suppression automatique dès la configuration technique, bien avant que vos messages ne finissent en boîte spam.

Trois signaux, trois incendies distincts

Un bounce dit que le message n’a pas été livré. Un complaint dit qu’il a été livré et que le destinataire l’a marqué indésirable. Un deferral dit que le système récepteur a demandé de réessayer plus tard. Confondre toute paire produit le mauvais correctif — réessayer un hard bounce brûle la réputation exactement comme ignorer un complaint.

Bounce : hard vs soft, et ce que les équipes confondent

Complaint (FBL) : le moyen le plus rapide de brûler un domaine

Un complaint signifie qu’un destinataire réel a dit à son fournisseur de boîte que votre message était indésirable. Les plaintes pèsent plus que les bounces car elles sont un jugement humain, pas une panne technique. Une adresse, un complaint, un suppress immédiat — pas de « voyons si ça se répète ».

Deferral : signal de throttling, pas un échec

Les deferrals demandent de ralentir ou de réessayer plus tard — souvent liés au débit, pas au contenu. Panic-suppress après un deferral gaspille une audience légitime. La bonne réponse est backoff et pacing, pas des purges de listes.

Séparez deferral et soft bounce : le deferral est souvent récupérable ; le soft entre en suppress quand les retries sont épuisés. La politique de rythme doit vivre dans des changements de config, pas des accords de minuit.

Construisez une table de triage que l’équipe utilise vraiment

Mettez codes bounce, sources de complaint et motifs de deferral sur une page avec owner et action par ligne. Si un nouveau code d’échec apparaît que personne ne reconnaît, routez-le vers un owner nommé avant que l’automatisation décide seule.

Commencer avec IOSOR

Extrayez une semaine d’événements bounce, complaint et deferral et triez-les en trois seaux avant de monter le volume. Confirmez que les hard bounce passent en suppress tout de suite et ne se relancent jamais. Confirmez que chaque plainte écrit un suppress permanent. Confirmez que les deferral se relancent avec backoff et ne comptent pas comme un échec dur. Nommez un owner pour les éditions de la liste de suppress.

• Second domaine e-mail : transfert sans mélanger la phase de chauffe
• authentification e-mail avant production
• Preuve de Flash-Call avant la connexion de production

À retenir — IOSOR

Bounce, plainte et deferral sont trois actions distinctes. Les mélanger remplit à la fois le dossier spam et le dossier plaintes.

Faites : mettez en suppress les hard bounce et les plaintes tout de suite ; relancez les deferral avec backoff. Ne faites pas : traiter un deferral comme un bounce ni continuer d’écrire après une plainte. Chaque envoi accepted est un débit prepaid au ledger.