Erreur SMTP 421 : signification et correction

Que signifie vraiment l’erreur SMTP 421 ?

Le serveur de réception a accepté votre connexion, mais ferme la session SMTP sans prendre le message et veut que vous reveniez plus tard. La RFC 5321, la norme qui définit SMTP, décrit 421 comme « Service not available, closing transmission channel » et précise que le serveur peut le renvoyer « après avoir détecté le besoin d’arrêter le service SMTP », en réponse à une commande ou en pleine conversation.

Le chiffre de tête compte. La RFC 5321 classe chaque réponse en trois niveaux de gravité, et une réponse 4yz est une réponse négative transitoire : « la commande n’a pas été acceptée et l’action demandée n’a pas eu lieu. Toutefois, la condition d’erreur est temporaire, et l’action peut être redemandée. » Autrement dit, rien n’est perdu. Le destinataire ne dit pas que votre message est mauvais. Il dit « pas maintenant ».

Le code étendu à trois nombres qui suit souvent (défini dans la RFC 3463) précise la raison : 4.7.0 est un report générique de sécurité/politique, 4.7.28 le signal de taux de spam de Gmail, 4.3.2 signifie « system not accepting network messages ». Tous ont le 4 : tous sont temporaires.

Le 421 est-il temporaire ou définitif ?

Temporaire : c’est tout le sens du préfixe 4, et cette différence décide de votre réaction. Un code 4xx veut dire réessayer ; un code 5xx veut dire arrêter. Traiter un 421 comme un rejet définitif et retirer le destinataire, c’est jeter des e-mails livrables. Traiter un 5xx comme un 421 et marteler le serveur nuit à votre réputation sans raison.

Voici le contraste qui piège souvent :

• 421 / 4xx (transitoire) : « Service indisponible, réessayez. » Le message reste en file. Voisins : 450 (boîte temporairement indisponible) et 451 (erreur locale de traitement, souvent du greylisting).
• 550 / 5xx (définitif) : « Cela ne marchera jamais tel quel. » Le message est rejeté. Un rejet de politique 550 5.7.1 ou un échec d’authentification 550 5.7.9 (comme ceux des rejets 550 de Gmail) exige un vrai changement avant de renvoyer.

Un 421 ponctuel est donc sans gravité. Un 421 répété à chaque tentative, des jours durant, est un signal faible qui devient un problème de livraison. Le destinataire ne se fie pas assez à votre flux pour le laisser entrer à pleine vitesse.

Que signifient les variantes 421 4.7.0, 4.7.28 et 4.3.2 ?

Chaque variante désigne une cause différente : lisez le code étendu avant de changer quoi que ce soit.

• 421 4.7.0 est un bridage de sécurité ou de politique. Dans la liste des codes d’erreur SMTP de Google, 4.7.0 couvre les messages différés pour « la très faible réputation de l’IP d’envoi », un PTR (DNS inverse) absent, une connexion TLS exigée ou une IP non autorisée pour le domaine destinataire. C’est le code fourre-tout « cette connexion n’inspire pas encore assez confiance ».
• 421 4.7.28 est le code de limite de débit de Gmail. La référence Gmail SMTP errors and codes de Google liste plusieurs formulations. Celle sur l’IP dit « Gmail has detected an unusual rate of email originating from your IP address », d’autres citent votre bloc d’IP, domaine DKIM, domaine SPF ou un domaine d’URL. Chacune renvoie aux consignes aux expéditeurs de Google. Gmail diffère l’e-mail sans l’accepter. Notre page 421 4.7.28 liste chaque formulation et la marche à suivre.
• 421 4.3.2 est « System not accepting network messages » selon la RFC 3463 : le système de réception est surchargé, s’arrête ou freine les entrées. Ses cousins sont 421 4.3.0 (« Temporary System Problem. Try again later. ») et 421 4.4.5 (« Server busy, try again later. »). Ils reflètent souvent l’état du destinataire, pas le vôtre, et disparaissent au réessai.

La logique est constante : les codes 4.7.x vous visent vous (réputation, politique, authentification) ; 4.3.x et 4.4.x visent plus souvent la capacité du destinataire à l’instant.

Comment corriger un report 421 ?

Partez de « est-ce mon problème ? » puis élargissez. La plupart des 421 isolés n’exigent rien ; ces étapes comptent quand le report persiste.

1. Vérifiez qu’il se répète, et pas une seule fois. Consultez vos logs. Si un 421 a été suivi d’un réessai réussi une heure plus tard, c’est réglé. C’était le délai normal ou le greylisting qui faisait son travail.
2. Lisez le code étendu et le texte. 4.7.28 et 4.7.0 (faible réputation) : ralentissez et assainissez ; 4.3.2 / 4.4.5 : attendez, en général. Comparez au tableau ci-dessus.
3. Ralentissez et faites une montée en charge. Si un pic l’a déclenché, baissez le volume vers ce fournisseur et remontez peu à peu sur plusieurs jours, sans rafale. Les IP et domaines neufs ont surtout besoin d’une montée douce pour gagner la confiance des destinataires.
4. Authentifiez et alignez. Publiez ou réparez les trois enregistrements, alignés sur votre domaine From visible. Vérifiez chacun avec les tests SPF, DKIM et DMARC de Palisade, et la résolution DNS avec l’outil de requête DNS. Notre guide de l’authentification des e-mails montre comment les trois s’articulent.
5. Vérifiez le DNS inverse et la réputation IP. Un PTR absent ou une IP sur une liste de blocage déclenche souvent un 4.7.0. Votre IP d’envoi doit avoir un DNS inverse valide pointant vers votre nom d’hôte.
6. Réparez la réputation d’envoi. Si Gmail ou une autre messagerie vous bride pour un comportement de spam, le blocage s’allège avec des e-mails propres et voulus, et peu de plaintes. Notre guide pour vérifier et améliorer la réputation de domaine détaille la reprise.
7. Laissez la file travailler. Après la correction, ne déversez pas le retard à la main. Votre MTA réessaiera seul ; tout forcer d’un coup peut relancer la limite que vous venez de lever.

