On assimile un bounce mailbox full à une boîte de réception saturée qu’il suffit d’attendre. Dans les logs SMTP d’un expéditeur qui envoie plusieurs dizaines de milliers de messages par jour, le code renvoyé raconte rarement cette histoire. Le code 552 signale un dépassement de stockage permanent au sens strict de la RFC 5321 (IETF, 2008). La majorité des rejets mailbox full observés en production ne relèvent pourtant pas de ce cas : ils viennent d’un compte dormant recyclé par le fournisseur ou d’un throttling de réputation que le FAI habille en quota dépassé. Retenter patiemment un rejet lié au complaint rate revient à cogner contre un mur pendant que le score se dégrade. Certains postmasters ont vu leurs scores seedlist chuter sans explication après la mise à jour Gmail de décembre 2025. Un mailbox full mal lu en est souvent la cause silencieuse.
Ce que dit vraiment le code SMTP renvoyé
L’étiquette générique « mailbox full » cache 2 codes qui ne pèsent pas le même poids. Le code 552, « exceeded storage allocation », est un rejet permanent selon la RFC 5321 publiée par l’IETF en 2008 : renvoyer le même message ne changera rien. Le code 452, « insufficient system storage », décrit un problème transitoire côté serveur, sans lien nécessaire avec le destinataire lui-même. Google distingue les deux dans sa documentation Workspace Admin.
Un message rejeté en 452 4.2.2 pour une boîte au-dessus du quota reste en file d’attente : le serveur d’envoi le retente automatiquement pendant la durée qu’il a configurée, sans que l’expéditeur ait à intervenir. C’est ce que documente Google dans son centre d’aide Workspace Admin dédié aux erreurs SMTP.
Le problème vient de la pratique des fournisseurs, qui n’appliquent pas ces codes de façon homogène. Un même état de fait, une boîte pleine, peut ressortir en 452 chez un fournisseur et en 552 chez un autre. Certains FAI utilisent l’un ou l’autre selon leur politique de rétention interne, sans lien direct avec l’état réel du stockage disque.
Le compte dormant que le fournisseur traite comme plein
Yahoo a lancé un programme de recyclage des comptes inactifs en 2013 : toute adresse non consultée depuis plus d’un an bascule en statut « disabled », puis devient éligible à la réattribution. Pendant cette phase intermédiaire, le compte existe toujours techniquement. Il n’accepte simplement plus de courrier tant que le titulaire d’origine ne s’est pas reconnecté. Le fournisseur pourrait renvoyer un 550 5.1.1 user unknown, message sans ambiguïté. Il choisit souvent un code proche du quota dépassé, une façon de garder la porte entrouverte au cas où le compte serait réactivé.
Cette zone grise complique directement la Suppression List. Une adresse en 452 récurrent depuis 8 semaines sur un domaine Yahoo ou AOL pointe vers un compte mort, géré comme tel par le fournisseur pour des raisons étrangères au volume stocké.
Le throttling de réputation maquillé en quota dépassé
Le code 421 raconte une autre histoire. Google le documente comme un « generic temporary hold », souvent déclenché sur une IP neuve ou une réputation dégradée : le message n’est jamais évalué au niveau de la boîte du destinataire, il est bloqué en amont, au niveau du MTA. Yahoo et AOL appliquent une logique proche avec leurs codes 421 4.7.0 assortis d’un tag interne comme [TSS04] ou [TS01], propres à leurs systèmes de filtrage de réputation. Ce blocage précoce protège le fournisseur : il évite de consommer des ressources à évaluer un message qui finira de toute façon en quarantaine et il donne à l’expéditeur un signal qu’aucun retry immédiat ne peut lever.
Yves-Marie Le Pors-Chauvel, consultant chez Postmastery, notait en juillet 2024 que le taux de deferral, les rejets temporaires cumulés sur une fenêtre donnée, est un indicateur de réputation IP plus fin que le bounce rate lui-même, en particulier pendant une phase de warm-up. Le texte humain du message SMTP porte l’information utile, au-delà de son code numérique à trois chiffres : les formulations « reputation » ou « throttl » dans le corps du rejet trahissent un signal de confiance, « rate limit » aussi. Un MTA qui multiplie ces formulations sur plusieurs domaines destinataires en même temps décrit un problème d’émission, jamais un problème de stockage isolé chez un destinataire.
Distinguer les 3 cas en production : la méthode
4 vérifications suffisent pour trancher : le texte du message, le croisement avec Postmaster Tools ou SNDS, la récurrence sur plusieurs IP et l’historique d’engagement de l’adresse. La documentation postmaster de Google confirme que 452 4.2.2 correspond à un compte au-dessus du quota. Elle ne dit rien du taux de récidive qui permet de repérer un rejet de réputation déguisé en quota dépassé : cette lecture se fait dans les logs d’envoi ; aucune documentation générique ne la remplace.
- Lire le texte humain du message SMTP au-delà du code à trois chiffres : la présence de « quota » ou « storage » oriente vers une capacité réelle, celle de « reputation » ou « throttl » vers autre chose, « rate » y compris.
- Croiser le rejet avec Google Postmaster Tools ou le SNDS de Microsoft : une chute de l’IP reputation tier sur la même fenêtre temporelle confirme un throttling plutôt qu’un quota isolé.
- Observer la récurrence sur plusieurs jours et sur plusieurs IP du même pool d’envoi : un quota réellement plein reste isolé à une adresse précise, un throttling de réputation touche l’ensemble du flux.
- Vérifier l’historique d’engagement de l’adresse concernée, dernier clic ou ouverture connu, pour repérer un compte dormant plutôt qu’un incident ponctuel isolé.
Ce que ça change pour la stratégie de retry
Un quota transitoire justifie un retry classique : plusieurs tentatives échelonnées sur 24 à 72 heures, puis suppression si le rejet persiste au-delà. Un throttling de réputation appelle une réponse différente. Retenter la même adresse ne sert à rien puisque le rejet ne dépend pas d’elle. Ralentir le débit d’envoi sur l’ensemble du pool d’IP ou isoler un volume plus faible sur une IP dédiée corrige la cause réelle du blocage. Un pool de 10 IP mutualisées absorbe un throttling temporaire mieux qu’une IP unique : la charge se redistribue pendant que la moins bien notée récupère sa réputation sur quelques jours. Sur une IP dédiée isolée, ce filet de sécurité n’existe pas ; réduire le volume et attendre que le score remonte reste le seul levier disponible. Confondre les deux traitements revient à laisser grimper le complaint rate pendant qu’on attend patiemment qu’une boîte se libère, alors qu’elle n’existe peut-être plus.
Pour un compte identifié comme dormant, aucun retry n’a de sens. L’adresse rejoint la suppression immédiate, au même titre qu’un hard bounce classique. L’hygiène de la base avant l’envoi, celle qui consiste à retirer les adresses invalides avant chaque campagne, reste traitée en détail dans notre guide sur la réduction du taux de hard bounce. Le diagnostic porte ici sur le signal lui-même, une fois qu’il arrive dans les logs.
Le signal qui protège la réputation avant le hard bounce
Le rapport Validity 2025 situe le seuil d’alerte du bounce rate à 2 % et le seuil de blocage informel autour de 5 %. Ces seuils mesurent uniquement le bounce confirmé. Le deferral reste hors radar dans la plupart des tableaux de bord, alors qu’il précède souvent de plusieurs jours la dégradation observée par Postmastery.
Cette grille de lecture demande du volume. Sur une liste de quelques centaines de contacts, la récurrence ne se mesure pas : un seul mailbox full reste un seul mailbox full, sans motif statistique à en tirer.
Sur un pool qui dépasse quelques dizaines de milliers d’envois quotidiens, vérifier un échantillon d’adresses suspectées mortes avant de les resservir en campagne reste le seul moyen de confirmer qu’un compte recyclé en mailbox full n’est pas redevenu actif entre-temps.
Ce que les fournisseurs ne documentent pas encore
Aucun grand FAI ne publie de politique claire sur la durée de la phase « disabled » avant réattribution d’une adresse. Yahoo évoque un délai autour de 12 mois, sans engagement contractuel écrit. Google et Microsoft restent silencieux sur ce point précis dans leur documentation postmaster respective. Ni l’un ni l’autre ne précise combien de temps un compte recyclable peut répondre en mailbox full avant d’être classé définitivement mort et retiré de la circulation : en pratique, c’est à l’expéditeur de le repérer dans ses propres logs avant que le fournisseur ne tranche à sa place.
