← RFC Reference

Comprendre les rebonds d'email

Les rebonds stricts, les rebonds souples, le format DSN, les codes d'état améliorés — et comment les gérer par programme sans détruire votre réputation d'expéditeur.

Deux façons dont les rebonds se produisent

La livraison d'e-mails peut échouer à deux points distincts, et le mécanisme diffère pour chacun :

Rejet synchrone (pendant la session SMTP)

Le serveur récepteur rejette le message en temps réel, lors de la conversation SMTP. Vous obtenez l'erreur immédiatement en tant que code de réponse SMTP :

C'est le type de rebond le plus propre. Votre serveur d'envoi sait immédiatement que la livraison a échoué et peut agir en conséquence.

Rebond asynchrone (DSN après acceptation)

Le serveur récepteur accepte le message (250 OK à DATA), mais découvre plus tard qu'il ne peut pas le livrer — la boîte aux lettres a dépassé son quota, le filtrage de contenu l'a rejeté, ou un relais interne a échoué. Le serveur génère une Notification d'état de livraison (DSN) et l'envoie à l'expéditeur de l'enveloppe (adresse MAIL FROM).

C'est pourquoi l'adresse MAIL FROM est importante. C'est l'adresse qui reçoit les notifications de rebond. Pour les e-mails transactionnels, il s'agit souvent d'une adresse de traitement des rebonds dédiée comme bounces+tag@yourdomain.com.

Rebonds stricts vs. rebonds souples

La distinction est critique. Continuer à envoyer aux adresses qui font rebond strict endommage votre réputation d'expéditeur. Les fournisseurs de boîtes aux lettres suivent votre taux de rebond — s'il dépasse environ 2%, votre délivrabilité en souffrera.

Codes d'état améliorés

Les serveurs SMTP modernes utilisent des codes d'état améliorés (RFC 3463, registre dans RFC 5248) qui fournissent beaucoup plus de détails que le code à trois chiffres de base. Le format est classe.sujet.détail :

• Classe : 2 = succès, 4 = échec temporaire, 5 = échec permanent
• Sujet : La catégorie du problème
• Détail : Le problème spécifique

Catégories de sujet

Codes d'état que vous verrez le plus

Format DSN : À quoi ressemble un message de rebond

Quand un rebond est généré de manière asynchrone, il arrive en tant que message structuré défini par RFC 3464, enveloppé dans le type MIME multipart/report de RFC 3462. Un DSN a trois parties :

Les trois parties MIME :

1. text/plain — Explication lisible par l'humain
2. message/delivery-status — Données structurées lisibles par machine avec le code d'état, le destinataire et les informations de diagnostic
3. message/rfc822 — Les en-têtes du message original (ou message complet), afin que vous puissiez identifier quel message a fait rebond

Les champs clés pour le traitement par programme :

• Final-Recipient: L'adresse qui a échoué
• Action: failed (permanent), delayed (temporaire), delivered, relayed, ou expanded
• Status: Le code d'état amélioré (p. ex., 5.1.1)
• Diagnostic-Code: La réponse SMTP brute

Gérer les rebonds par programme

Utiliser VERP pour une identification fiable

VERP (Variable Envelope Return Path) code l'adresse du destinataire dans le MAIL FROM, de sorte que lorsqu'un rebond revient, vous pouvez identifier exactement quel destinataire a fait rebond sans analyser le corps DSN :

Quand bob@example.com fait rebond, le DSN est livré à bounces+bob=example.com@yourdomain.com. Vous analysez la partie locale pour extraire le destinataire original. Cela fonctionne même quand le DSN est mal formé ou non standard.

Logique de traitement

Un processeur de rebond fiable suit cette logique :

1. Analyser le DSN — Extraire la partie message/delivery-status. Lire le champ Status:.
2. Classer le rebond :
   • Status commence par 5. → Rebond strict. Supprimer l'adresse.
   • Status commence par 4. → Rebond souple. Incrémenter un compteur.
3. Appliquer les règles de suppression :
   • 1 rebond strict → supprimer immédiatement
   • N rebonds souples dans une fenêtre (p. ex., 3 dans 7 jours) → supprimer comme strict
4. Identifier via VERP si l'analyse DSN échoue (beaucoup de serveurs envoient des rebonds non standard)
5. Enregistrer tout — Journaliser le code d'état, le diagnostic, l'horodatage et l'ID de message d'origine pour le débogage

Attention aux faux rebonds stricts

Certains serveurs retournent incorrectement 5xx pour les conditions temporaires (comme la limitation de débit). Si vous voyez 5.7.1 avec un message à propos de « trop de connexions » ou « réessayer plus tard », traitez-le comme un rebond souple malgré la classe 5xx. Utilisez le texte de diagnostic comme signal secondaire.

Taux de rebond et réputation

Les fournisseurs de boîtes aux lettres surveillent votre taux de rebond comme signal d'hygiène de liste :

• < 2% taux de rebond — Acceptable
• 2-5% — Zone d'avertissement. Vous verrez de l'étranglement et un placement accru dans le dossier spam.
• > 5% — Votre réputation IP et domaine se dégrade activement. Certains fournisseurs vous bloqueront.

Pour les e-mails transactionnels (réinitialisations de mot de passe, reçus), les taux de rebond doivent être bien en dessous de 1 %. Les taux de rebond élevés sur le courrier transactionnel suggèrent que votre application accepte des adresses invalides lors de l'inscription. Ajoutez la validation d'e-mail avant d'envoyer.

Ce qui peut mal tourner

Ignorer complètement les rebonds

L'erreur la plus courante. Si vous continuez à envoyer aux adresses qui font rebond strict, les fournisseurs de boîtes aux lettres vont étrangler et finalement bloquer votre IP d'envoi. Votre délivrabilité se dégrada pour tous les destinataires, pas seulement les invalides.

Formats de rebond non standard

Tous les MTA ne génèrent pas des DSN conformes à la RFC. Certains envoient des rebonds en texte brut sans partie message/delivery-status. D'autres incluent le code d'état uniquement dans le texte lisible par l'humain. Votre analyseur doit gérer ceux-ci avec élégance — c'est pourquoi VERP est si précieux comme méthode d'identification de secours.

Backscatter

Quand un serveur accepte un message d'un expéditeur usurpé et génère ensuite un rebond, ce rebond va à l'adresse MAIL FROM forgée. Le propriétaire du domaine innocent reçoit des messages de rebond pour du courrier qu'il n'a jamais envoyé. C'est appelé backscatter et c'est une forme d'abus. Les serveurs modernes devraient rejeter lors de la session SMTP (de façon synchrone) plutôt que d'accepter et faire rebond plus tard.

Boucles de rebond

Si votre adresse de traitement des rebonds elle-même fait rebond (en raison d'une mauvaise configuration), cela peut créer une boucle. SMTP prévient les boucles infinies en exigeant que les messages de rebond (ceux avec MAIL FROM:<>) ne fassent jamais eux-mêmes rebond — ils sont silencieusement ignorés si la livraison échoue.

Gestion de la liste de suppression

Une fois que vous supprimez une adresse, vous avez besoin d'un processus pour la réactiver. Les gens réparent leur boîte aux lettres (effacent le quota, réactivent le compte). Un modèle courant : permettre aux destinataires de se revalider en recevant avec succès un e-mail de confirmation après une période de refroidissement (30-90 jours).

Points clés à retenir

• Les rebonds stricts (5xx) sont permanents — arrêtez d'envoyer immédiatement. Les rebonds souples (4xx) sont temporaires — réessayez avec retrait progressif.
• Les codes d'état améliorés (X.Y.Z) vous donnent la raison spécifique. Apprenez les courants.
• Les DSN ont une partie structurée message/delivery-status pour l'analyse par machine. Utilisez-la.
• VERP code le destinataire dans le chemin de retour pour une identification fiable des rebonds.
• Gardez votre taux de rebond en dessous de 2 %. Pour les e-mails transactionnels, en dessous de 1 %.
• Validez les adresses e-mail au point de collecte, avant d'envoyer.

Lectures complémentaires

Related RFCs