Délivrabilité email : Comment optimiser la gestion des bounces ?

Restez informé.e via les newsletters de Badsender

Chaque mois, nous publions une newsletter sur l’email marketing et une infolettre sur la sobriété et le marketing. Pour avoir plus de détails sur le contenu et le rythme de nos communications, rendez-vous ici.

Votre adresse email servira uniquement à vous envoyer nos newsletters et nos invitations. JAMAIS ô grand jamais, nous ne la communiquerons à un tiers. Vous pourrez vous désabonner à tout moment en un seul clic.

Parmi les sujets de délivrabilité qui effraient le plus, la gestion des bounces pourrait faire partie du TOP10 (croyez-moi, j’ai déjà fait peur à quelques personnes en formation ou par téléphone :p).

En plus d’être un sujet technique, la gestion des bounces est plutôt négligée par les annonceurs alors qu’elle est de première importance, celle-ci pouvant amener des problématiques fortes de livraison si elle n’est pas gérée voir mal gérée.

Concrètement un bounce, qu’est-ce que c’est ?

Un bounce (ou rebondir en français) est un message légitime (normalement) émis par un serveur distant suite à la non délivrance d’un courriel vers son serveur de messagerie.

Pour faire simple, une notification va être envoyé à un expéditeur si celui-ci ne peut délivrer son email dans la messagerie électronique du destinataire.

Les bounces se classent en deux catégories : les hard et les soft.

Le hardbounce

Définition

Logiquement, dans le jargon technique, le hardbounce doit être considéré comme une erreur définitive, c’est-à-dire que l’erreur va perdurer dans le temps.

Quelques exemples de hardbounces :

  • Une adresse e-mail qui n’existe pas ou plus sur un domaine.
  • Un domaine qui n’existe pas ou plus.
  • Un serveur de messagerie qui n’existe pas ou plus.

Gestion d’un hard chez un routeur

Côté routeur e-mail, seule l’adresse e-mail qui n’existe pas ou plus est considéré comme un hardbounce, tout autre erreur définitive sera plutôt tagué comme du softbounce, tout simplement parce que vous n’êtes pas à l’abri qu’un serveur de messagerie soit temporairement tombé en panne et par conséquent renvoie des bounces de type hard.

Comment identifier un hard ?

La RFC 3463 indique qu’un code commençant par 5.xxx.xxx doit indiquer une erreur permanente.

5.XXX.XXX   Permanent Failure : A permanent failure is one which is not likely to be resolved by resending the message in the current form.  Some change to the message or the destination must be made for successful delivery.

Ainsi, en principe, si l’administrateur réseau a bien paramétré son serveur, tout code SMTP qui commence par 5.xxx.xxx devrait être tagué comme du hard. Malheureusement, il arrive que certains softbounces commencent par 5.

Comment bien gérer les hardbounces ?

Tout simplement, il suffit au premier impact de l’écarter définitivement de sa base de données et de le placer dans une blacklist spécifique à ce type de bounces. Les routeurs e-mails professionnels font ceci automatiquement.

Risques et impacts

Il est important d’écarter vos hardbounces au premier impact pour :

  • Maintenir une hygiène de base de donnée correcte
  • Préserver une bonne réputation
  • Éviter d’être considéré comme un spammeur (c’est une technique de spam !)

Si vous ne les gérez pas (ou pas correctement), les impacts sur votre réputation seront très forts, ceci pouvant amener un blocage temporaire ou un blacklistage total de tous vos envois, le tout pour une durée indéterminée.

Dernier point, il ne faut pas oublier qu’un spammeur va générer beaucoup de hardbounces, si vous êtes dans ce cas de figure là, votre marque pourrait être considérée comme telle !

Le softbounce

Définition

Un softbounce doit être considéré comme une erreur temporaire, c’est-à-dire que l’erreur devrait disparaître au fil du temps.

Besoin d'aide ?

Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.


Quelques exemples de softbounces :

  • Les boites pleines
  • Un blocage temporaire
  • Un serveur de messagerie en panne

Gestion d’un soft chez un routeur

