117 codes sur 117
Codes de réponse de base
État du système ou réponse d'aide du système. Peu utilisé en pratique.
Message d'aide en réponse à la commande HELP, avec des informations sur l'utilisation du serveur ou d'une commande précise.
Message d'accueil initial du serveur à l'ouverture de la connexion : le service est prêt. C'est aussi la réponse à STARTTLS pour indiquer que la négociation TLS peut commencer.
Le serveur ferme la connexion, généralement en réponse à la commande QUIT.
L'authentification avec AUTH a réussi. Généralement accompagné du code amélioré 2.7.0.
L'action demandée a été effectuée. C'est la réponse habituelle à EHLO, MAIL FROM, RCPT TO et à la fin de DATA, lorsque le serveur accepte le message.
Le destinataire n'est pas local, mais le serveur accepte le message et le transférera à l'adresse indiquée.
Le serveur ne confirme pas si l'utilisateur existe (VRFY désactivé pour empêcher l'énumération des comptes), mais il acceptera le message et tentera de le remettre.
Réponse à ETRN : le serveur a commencé à remettre les messages en file d'attente pour le domaine ou le nœud demandé.
Défi du serveur pendant AUTH, encodé en Base64. Le client doit répondre avec la donnée suivante du mécanisme (par exemple, le nom d'utilisateur ou le mot de passe avec AUTH LOGIN).
Réponse à DATA : le serveur attend le contenu du message, qui se termine par une ligne ne contenant qu'un point.
Le service n'est pas disponible et le serveur ferme la connexion : arrêt, surcharge, trop de connexions ou limite d'envoi temporaire. L'expéditeur doit réessayer plus tard.
L'utilisateur doit changer son mot de passe ou passer à un autre mécanisme d'authentification avant de pouvoir s'authentifier. Accompagné du code amélioré 4.7.12.
La boîte aux lettres est temporairement indisponible : occupée, verrouillée ou rejetée temporairement par une stratégie. Le greylisting répond généralement avec ce code ou avec 451.
L'action a été abandonnée à cause d'une erreur locale du serveur, comme un échec de requête DNS ou un filtre qui n'a pas répondu. L'expéditeur doit réessayer plus tard.
Le serveur n'a pas assez d'espace pour accepter le message pour le moment. Indique aussi que le nombre de destinataires par message a été dépassé : le client doit envoyer le reste dans une autre transaction.
Échec temporaire de l'authentification (par exemple, le serveur d'identifiants ne répond pas) ou TLS momentanément indisponible lors d'une demande STARTTLS.
Le serveur ne peut pas prendre en charge pour le moment les paramètres envoyés dans MAIL FROM ou RCPT TO, mais pourrait les accepter plus tard.
Réponse à ETRN : le serveur ne peut pas traiter pour le moment la file d'attente du nœud demandé.
Réponse à ETRN : le nœud ou domaine demandé n'est pas autorisé à demander la remise de sa file d'attente.
Le serveur ne reconnaît pas la commande ou la ligne est trop longue. AUTH l'utilise aussi lorsqu'une ligne de l'échange dépasse la longueur maximale autorisée.
La commande est valide, mais pas ses paramètres ou arguments : par exemple, une adresse mal formée dans MAIL FROM ou un nom invalide dans EHLO.
Le serveur reconnaît la commande mais ne l'implémente pas ou l'a désactivée, comme VRFY ou EXPN sur de nombreux serveurs.
Les commandes sont arrivées dans le mauvais ordre, par exemple RCPT TO avant MAIL FROM, ou DATA sans destinataire valide. Certains serveurs le renvoient lorsqu'on tente d'envoyer sans s'authentifier.
Le serveur n'accepte pas le paramètre indiqué, par exemple un mécanisme AUTH qu'il ne prend pas en charge.
L'hôte n'accepte aucun e-mail. Il est envoyé comme message d'accueil à la place de 220 et le client ne doit pas réessayer.
Le serveur exige une authentification, ou le démarrage de TLS avec STARTTLS, avant d'accepter la commande. Typique lors de l'utilisation du port de soumission 587 sans identifiants.
Le mécanisme d'authentification choisi est trop faible selon la stratégie du serveur. Certains fournisseurs le renvoient lorsqu'ils exigent des mots de passe d'application ou OAuth.
Nom d'utilisateur ou mot de passe incorrect, ou identifiants refusés. Accompagné du code amélioré 5.7.8.
Le mécanisme d'authentification choisi n'est autorisé que sur une connexion chiffrée : il faut d'abord exécuter STARTTLS.
La boîte aux lettres n'existe pas ou n'est pas disponible, ou le message a été rejeté par une stratégie (spam, listes noires, SPF, DKIM ou DMARC). Le code amélioré qui l'accompagne indique la cause précise.
Le destinataire n'est pas local et le serveur ne transfère pas le message ; il peut indiquer à quelle adresse l'envoyer.
L'espace alloué est dépassé : la boîte aux lettres du destinataire est pleine ou le message dépasse la taille maximale annoncée par l'extension SIZE.
L'adresse e-mail n'est pas valide ou n'est pas autorisée, par exemple à cause d'une syntaxe incorrecte ou parce que l'expéditeur ne peut pas utiliser cette adresse.
La transaction a échoué. En message d'accueil, cela signifie qu'il n'y a pas de service SMTP pour ce client ; après DATA, que le message a été rejeté, souvent à cause de son contenu ou de la réputation de l'expéditeur.
Le serveur ne reconnaît pas ou n'implémente pas un paramètre d'extension envoyé dans MAIL FROM ou RCPT TO.
Le domaine du destinataire publie un null MX (un enregistrement MX qui pointe vers « . ») : il déclare ne pas recevoir d'e-mails, il est donc inutile de réessayer.
Codes d'état améliorés (RFC 3463)
État sans autre précision : utilisé lorsque seule la classe du résultat est connue (succès, échec temporaire ou permanent).
Il y a un problème avec une adresse du message qui ne correspond à aucun des codes plus précis.
La boîte aux lettres du destinataire n'existe pas sur le serveur de destination. C'est le rebond classique dû à une adresse mal saisie ou à un compte supprimé.
Le domaine ou le système de destination n'existe pas ou ne peut pas accepter d'e-mails, par exemple parce que le domaine ne se résout pas.
L'adresse du destinataire a une syntaxe invalide.
L'adresse du destinataire correspond à plusieurs boîtes aux lettres sur le système de destination.
L'adresse du destinataire est valide. Apparaît sous la forme 2.1.5 dans la réponse positive à RCPT TO.
La boîte aux lettres existait mais a été déplacée, et aucune adresse de réexpédition n'est connue.
L'adresse de l'expéditeur a une syntaxe invalide.
Le domaine de l'expéditeur n'existe pas ou n'accepte pas de réponses, par exemple parce qu'il n'a ni enregistrement MX ni enregistrement A.
Le message a été remis à un système qui ne prend pas en charge les notifications d'état ; sa remise finale ne pourra donc pas être confirmée.
Le domaine du destinataire publie un null MX : il déclare ne pas recevoir d'e-mails.
La boîte aux lettres existe, mais un problème la concernant a empêché la remise et il n'existe pas de code plus précis.
La boîte aux lettres existe mais est désactivée et n'accepte pas de messages, par exemple un compte suspendu.
La boîte aux lettres du destinataire a dépassé son quota de stockage.
Le message dépasse la taille maximale que le destinataire est autorisé à recevoir.
Le destinataire est une liste de distribution qui n'a pas pu être développée en ses membres.
Le système de destination a rencontré un problème qui ne correspond à aucun des codes plus précis.
Le stockage du système de messagerie de destination est plein.
L'hôte de destination n'accepte pas de messages, en raison d'un arrêt imminent, d'une surcharge ou d'une maintenance.
Le système de destination ne prend pas en charge une fonctionnalité requise par le message.
Le message dépasse la taille maximale que le serveur accepte pour n'importe quel destinataire.
Le système de destination est mal configuré et ne peut pas accepter le message.
Le message a été accepté, mais avec une priorité différente de celle demandée (extension MT-PRIORITY).
Un problème de réseau ou de routage est survenu, qui ne correspond à aucun des codes plus précis.
Le serveur de destination n'a pas répondu à la tentative de connexion.
La connexion a été établie, mais elle a été coupée ou est devenue instable avant la fin de la remise.
Un service d'annuaire nécessaire à la remise a échoué, généralement la résolution DNS.
Aucune route vers la destination n'a été trouvée, par exemple parce que le domaine n'a pas d'enregistrements MX ou A utilisables.
Le système de messagerie est congestionné et ne peut pas traiter le message pour le moment.
Une boucle de routage a été détectée : le message est passé trop de fois par les mêmes serveurs.
Le délai maximal de nouvelles tentatives a expiré et le message est abandonné sans avoir été remis.
Un problème de protocole de remise est survenu, qui ne correspond à aucun des codes plus précis.
La commande n'est pas valide, n'est pas autorisée à ce moment-là ou n'est pas reconnue.
La commande contient une erreur de syntaxe et le serveur ne peut pas l'interpréter.
Le message a plus de destinataires que le serveur n'en accepte dans une transaction.
La commande est valide, mais ses arguments ne le sont pas ou ne sont pas pris en charge.
Il y a une incompatibilité de version du protocole entre le client et le serveur.
Une ligne de l'échange AUTH dépasse la longueur maximale acceptée par le serveur.
Un problème lié au contenu du message est survenu, qui ne correspond à aucun des codes plus précis.
La destination ne prend pas en charge le type de contenu du message ou de l'une de ses pièces jointes.
Pour remettre le message, il faudrait convertir son contenu, mais l'expéditeur l'a interdit.
Pour remettre le message, il faudrait convertir son contenu, et le serveur ne sait pas le faire.
Le message a été remis, mais la conversion du contenu a entraîné une perte d'informations.
La conversion du contenu du message a échoué.
Le contenu du message référencé par une URL n'a pas pu être récupéré (extension BURL).
L'expéditeur ou le destinataire ne prend pas en charge les adresses contenant des caractères non ASCII (e-mail internationalisé, SMTPUTF8).
Le serveur doit répondre avec du texte UTF-8, mais le client n'a pas annoncé la prise en charge de SMTPUTF8.
Le message contient des en-têtes UTF-8 et ne peut pas être transféré à un ou plusieurs destinataires qui ne les prennent pas en charge ; il est donc rejeté.
État de sécurité sans autre précision. Apparaît lors des authentifications réussies (2.7.0), des échecs temporaires d'AUTH (4.7.0) et des rejets par stratégie.
L'expéditeur n'est pas autorisé à envoyer à ce destinataire : blocage dû à une liste noire, à la réputation, à l'antispam ou à une tentative de relais non autorisée. Sous la forme 4.7.1, il indique généralement du greylisting.
L'expéditeur n'a pas l'autorisation d'envoyer à cette liste de distribution.
Il faudrait convertir le message d'un protocole de sécurité à un autre, ce qui n'est pas possible.
Le message requiert des fonctionnalités de sécurité que la destination ne prend pas en charge.
Une opération cryptographique a échoué pendant le transport, par exemple la vérification d'une signature ou le déchiffrement.
La destination ne prend pas en charge l'algorithme cryptographique utilisé dans le message.
La vérification d'intégrité a échoué : le message a été modifié en transit ou la somme de contrôle ne correspond pas.
Les identifiants d'authentification ne sont pas valides : nom d'utilisateur ou mot de passe incorrect.
Le mécanisme d'authentification choisi est plus faible que ce qu'exige la stratégie du serveur.
Une couche de chiffrement externe, comme TLS, est nécessaire pour utiliser le mécanisme d'authentification demandé. Prévu surtout pour les mécanismes qui envoient le mot de passe en clair.
Le mécanisme d'authentification demandé n'est autorisé que sur une connexion chiffrée.
L'utilisateur doit changer son mot de passe ou passer à un autre mécanisme d'authentification.
Le compte de l'utilisateur qui tente de s'authentifier est désactivé.
Le serveur n'accepte que les messages provenant de systèmes avec lesquels il a établi une relation de confiance.
La priorité du message est trop basse pour qu'il soit accepté pour le moment (extension MT-PRIORITY).
Le message est trop volumineux pour la priorité indiquée (extension MT-PRIORITY).
La boîte aux lettres a changé de propriétaire depuis la date indiquée par l'expéditeur ; le message n'est donc pas remis (extension RRVS).
Le domaine du destinataire a changé de propriétaire depuis la date indiquée par l'expéditeur (extension RRVS).
Le serveur ne peut pas vérifier si la boîte aux lettres a changé de propriétaire, comme l'a demandé l'expéditeur (extension RRVS).
Le message ne comporte aucune signature DKIM valide alors que la stratégie du destinataire en exige une.
Le message comporte des signatures DKIM valides, mais aucune ne respecte la stratégie du destinataire (par exemple, à cause du domaine signataire ou de l'algorithme).
Le message ne comporte pas de signature DKIM valide du même domaine que celui de l'en-tête From.
L'IP d'envoi n'est pas autorisée dans l'enregistrement SPF du domaine de l'expéditeur.
L'évaluation SPF a renvoyé une erreur, par exemple à cause d'un enregistrement mal formé ou d'un trop grand nombre de requêtes DNS.
L'IP d'envoi n'a pas de DNS inverse (PTR), ou le nom renvoyé ne se résout pas vers cette même IP.
Plusieurs contrôles d'authentification du message ont échoué en même temps, comme SPF et DKIM.
Le domaine de l'expéditeur publie un null MX ; il ne pourrait donc recevoir ni réponses ni rebonds, et le message est rejeté.
Le message semble faire partie d'un envoi massif de messages abusifs similaires.
La validation de la chaîne ARC a échoué ; ARC préserve les résultats d'authentification lorsque le message passe par des redirecteurs ou des listes de diffusion.
Le message exige REQUIRETLS et le serveur suivant sur la route ne prend pas en charge cette extension ; il ne peut donc pas être remis avec une garantie de chiffrement.
Collez la réponse complète du serveur, par exemple 550 5.7.1 Message rejected, pour voir à la fois le code de base et le code amélioré. Pour un code de base, la recherche affiche aussi les codes améliorés qui l'accompagnent habituellement.
Comment ça marche
Dans une session SMTP, chaque commande du client (EHLO, MAIL FROM, RCPT TO, DATA…) reçoit une réponse du serveur qui commence par un code à trois chiffres. Le premier indique l'issue : 2 signifie succès, 3 que le serveur attend d'autres données, 4 une erreur temporaire et 5 une erreur permanente. Le deuxième indique le domaine : x0z syntaxe, x1z information, x2z connexion et x5z système de messagerie. Le texte qui suit le code est libre et chaque serveur écrit le sien ; les logiciels ne regardent que le numéro.
Comme trois chiffres en disent peu sur la cause, la RFC 3463 a défini les codes d'état améliorés, au format classe.sujet.détail : 5.1.1 est un échec permanent (5) lié à l'adressage (1) parce que la boîte aux lettres n'existe pas (1). La classe reprend le sens du premier chiffre (2, 4 ou 5), le sujet regroupe la cause et le détail la précise. Les serveurs qui les utilisent l'annoncent avec l'extension ENHANCEDSTATUSCODES dans leur réponse à EHLO, et le même code apparaît dans le champ Status des messages de non-remise.
Le tableau réunit les codes de base de la RFC 5321 et ceux qu'ajoutent les extensions courantes (AUTH, STARTTLS, ETRN et null MX), ainsi que tous les codes améliorés du registre de l'IANA, avec les codes de base avec lesquels chacun apparaît habituellement. Les grands fournisseurs ajoutent leurs propres textes et liens d'aide, mais toujours sur ces mêmes numéros.
Exemples
550 5.1.1 <nadie@example.com>: Recipient address rejected: User unknown in local recipient table5xx Permanent · X.1.1 Bad destination mailbox addressLe rebond typique de Postfix lorsque le compte n'existe pas. Réessayer ne sert à rien : il faut corriger l'adresse. Si le même destinataire fonctionnait auparavant, le compte a très probablement été supprimé.450 4.2.0 <ana@example.com>: Recipient address rejected: Greylisted4xx Transient · X.2.0 Other or undefined mailbox statusGreylisting : le serveur rejette temporairement l'expéditeur inconnu et attend qu'il réessaie. Un serveur de messagerie légitime le fait tout seul au bout de quelques minutes et le message passe ; beaucoup de logiciels de spam ne réessaient jamais.AUTH LOGIN334 VXNlcm5hbWU6Le 334 transporte le défi en Base64 : VXNlcm5hbWU6 correspond à « Username: » et le suivant, UGFzc3dvcmQ6, à « Password: ». Si les identifiants sont incorrects, le serveur répond 535 5.7.8 ; s'il exige d'abord le chiffrement, 538 ou 530.Cas d'usage
- Comprendre pourquoi un e-mail a été rejeté à partir du message d'erreur renvoyé par le serveur.
- Distinguer si une erreur est temporaire et que la file d'attente réessaiera, ou permanente et qu'il faut agir.
- Diagnostiquer les échecs d'authentification lors de la configuration de l'envoi d'e-mails depuis une application, une imprimante ou un serveur.
- Interpréter les rejets liés à SPF, DKIM, DMARC, au DNS inverse ou aux listes noires dans les journaux du serveur de messagerie.
- Classer les rebonds dans une plateforme d'e-mailing pour supprimer les adresses inexistantes.
- Lire une session SMTP capturée avec telnet, openssl s_client ou swaks.
Questions fréquentes
Quelle est la différence entre une erreur 4xx et une erreur 5xx ?
Une 4xx est temporaire : le serveur d'envoi garde le message en file d'attente et réessaie régulièrement, en général pendant quatre ou cinq jours, avant d'abandonner et de générer un message de non-remise. Une 5xx est permanente : le rebond est immédiat, et renvoyer le même message sans rien changer échouera à nouveau.
Pourquoi la réponse contient-elle deux codes, comme 550 5.1.1 ?
Le premier est le code de base à trois chiffres exigé par la RFC 5321. Le second est le code d'état amélioré de la RFC 3463, qui précise la cause : un 550 peut être dû à une boîte aux lettres inexistante (5.1.1), à un blocage par stratégie (5.7.1) ou à un échec SPF (5.7.23). Pour le diagnostic, fiez-vous surtout au code amélioré.
Que signifie le tiret dans 550-5.7.1 ?
Que la réponse s'étend sur plusieurs lignes. Toutes portent le même code, mais les lignes intermédiaires le séparent du texte par un tiret et la dernière par un espace : le client sait ainsi quand la réponse est terminée. C'est la même chose que dans la liste des extensions renvoyée par EHLO.
Pourquoi suis-je rejeté avec 550 5.7.1 alors que l'adresse existe ?
Parce que le 5.7.1 ne concerne pas le destinataire mais l'expéditeur : le serveur ne vous autorise pas à lui remettre ce message. Les causes habituelles sont que l'IP d'envoi figure sur une liste noire, que la vérification SPF, DKIM ou DMARC du domaine échoue, que l'IP n'a pas de DNS inverse ou qu'on a tenté d'utiliser le serveur comme relais sans s'authentifier. Le texte qui accompagne le code donne généralement un indice.
Pourquoi est-ce que j'obtiens 530 ou 535 en envoyant un e-mail depuis une application ?
Le 530 indique que le serveur exige une authentification, ou le démarrage de TLS, avant d'accepter le message ; le 535, que le nom d'utilisateur ou le mot de passe est incorrect. Vérifiez que l'application utilise le port 587 avec STARTTLS ou le port 465 avec TLS implicite, que l'authentification est activée et, chez des fournisseurs comme Gmail ou Microsoft 365, que vous utilisez un mot de passe d'application ou OAuth au lieu de votre mot de passe habituel.