Les codes SMTP sont une combinaison, pas un seul numéro

Un échec SMTP, ce sont trois listes en même temps. Les réduire à 550 enlève la seule partie qui dit quoi vérifier ensuite.

Les trois listes

Classe de réponse (RFC 5321). Le premier chiffre est 2 (succès), 4 (réessayer plus tard) ou 5 (ne pas réessayer de la même façon). 550 est un code de la classe 5. Ce n’est pas une cause.
Statut étendu (RFC 3463, puis le registre IANA). La forme est classe.sujet.détail. Le chiffre de classe doit s’accorder avec la réponse (5.1.1 avec un 5xx, 4.2.2 avec un 4xx). Le sujet dit quelle partie du système est en cause : 1 adressage, 2 boîte, 3 système de messagerie, 4 réseau, 7 sécurité ou politique.
Le texte. Les fournisseurs réutilisent les codes étendus génériques. 5.7.1 signifie « remise non autorisée » dans le registre. Gmail, un relais et une passerelle destinataire peuvent l’émettre pour des règles différentes. La phrase après le code fait partie de la preuve.

Un dossier utile garde les trois : 550 5.1.1 User unknown, pas 550.

Pourquoi le panel est un produit, pas une table de correspondance

Le même code de réponse s’associe à beaucoup de statuts étendus. Le même sujet s’associe à deux classes.

Ce que vous avez vu	Lecture plus étroite	Ce que cela ne prouve toujours pas
`550` seul	Échec permanent, cause inconnue	Authentification, politique de relais, ou mauvais destinataire
`550 5.1.1` … utilisateur inconnu	L’adresse destinataire a été rejetée	Que toutes les adresses du domaine échoueraient
`550 5.2.2` ou `452` … boîte pleine	Stockage ou quota de cette boîte	Un échec de contenu ou d’authentification
`4.2.2` face à `5.2.2`	Même sujet « boîte » ; `4` dit réessayer, `5` dit arrêter	Combien de temps la boîte reste pleine
`550 5.7.1`	Politique ou autorisation : le texte est obligatoire	Quelle règle a joué, tant que le texte ou la doc fournisseur ne le dit pas
`250`	Ce serveur a accepté cette transaction	La boîte de réception, une quarantaine ultérieure, ou une lecture

4.2.2 et 5.2.2 ne sont pas deux erreurs sans rapport. C’est le même sujet (la boîte) sous deux classes. Traiter chaque code à trois chiffres comme une cause propre, ou chaque code étendu comme un incident unique, rate la combinaison dans les deux cas.

Les codes génériques restent sans étiquette d’incident, exprès. 550 et 5.7.1 couvrent plusieurs causes. Les lier à un seul id inventerait une précision que la réponse n’a pas. Un code précis peut être lié : 5.1.1 est un statut d’adresse, 5.2.2 est une boîte pleine. Les codes fournisseur absents de la RFC 3463 (par exemple Gmail 5.7.26 ou Outlook 5.7.515) se lisent avec le texte de ce fournisseur, pas avec un sens RFC deviné.

Ce qu’il faut garder de la session

La ligne complète, code étendu et texte compris.
Quel hôte l’a renvoyée : le relais, le MX destinataire, ou un DSN plus tard.
La classe : réessayer (4xx) ou arrêter (5xx).
Ce qui a été cherché ensuite, et ce que cette recherche n’a pas montré.

Le catalogue d’erreurs du relais Google groupe par mécanisme (identifiants, relais refusé, limites). Il sert pour une réponse du relais Workspace. Ne collez pas un 5.1.1 de MX destinataire dans une checklist d’authentification de relais.

Limites

Cette page décrit comment lire un statut public, pas une fréquence mesurée de chaque combinaison sur votre tenant. La RFC 3463 définit la structure. Les fournisseurs ajoutent des codes et réutilisent les codes génériques. Le registre PunchOp garde les listes séparées et n’attache une étiquette d’incident que lorsque le code est assez précis. L’étiquette reste une hypothèse tant que le texte et le chemin ne concordent pas.

Voir aussi Erreurs du relais SMTP Google Workspace et le code de statut étendu.