Pourquoi le 421 revient-il malgré les réessais ?

Parce que le réessai traite le symptôme, pas la cause. Chaque réessai réussi livre ce message, mais si la cause est une limite de débit ou de réputation, le lot suivant bute sur le même mur. Le destinataire ne bugue pas. Il décide, de façon constante, que votre flux doit aller moins vite que vous ne le poussez.

C’est ce que la plupart des expéditeurs ratent : un code transitoire peut décrire une condition persistante. 421 4.7.28 se déclenche tant que Gmail voit un taux inhabituel d’e-mails qu’il juge non sollicités ; 421 4.7.0 pour faible réputation IP persiste jusqu’au rétablissement de cette réputation. Le 4 promet que le message peut passer au réessai, pas que la tendance changera seule.

La correction durable se situe donc en amont de la boucle de réessai (authentification, gestion du volume, réputation), et un 421 quotidien est un avertissement, pas du bruit. Un destinataire qui vous diffère sans cesse peut passer à des rejets 5xx. Si vos messages s’accumulent au lieu de partir, pourquoi votre e-mail est en file d’attente détaille la même dynamique de bridage côté expéditeur.

Que doit faire un bon serveur d’envoi face à un 421 ?

Mettre le message en file et réessayer avec un délai croissant, sans le rejeter ni réessayer trop vite. Les consignes de réessai de la RFC 5321 sont précises : « l’intervalle de réessai DEVRAIT être d’au moins 30 minutes », et les réessais continuent « jusqu’à la transmission du message ou l’abandon », où « le délai d’abandon doit en général être d’au moins 4-5 jours ».

En pratique, un MTA conforme :

• Attend avant de réessayer. Il patiente, puis réessaie après un délai croissant (backoff exponentiel), plutôt que de renvoyer à la seconde.
• Garde le message en file plusieurs jours. La plupart des serveurs réessaient environ 24–72 heures ou plus avant d’avertir d’un retard, et ne rejettent qu’après le délai d’abandon.
• Passe le greylisting sans effort. Le greylisting diffère les expéditeurs inconnus (IP d’envoi, expéditeur d’enveloppe et destinataire) par un code 4xx temporaire, en pariant que les logiciels de spam ne réessaieront pas. Un vrai MTA réessaie peu après et passe.

Si votre plateforme rejette l’e-mail dès un 421 au lieu de réessayer, la mauvaise configuration est de votre côté. Elle jette des messages livrables que la norme vous demande de réessayer.

Problèmes courants de reports 421

Le 421 passe au réessai mais revient à chaque envoi

C’est le cas typique du « transitoire persistant ». La livraison finit par réussir, donc tout semble normal, mais chaque nouveau lot est d’abord différé. Presque toujours, vous touchez une limite de débit ou un plafond de réputation. Baissez le volume vers ce fournisseur, montez plus lentement et vérifiez que l’authentification réussit. Ne comptez pas seulement sur les réessais.

Seul Gmail (ou un seul fournisseur) renvoie 421

Un 421 d’un seul fournisseur de messagerie vise votre réputation chez lui, pas un enregistrement cassé. Si Gmail vous bride avec 4.7.28 alors qu’Outlook et Yahoo acceptent vos e-mails, c’est souvent votre réputation ou votre volume chez Gmail. Consultez Google Postmaster Tools pour la réputation de votre domaine et IP, et dosez l’envoi vers Gmail à part.

Un domaine ou une IP neuve reçoit un 421

Un nouvel expéditeur n’a pas de réputation : les destinataires sont prudents et diffèrent les premières rafales. C’est normal. Montez en charge : de petits envois vers des contacts engagés, puis une hausse graduelle sur une à plusieurs semaines. Pousser un gros volume sur une IP froide dès le premier jour est le plus sûr moyen d’obtenir un 4.7.0 ou 4.7.28.

Votre MTA abandonne et rejette avant toute livraison

Si un 421 devient un rejet définitif en quelques minutes, vos réglages de réessai sont trop agressifs ou votre délai d’abandon trop court. La RFC 5321 attend un intervalle d’au moins 30 minutes et un abandon après plusieurs jours : allongez la durée de vie en file et le délai pour donner aux reports transitoires leurs réessais.

À lire aussi

• E-mail en file d’attente : cause et correction
• Pourquoi Gmail rejette-t-il mes e-mails (erreur 550) ?
• Comment vérifier et améliorer la réputation de votre domaine ?