Taux de rebond email : comment le mesurer et quoi corriger
Résumé
Le taux de rebond email est la part des messages envoyés que le serveur destinataire a refusés. Gardez les rebonds durs sous 1 % sur une liste saine, enquêtez à 2 % et traitez 5 % comme un incident, car Amazon SES place les comptes à ce niveau sous examen. Découpez le taux par flux, par source et par domaine, et stockez le code SMTP pour distinguer une liste sale d'un problème de réputation.
Votre taux de rebond email correspond à la part des messages envoyés que le serveur destinataire a refusés, rapportée au nombre de messages envoyés. Gardez les rebonds durs sous 1 % sur une liste saine, considérez 2 % comme le seuil où il faut enquêter et 5 % comme un incident. La plupart des équipes lisent un seul chiffre global sur leur tableau de bord et passent à côté du fait que le dénominateur, le type de rebond et la fenêtre temporelle modifient la réponse.
La suite porte d'abord sur la manière d'obtenir le bon chiffre, puis sur ce qu'il faut corriger.
La formule est simple, c'est le dénominateur qui pose problème
Le taux de rebond se calcule ainsi : messages rebondis divisés par messages envoyés, multiplié par 100. Certains ESP divisent par les messages délivrés à la place, ce qui fait paraître le taux plus élevé, puisque les messages délivrés excluent déjà les rebonds. Vérifiez quel dénominateur votre fournisseur utilise avant de comparer le résultat à un seuil.
Amazon SES, par exemple, calcule son taux de rebond uniquement à partir des rebonds durs, rapportés aux messages envoyés via le compte. Ce détail compte : un tableau de bord qui mélange rebonds souples et rebonds durs affichera un chiffre plus élevé que celui que votre fournisseur utilise pour vous évaluer.
Choisissez une seule définition et notez-la à côté de la métrique, dans le titre du tableau de bord si besoin. Chez nous, on retient les rebonds durs rapportés aux envois, par domaine d'envoi, sur 24 heures et sur 7 jours. Si deux personnes de votre équipe citent des chiffres différents pour la même semaine, comparez d'abord le dénominateur.
Rebonds durs, rebonds souples et blocages : trois signaux différents
Un rebond dur est un échec permanent : l'adresse n'existe pas, le domaine ne résout pas, ou la boîte a été fermée. SMTP le signale par un code amélioré en 5.x.x, défini dans la RFC 3463.
Un rebond souple est un échec transitoire : boîte pleine, serveur indisponible, message trop volumineux. Ces refus reviennent avec des codes 4.x.x, et un expéditeur bien configuré les réessaie. Si vous voulez la classification complète, notre guide sur la différence entre rebond souple et rebond dur détaille la correspondance des codes SMTP.
La troisième catégorie est celle que les tableaux de bord masquent. Un blocage est un rejet en 5.x.x qui ne dit rien de l'adresse et tout de votre envoi : une IP sur liste noire, un échec d'authentification, un filtre de contenu ou de réputation. Compter un blocage comme un rebond dur fait paraître votre liste sale alors que le problème vient de votre configuration d'envoi.
Évitez les rapports qui affichent une seule ligne « rebonds ». Séparez-la en trois séries, sinon vous nettoierez une liste qui n'était pas le problème.
Quel taux de rebond email est acceptable en 2026 ?
Il n'existe pas de chiffre officiel unique, et c'est utile à savoir avant d'en citer un. Gmail et Yahoo publient des seuils pour les plaintes pour spam, pas pour les rebonds. Google demande aux expéditeurs en nombre de garder le taux de spam signalé dans Postmaster Tools sous 0.10 % et de ne jamais atteindre 0.30 %, selon sa FAQ sur les consignes pour expéditeurs.
Pour les rebonds, les repères viennent des ESP et de la pratique. Voici les seuils que nous utilisons comme niveaux d'alerte, et non comme garanties d'un fournisseur de boîtes mail. Taux de rebond dur par domaine sur 24 heures, et ce que nous en faisons :
Sous 0.5 % : normal pour une liste engagée et vérifiée.
De 0.5 % à 1 % : surveiller, et contrôler la source des nouvelles adresses.
De 1 % à 2 % : enquêter, et suspendre le segment au taux le plus élevé.
De 2 % à 5 % : arrêter les envois massifs sur ce flux et trouver l'import ou le formulaire en cause.
Au-delà de 5 % : incident. Amazon SES place les comptes à ce niveau sous examen.
La dernière ligne correspond à un seuil documenté. Dans sa documentation du tableau de bord de réputation, Amazon SES indique qu'un compte dont le taux de rebond atteint 5 % ou plus est placé sous examen, et que l'envoi peut être suspendu si le taux reste au-dessus de 10 %. Les autres fournisseurs retiennent des seuils différents, formulés autrement : relisez les conditions de votre propre contrat.
Segmenter d'abord : un taux global cache le flux qui échoue
Un taux global de 0.8 % peut cacher un flux transactionnel à 0.1 % et une importation de réengagement à 6 %. La moyenne paraît acceptable, mais le second flux abîme discrètement le domaine d'envoi.
Calculez le taux par flux, par source et par domaine destinataire. Quatre découpages détectent la plupart des problèmes :
Par flux. Transactionnel, cycle de vie et campagnes massives ne doivent jamais partager un même chiffre.
Par source d'inscription. Formulaires, inscriptions via API, imports CSV et listes partenaires n'ont pas du tout la même qualité d'adresses.
Par domaine destinataire. Un pic chez un seul fournisseur signale en général une politique de rejet, pas une liste sale.
Par ancienneté de l'adresse. Les adresses collectées il y a plus de 12 mois rebondissent plus souvent que les récentes.
Ce n'est pas un confort de reporting. C'est la différence entre corriger un bug de validation de formulaire en une heure et purger une liste saine dans la panique.
Un cinquième découpage est utile une fois les autres en place : par IP ou par domaine d'envoi. Si vous utilisez une IP dédiée pour le transactionnel et un pool partagé pour les campagnes, un pic sur l'un ou l'autre vous indique où regarder avant d'ouvrir le moindre journal.
Lire les événements de rebond sans en perdre
Tout ESP sérieux expose les rebonds sous forme d'événements : webhook, sujet de notification ou API d'événements. Traitez ce flux comme la source de vérité et écrivez-le dans votre propre stockage, car les tableaux de bord agrègent et perdent le détail dont vous aurez besoin plus tard.
Persistez ces champs pour chaque événement : identifiant du message, destinataire, type de rebond, code de statut amélioré, texte de diagnostic et horodatage. Avec ces six éléments, vous répondez à presque toutes les questions qui surgissent lors d'un post-mortem.
{
"event": "bounce",
"message_id": "msg_01H9",
"recipient": "user@example.com",
"bounce_type": "permanent",
"status": "5.1.1",
"diagnostic": "550 5.1.1 user unknown",
"stream": "lifecycle",
"ts": "2026-11-02T09:14:03Z"
}Rendez le gestionnaire idempotent, en l'indexant sur l'identifiant d'événement du fournisseur combiné à l'identifiant du message. Les fournisseurs rejouent les webhooks, et un événement de rebond dur dupliqué qui incrémente un compteur deux fois fausse votre taux et peut supprimer une adresse pourtant valable.
Postmark et Resend séparent tous deux les types de rebonds dans leurs événements et permettent de les extraire par flux de messages, ce qui rend le découpage par flux peu coûteux à construire.
La règle de suppression qui fait l'essentiel du travail
Le levier le plus efficace reste la suppression automatique. Après un seul rebond dur, arrêtez d'écrire à cette adresse, définitivement, au niveau de l'application plutôt que de vous fier seulement à la liste du fournisseur.
La plupart des ESP suppriment déjà les rebonds durs à votre place. L'écart apparaît quand vous changez de fournisseur, en faites tourner deux en parallèle, ou envoyez depuis un système qui ne lit jamais la liste de suppression. Une table à vous, indexée sur une adresse normalisée, comble cet écart.
Pour les rebonds souples, utilisez un compteur plutôt qu'un événement isolé. Notre valeur par défaut : suppression après trois rebonds souples consécutifs sur au moins sept jours. Une boîte pleine depuis une semaine est, pour le cycle de vie, une adresse perdue.
Ne supprimez pas les adresses rebondies de votre table d'utilisateurs. Marquez-les avec le code de statut et la date. Une ligne supprimée ne peut pas vous dire qu'une même adresse a rebondi deux fois le trimestre dernier. Vous avez besoin de cet historique pour éviter de réimporter la même adresse depuis le prochain CSV, c'est le moyen le plus courant de voir une liste « nettoyée » redevenir sale.
Pourquoi le taux monte brusquement : les causes, classées
Quand le taux bouge, cherchez la cause dans cet ordre. Les trois premières expliquent la plupart des pics.
Un nouvel import. Un CSV issu d'un événement, d'un partenaire ou d'un ancien export CRM. Vérifiez d'abord le taux par source.
Un formulaire d'inscription sans validation. Fautes de frappe comme gmial.com, domaines jetables. Une vérification de syntaxe et des enregistrements MX à la soumission élimine la plupart des cas, et un e-mail de confirmation retire le reste avant qu'il ne compte comme envoi dans un flux de cycle de vie.
Un changement d'envoi. Une nouvelle IP, un nouveau domaine, ou un réchauffement trop rapide qui se transforme en blocages plutôt qu'en rebonds durs.
Une rupture d'authentification. Alignement SPF, DKIM ou DMARC en échec après une modification DNS.
Une politique de rejet côté fournisseur. Un domaine destinataire a durci ses filtres. Votre taux monte pour ce seul domaine.
Le diagnostic passe par la répartition des codes de statut, groupée par flux et par domaine destinataire, sur la même fenêtre que le pic. Une hausse des 5.1.1 (utilisateur inconnu) pointe vers la liste. Une hausse des 5.7.x pointe vers la politique, l'authentification ou la réputation. Ces cas exigent des correctifs opposés, c'est pourquoi on stocke le code.
Ce sur quoi nous alerterions
Alerter sur une moyenne quotidienne arrive trop tard. Un mauvais import peut envoyer 40 000 messages en une heure. Alertez donc sur une fenêtre glissante :
un taux de rebond dur supérieur à 1 % sur les 1 000 derniers envois de n'importe quel flux ;
tout domaine destinataire au-dessus de 5 % sur au moins 200 envois en une heure ;
un nombre de blocages 5.7.x qui dépasse nettement votre niveau de référence.
Reliez les deux premières alertes à une mise en pause du flux concerné, pas à une astreinte humaine. Un humain peut enquêter ensuite. La pause protège votre réputation dans les dix prochaines minutes.
Exportez le taux vers la supervision que vous utilisez déjà, Grafana, Datadog ou un outil maison, et gardez l'étiquette du flux sur chaque série pour que le découpage survive à l'export.
Pour le reporting à la direction, utilisez le taux de rebond dur par flux sur une fenêtre de 7 jours, plus le nombre de blocages. Laissez les rebonds souples dans la vue ingénierie, où ils sont utiles, et hors de la vue direction, où ils créent de la confusion. Ne présentez jamais le chiffre global du compte seul, car il bouge pour des raisons que personne dans la salle ne peut expliquer.
Si l'on vous demande un seul chiffre, donnez le taux de rebond dur du flux transactionnel. C'est le flux où un échec coûte une réinitialisation de mot de passe ou une facture, et la lecture la plus nette de la santé de votre infrastructure.
La prochaine étape est simple : extrayez les événements de rebond des 30 derniers jours, groupez-les par flux et par code de statut, et repérez la ligne que vous n'attendiez pas.