Côté routeur e-mail, les softbounces sont catégorisés de différentes façons (ceci change d’un routeur à l’autre mais globalement, seuls les noms et le nombre de catégories changent, le principe de classification restant le même) :

  • Mailbox Full / Boites pleines : concerne les utilisateurs ayant atteint leur quota d’espace disque disponible
  • DNS Error / Erreur DNS : concerne les domaines qui ne répondent pas à la demande de connexion
  • Account disabled / Adresses désactivée : concerne les adresses désactivées par le FAI (dernière étape avant que l’adresse devienne un hardbounce ou un spamtrap).
  • Blocks / Filtrage Anti-Spam : concerne les blocages temporaires ou permanent (il se peut qu’un routeur considère le filtrage anti-spam en dehors d’un softbounce – et d’un hardbounce – et le considère comme un bounce à part).
  • General errors / Erreurs générales : en principe, c’est la catégorie fourre-tout, quand un softbounce n’est pas classé dans une des catégories ci-dessus, il sera placé ici jusqu’à sa qualification par l’équipe technique.

 Comment identifier un soft ?

La RFC 3463 indique qu’un code commençant par 4.xxx.xxx doit indiquer une erreur permanente.

4.XXX.XXX   Persistent Transient Failure : A persistent transient failure is one in which the message as sent is valid, but persistence of some temporary condition has caused abandonment or delay of attempts to send the message.If this code accompanies a delivery failure report, sending in the future may be successful.

Ainsi, en principe, si l’administrateur réseau a bien paramétré son serveur, tout code SMTP qui commence par 4.xxx.xxx devrait être tagué comme du soft.

Comment gérer les softbounces ?

Les routeurs, en principe, ne gèrent pas vraiment les softbounces, ce qui en soit ne pourrait pas poser puisque ce ne sont que des erreurs temporaires. Mais, certains softbounces peuvent générer des blocages s’ils deviennent trop récurrents et/ou trop fréquents.

Idéalement, en fonction de la catégorie du softbounce, il serait opportun d’appliquer des règles de gestion, c’est-à-dire les écarter après X échecs (à vous de voir comment vous souhaitez les gérer) et les placer dans une blacklist spécifique (en dehors de vos hardbounces/plaintes).

Risques et impacts

Comme je l’ai indiqué sur le point précédent, il est important d’appliquer des règles de gestion pour certains de vos softbounces, ceci pour plusieurs raisons :

  • Maintenir une hygiène de base de données
  • Préserver une bonne réputation
  • Éviter d’être considéré comme un spammeur (du fait que vous allez générer beaucoup d’erreurs sur le serveur distant)

Si vous ne les gérez pas (ou pas correctement), les impacts sur votre réputation pourront être forts, ceci pouvant amener un blocage temporaire (voir permanent) ou une mise en spam.

Quelles mécaniques à mettre en place

Tout d’abord, il ne faut oublier que vos bounces dégradent votre taux de délivrabilité et votre réputation. De ce fait, il est important pour vous de bien les gérer en mettant en place différentes mécaniques :

Mécanique au niveau de la collecte

Collecter en double-optin: ceci vous permettra de bien qualifier une adresse avant de l’injecter dans vos e-mails de masse. En bonus, vous récolterez le consentement de la personne et vous vous assurez également que c’est bien elle qui s’est inscrite à votre programme (et non un robot ou une personne malveillante).

Mécanique au niveau de votre base de données

Workflow de gestion des softbounces: le principe est de mettre en place des automatisations au sein de votre base afin d’écarter les softbounces au bout d’un certain nombre d’erreurs afin d’en améliorer l’hygiène. Votre réputation au final, n’en sera que meilleure.

Workflow de gestion des hardbounces (si vous n’utilisez pas un routeur professionnel) : écarter les erreurs de type hard au premier impact.

Conclusion :

La gestion des bounces n’est pas quelque chose d’insurmontable mais ceci demande du temps (cf. monitoring), une bonne compréhension des codes erreurs remontés et la mise en place d’une mécanique (bien huilée) pour les gérer.

Si vous avez des doutes ou que vous souhaitez mettre en place de telles mécaniques, n’hésitez pas à nous consulter 😉

Partagez
L’auteur

Une réponse

  1. « Comment identifier un soft ?
    La RFC 3463 indique qu’un code commençant par 4.xxx.xxx doit indiquer une erreur permanente. »
    Bah non, justement…

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *