Codes d’état étendus SMTP (RFC 3463)

Quand un message est refusé ou rebondit, la réponse comporte généralement un code comme 5.1.1 ou 4.2.2. Ces codes vous indiquent si l’échec est définitif et quelle partie du système de messagerie a échoué, ce qui en fait la donnée la plus utile pour classer automatiquement les rebonds.

La RFC 3463 définit ces codes d’état étendus du système de messagerie. Les codes X.Y.Z apparaissent dans les réponses SMTP et dans le champ Status: des notifications d’état de livraison. Ils existent parce que les codes de réponse SMTP de base à 3 chiffres (250, 450, 550…) mélangent les résultats du transport et le sens du résultat de la livraison. Les codes étendus donnent un motif qu’une machine peut analyser et qui ne dépend pas du transport.

Structure

status-code = class "." subject "." detail

Chaque composant est numérique, sans zéro non significatif.

Classe (premier nombre) : l’échec est-il définitif ?

Sujet (deuxième nombre) : quelle partie du système a échoué ?

Table complète des codes de détail

X.1.X : adressage

X.2.X : boîte aux lettres

X.3.X : système de messagerie

X.4.X : réseau et routage

X.5.X : protocole de livraison du courrier

X.6.X : contenu ou média du message

X.7.X : sécurité ou politique

Utiliser les codes pour classer les rebonds

Voici les combinaisons qui apportent le plus d’information à un moteur de suppression :

Mises en garde :

• Le chiffre de classe décide de la manière de réessayer, même lorsque le sujet et le détail semblent le contredire. Dans le modèle de la RFC 3463, c’est le jugement du premier nombre sur le caractère définitif de l’échec qui l’emporte.
• Beaucoup de serveurs de réception ne renvoient qu’un code générique (5.0.0) ou un texte non standard. Les classificateurs fiables combinent le code étendu avec le texte libre du Diagnostic-Code (voir Delivery Status Notifications).
• Des RFC ultérieures et des enregistrements IANA étendent cette liste. Par exemple, la RFC 7372 enregistre des codes 5.7.x supplémentaires pour les échecs SPF et DMARC. Les codes ci-dessus sont l’ensemble de base de la RFC 3463, commun à toutes les implémentations.

Les codes d’état et la règle de retrait du M3AAWG

Le Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) fixe la référence du secteur pour le retrait des adresses qui produisent des rebonds, dans ses Sender Best Common Practices (version 4.0, août 2026, section 2.2). Ses recommandations comportent trois volets :

• Lorsque le serveur de réception indique qu’il n’y a personne à cette adresse (« user unknown »), ne réessayez pas, et supprimez l’adresse des envois futurs.
• Les codes numériques n’ont pas été conçus pour dire si une adresse devrait être retirée : les expéditeurs doivent donc lire le texte descriptif pour décider du traitement de l’adresse. Le texte peut désigner un problème d’infrastructure ou de contenu chez l’expéditeur, ou montrer que l’adresse IP de l’expéditeur figure sur une liste de blocage. Les expéditeurs devraient chercher à diagnostiquer et à corriger les problèmes de livraison des adresses qui semblent valides.
• Comme meilleure pratique générale, retirez une adresse qui produit un rebond au moins deux fois de suite, sur une période de deux semaines ou plus, quels que soient le code ou le texte. Chaque expéditeur choisit le nombre exact de campagnes et la durée, et la durée tient compte des problèmes de serveur côté réception qui peuvent provoquer un rebond par erreur.

Le tableau ci-dessus indique de ne pas supprimer le destinataire en cas de refus pour raison de politique 5.7.x, avec une exception pour une seule adresse (cas 4 ci-dessous). La raison tient à ce que ces codes signalent d’ordinaire. Un 5.7.x est un refus pour des raisons de sécurité ou de politique : une inscription sur une liste de blocage, un échec d’authentification, un blocage lié à la réputation. Ces causes relèvent de l’expéditeur, et elles touchent généralement de nombreux destinataires chez le même fournisseur au même moment. Supprimer toutes les adresses qui en ont reçu un retire de vrais abonnés à cause d’un problème de votre côté, et laisse le problème en place.

Appliquez les deux règles ensemble :

1. Échecs liés à l’adresse (5.1.1, 5.1.2, 5.1.3, 5.1.6 et 5.2.1) : supprimez, comme l’indique le tableau. Ils correspondent au cas « user unknown » des recommandations du M3AAWG.
2. Autres échecs qui se répètent pour une même adresse (une boîte pleine de façon récurrente, ou un 5.0.0 générique dont le texte ne mentionne aucune politique) : comptez un rebond par campagne, et non un par nouvelle tentative. Retirez l’adresse lorsque le compteur atteint votre seuil et que les rebonds s’étendent sur au moins deux semaines. Deux campagnes constituent le minimum du M3AAWG ; un nombre plus élevé respecte toujours sa règle.
3. Refus pour raison de politique ou de réputation (5.7.x) : examinez au lieu de supprimer. Lisez le texte, vérifiez les listes de blocage et l’authentification, et corrigez la cause. Les rebonds reçus pendant que vous étiez bloqué ne disent rien des adresses : ne les comptez donc pas dans le compteur de retrait d’une adresse.
4. Un 5.7.x qui se répète pour une seule adresse, sur au moins deux campagnes et deux semaines, alors que d’autres adresses du même domaine acceptent vos emails : cela désigne le destinataire, et non votre réputation (par exemple, une boîte qui refuse vos emails par choix de son titulaire). Traitez-le comme le cas 2, selon la règle de retrait du M3AAWG.

Pour la mécanique de suppression qu’applique une plateforme, voir Surveillance et rétablissement de la réputation.