Un message rejeté vous dit exactement pourquoi

par Francis Rozange | Sep 8, 2026 | Emailing

Abstract 3D render: beams of light returning down a dark corridor, sorted into coloured channels

Un message rejeté vous répond. Il vous dit pourquoi, avec une précision que vous ne trouverez dans aucun tableau de bord, et il vous le dit gratuitement.

Presque personne ne le lit. On regarde un taux de rebond, on constate qu’il monte, et on cherche la cause ailleurs. Elle est écrite en toutes lettres dans le journal d’envoi.

Apprendre à lire trois nombres suffit.

Le premier chiffre : réessayer ou renoncer

Le code de base vient de la RFC 5321, la norme SMTP d’octobre 2008. Elle définit deux familles d’échec, et la définition mérite d’être lue exactement.

« 4yz Transient Negative Completion reply. The command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again. »

« 5yz Permanent Negative Completion reply. The command was not accepted and the requested action did not occur. The SMTP client SHOULD NOT repeat the exact request (in the same sequence). »

La norme donne un critère de départage, et il est plus intelligent que le raccourci habituel :

« A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category is that replies are 4yz if they can be successful if repeated without any change in command form or in properties of the sender or receiver. »

Un 4xx réussira peut-être si vous répétez à l’identique. Un 5xx ne réussira que si quelque chose change. La norme ajoute d’ailleurs : « Even some « permanent » error conditions can be corrected. »

Un 5xx n’est donc pas une condamnation définitive. C’est l’interdiction de recommencer sans rien corriger.

Les trois nombres : la vraie information

Le code étendu vient de la RFC 3463, de janvier 2003. Sa structure est simple :

« status-code = class « . » subject « . » detail »

La classe reprend la sévérité. Le deuxième nombre désigne la nature du problème : 1 pour l’adresse du destinataire, 2 pour la boîte, 4 pour le réseau, 5 pour le protocole, 7 pour la sécurité et les règles de l’opérateur.

C’est ce deuxième nombre qui vous oriente. Un 5.1.1 est une adresse qui n’existe pas, donc un problème de base de données. Un 5.7.x est un refus de politique, donc un problème de réputation ou d’authentification. Les deux se corrigent dans des services différents de votre entreprise.

Le troisième nombre précise, et c’est là que le terrain devient accidenté.

Le registre, et ce qu’il révèle

Les codes détaillés ne sont pas tous dans la RFC 3463. Elle s’arrête à X.7.7. Tout ce qui suit a été ajouté au fil des années dans un registre tenu par l’IANA, créé en 2008 et mis à jour pour la dernière fois le 6 décembre 2024.

Deux entrées de ce registre méritent le détour, parce qu’elles expliquent une bonne partie de la confusion ambiante.

X.7.26, le code d’échec d’authentification que Gmail renvoie le plus souvent, vient de la RFC 7372, pas de la RFC 3463. Le registre le décrit ainsi : « This status code is returned when a message failed more than one message authentication check, contrary to local policy requirements. »

X.7.28, celui que tout expéditeur de volume finit par rencontrer, est plus surprenant. Sa description est « The message appears to be part of a mail flood of similar abusive messages », sa colonne « Associated basic status code » est vide, et sa référence est un document de travail de l’IETF expiré et archivé.

Le 421 4.7.28 que Gmail vous renvoie n’est donc pas une combinaison normalisée. C’est un usage imposé par un opérateur, sur un code dont la spécification n’a jamais abouti. C’est un bon résumé de ce métier.

Trois opérateurs, trois conventions

Voici le point qui coûte le plus de temps aux équipes techniques : les grands opérateurs ne mettent pas les mêmes codes sur les mêmes causes.

Gmail documente une liste dense, avec une convention d’identification propre : « Gmail appends one or both of these identifiers to all error messages: gsmtp (Google SMTP) is added to all errors. gcdp (Google Custom Domain Policies) is added to errors resulting from customized rules created by a Google Workspace administrator. »

Ce détail vaut de l’or en diagnostic. Un rejet marqué gcdp ne vient pas de la réputation : il vient d’une règle écrite par un administrateur, dans la console d’administration du domaine destinataire. Vous pouvez cesser de chercher du côté de vos enregistrements DNS.

Gmail documente aussi les mêmes causes aux deux niveaux de sévérité, ce qui est une information en soi : 421 4.7.30 pour un échec DKIM temporaire, 550 5.7.30 pour le même échec devenu permanent. La bascule de l’un à l’autre mesure la patience qu’il vous reste.

Yahoo ne publie aucune table de codes étendus. Sa page raisonne en codes de base, et donne une consigne opérationnelle nette : « You should not retry sending an email that comes back with a 5xx error. List managers should have a policy for removing email addresses that generate 5xx errors/bounces. »

Microsoft, enfin, utilise 5.7.23 pour un échec SPF, là où Gmail utilise 5.7.27. Même cause, deux codes. Tout outil qui prétend classer vos rejets par code étendu sans distinguer l’opérateur produit une statistique fausse.

Les quatre codes qui expliquent la majorité des rejets

Sans prétendre à l’exhaustivité, quatre familles couvrent l’essentiel de ce que vous verrez.

5.1.1 et 5.1.10, destinataire inexistant. Ce n’est pas un problème de délivrabilité, c’est un problème d’hygiène de liste. Une adresse qui renvoie ce code doit sortir de la base au premier rejet, ce que la vérification de Sestaro établit avant l’envoi plutôt qu’après, et continuer d’écrire à ces adresses est précisément ce qui vous mène ailleurs.

5.7.26 et 5.7.27, authentification. Gmail écrit alors : « This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. » Le message contient l’adresse IP testée et le domaine évalué. Tout est là pour corriger.

5.7.25, absence d’enregistrement DNS inverse sur l’IP d’envoi. C’est une exigence explicite des lignes directrices, et elle se règle chez l’hébergeur en une demande.

421 4.7.28, limitation de débit. Google donne ici la seule consigne chiffrée de toute sa documentation sur le sujet : « Do not send email for at least 10 minutes. » Réessayer immédiatement aggrave la situation.

Ce que vous faites demain matin

Ouvrez le journal d’envoi de votre serveur ou l’export de rejets de votre prestataire, et classez une journée complète par code étendu, opérateur par opérateur. Pas par taux : par code, en nombre.

Vous obtiendrez presque toujours une distribution très déséquilibrée, dominée par deux ou trois causes. Ces deux ou trois causes sont votre plan de travail, dans l’ordre.

Séparez ensuite ce qui relève de la liste et ce qui relève de l’infrastructure. Les 5.1.x se traitent en supprimant des adresses. Les 5.7.x se traitent en corrigeant des enregistrements DNS ou en réduisant un rythme. Les mélanger, c’est expliquer un problème d’authentification par la qualité de la base, ou l’inverse.

Et gardez le texte complet du rejet, pas seulement le code. Les opérateurs y écrivent le domaine évalué, l’adresse IP testée et parfois le lien vers la règle enfreinte. C’est la documentation la plus précise dont vous disposerez jamais sur votre propre trafic, et elle vous est adressée personnellement.

Sources

LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.