Les seuils sont publics depuis février 2024 : les directives expéditeurs de Gmail fixent un hard requirement à 0,3 % de plaintes spam, et la majorité des plateformes considèrent qu’un taux de hard bounce au-dessus de 2 % par campagne déclenche un throttling. Le code SMTP 501 fait partie des rebonds permanents qui pèsent dans ce calcul, et il ment par omission. Sa vraie nature se cache dans le sous-code Enhanced Status qui suit : 5.1.3, 5.1.7, 5.5.4 ou d’autres variantes selon le serveur destinataire. Chaque sous-code a une cause distincte et une correction qui ne ressemble pas à la précédente. Relancer l’envoi sans avoir lu ce sous-code revient à envoyer un second hard bounce dans votre file, ce qui aggrave directement votre sender reputation.
Ce que signifie vraiment le code 501
Un code SMTP qui commence par 5 est un rejet permanent. Le serveur distant dit : il ne tentera pas de relivrer ce message, ni maintenant, ni plus tard. Contrairement aux erreurs 4xx (temporaires), un 501 ne se résout pas en attendant ou en relançant l’envoi à l’identique.
La syntaxe complète d’un message d’erreur 501 ressemble à ceci dans votre NDR (Non-Delivery Report) :
501 5.1.3 Invalid address format
Le premier chiffre (5) indique le rejet permanent. Le second chiffre indique la catégorie de l’erreur Enhanced Status : 1 = problème d’adresse, 5 = problème de protocole ou de syntaxe de commande. Le troisième chiffre affine le diagnostic exact. C’est cette combinaison à trois chiffres, après le code 501, qui doit guider votre correction.
À l’usage, on constate que beaucoup d’équipes lisent le « 501 » et s’arrêtent là. Le sous-code disparaît dans la logique de reporting des ESPs (Email Service Providers). Résultat : elles traitent un problème d’expéditeur comme un problème de destinataire ou l’inverse.
Sous-code 5.1.3 : format d’adresse destinataire invalide
Le sous-code 5.1.3 signale que l’adresse du destinataire contient une erreur de format que le serveur SMTP distant refuse de traiter. Le serveur ne cherche pas à savoir si cette boîte existe réellement : il a détecté une anomalie syntaxique avant même d’arriver à cette étape.
Les causes les plus fréquentes :
- Double arobase :
prenom@domaine@example.com - Domaine manquant :
prenom.nom@ - Caractères interdits dans la partie locale (espaces non encodés, parenthèses, crochets hors guillemets)
- Extension de domaine absente :
prenom@domaine - Point en début ou fin de partie locale :
.prenom@domaine.com
Ces adresses entrent dans vos listes via des formulaires sans validation côté serveur, via des importations CSV mal nettoyées ou via des saisies manuelles en base CRM. La correction ne se fait pas côté SMTP : elle se fait en amont, avant l’envoi.
Pour corriger : passez votre liste à travers un validateur de format qui applique la syntaxe RFC 5321 avant chaque campagne. Les adresses 5.1.3 sont récupérables : soit on retrouve l’adresse correcte en contactant le lead par un autre canal, soit on supprime définitivement le contact de la liste. Le conserver avec ce statut garantit un hard bounce lors du prochain envoi.
Sous-code 5.1.7 : adresse expéditeur incorrecte ou refusée
Ici le problème change de camp. Le sous-code 5.1.7 concerne l’adresse de l’expéditeur, pas du destinataire. Le serveur distant a refusé votre commande MAIL FROM parce que l’adresse d’envoi n’est pas valide selon ses critères.
Ce sous-code apparaît dans deux situations distinctes. Première situation : votre adresse d’expédition contient elle-même une erreur de format (domaine inexistant, syntaxe invalide). Deuxième situation : le serveur destinataire applique une politique stricte qui bloque les expéditeurs dont l’adresse From ou Return-Path ne passe pas les contrôles d’authentification.
Un 5.1.7 peut donc trahir un problème SPF mal configuré sur votre domaine d’envoi. Si votre enregistrement SPF n’inclut pas l’adresse IP ou le domaine de votre ESP, certains serveurs receveurs rejettent la commande MAIL FROM avec ce sous-code plutôt qu’avec un 550 classique.
La vérification à faire en priorité : ouvrez le NDR complet et repérez l’adresse signalée. Si c’est votre Return-Path (adresse technique de rebond), contrôlez que votre enregistrement SPF inclut bien le domaine de votre plateforme d’envoi. Si c’est votre adresse From visible, vérifiez que le domaine d’envoi correspond à votre domaine SPF autorisé.
Vérifiez aussi votre alignement DMARC : un expéditeur dont le domaine From diffère du domaine SPF (ou DKIM) peut déclencher des rejets 5.1.7 sur les serveurs qui appliquent une politique DMARC stricte côté réception.
Sous-code 5.5.4 : commande SMTP invalide
Le sous-code 5.5.4 diffère des deux précédents. Il ne concerne plus l’adresse mais la commande SMTP elle-même. Le serveur distant a reçu une commande malformée ou des paramètres qu’il ne reconnaît pas.
En pratique, ce sous-code apparaît rarement sur les envois standards via un ESP réputé (Brevo, Mailgun, Postmark, Amazon SES). Il est plus courant quand vous envoyez via un serveur SMTP maison, un relais SMTP configuré manuellement ou une intégration API qui construit la session SMTP directement.
Les causes typiques d’un 5.5.4 :
- En-têtes SMTP mal formatés (encodage incorrect dans le
EHLOou leMAIL FROM) - Paramètres non supportés passés dans la commande (ex. extensions SMTP non négociées via
EHLO) - Incohérence entre le nom d’hôte annoncé dans
EHLOet l’adresse IP du serveur d’envoi - Connecteur ou middleware qui insère des caractères de contrôle dans la session
La correction passe par les logs SMTP bruts, pas par le NDR seul. Activez le mode debug sur votre serveur ou relais pour capturer la transaction complète et identifier la commande exacte qui provoque le rejet.
Autres variantes 501 : lire le message texte
Tous les serveurs n’implémentent pas les codes Enhanced Status de manière uniforme. Certains retournent un 501 sans sous-code ou avec un sous-code propriétaire (5.0.0, 5.7.1, etc.). Dans ce cas, le diagnostic repose entièrement sur le message texte qui accompagne le code.
Quelques exemples de messages 501 sans sous-code standardisé que vous pouvez rencontrer :
501 Syntax: MAIL FROM: <address>, problème de format dans la commande MAIL FROM, côté expéditeur501 Bad recipient address syntax, variante de 5.1.3, problème côté destinataire501 Domain must be present in address, domaine absent dans l’adresse, variante 5.1.3501 Too many invalid addresses, le serveur a atteint son seuil de tolérance pour une session avec plusieurs destinataires invalides
Ce dernier cas mérite attention. Si votre liste contient un fort taux d’adresses invalides sur un même domaine destinataire, certains serveurs bloquent la session entière après N erreurs consécutives. Vous obtenez alors un 501 sur des adresses qui auraient pu passer. Le taux de hard bounce apparent dépasse alors le taux d’adresses réellement invalides.
Lire le NDR pour identifier le bon sous-code
Votre ESP vous remonte généralement un résumé de l’erreur. Ce résumé est souvent tronqué. Pour diagnostiquer correctement, vous avez besoin du NDR complet.
Sur Gmail / Google Workspace : le NDR arrive dans la boîte de l’expéditeur. Ouvrez le message, cliquez sur les trois points en haut à droite, sélectionnez Afficher l’original. Le code SMTP complet apparaît dans l’en-tête Diagnostic-Code.
Sur Outlook / Exchange : même principe. Le NDR contient une section Diagnostic information for administrators avec le code complet retourné par le serveur distant.
Sur votre ESP (Brevo, Mailchimp, Postmark) : allez dans l’activité du message ou dans le rapport de bounce. La plupart des ESPs exposent le code Enhanced Status et le message texte brut dans la fiche d’activité de chaque envoi. Si votre ESP ne le montre pas, exportez les logs d’activité et filtrez sur le code 501.
Une fois le sous-code identifié, appliquez la correction correspondante. Corriger l’adresse pour les 5.1.3, corriger l’expéditeur ou le SPF pour les 5.1.7, corriger la session SMTP pour les 5.5.4.
Éviter les 501 avant l’envoi : vérification des adresses
La correction après bounce est coûteuse : un hard bounce enregistré, un contact à éliminer, une réputation IP légèrement entamée. La prévention agit plus tôt dans le cycle.
Pour les erreurs 5.1.3 (format d’adresse invalide), la vérification syntaxique avant import est une première barrière. Elle attrape les doubles arobasques, les domaines absents et les caractères interdits. Elle ne coûte rien et s’applique à l’import du fichier ou à la soumission du formulaire.
Pour aller plus loin, une vérification SMTP live (ping du serveur destinataire sans envoyer de message) permet de détecter les domaines qui n’existent pas ou qui n’acceptent plus de mail, catégorie qui génère aussi des bounces 5.1.x. Des services comme Captain Verify combinent la vérification syntaxique, la résolution DNS et le ping SMTP en une seule passe, avec un résultat par adresse qui distingue les catchall, les invalides et les valides.
Pour les erreurs 5.1.7, la prévention passe par un audit de votre configuration d’authentification (SPF, DKIM, alignement DMARC) avant de toucher à la liste. Un domaine d’envoi mal configuré génère des 5.1.7 quelle que soit la qualité de vos adresses destinataires.
Une list hygiene régulière, suppression des bounces, des inactifs longue durée et des catchall non vérifiés, réduit la probabilité d’accumulation de 501 en session.
Ce que les guides ne disent pas : l’effet d’accumulation sur la réputation
Un 501 isolé ne détruit pas une réputation. Le problème arrive quand ils s’accumulent sur plusieurs campagnes consécutives depuis la même IP ou le même domaine d’envoi. Gmail Postmaster Tools et Microsoft SNDS tracent le taux de rejets permanents par domaine expéditeur. Un taux de hard bounce supérieur à 2 % sur une campagne suffit pour déclencher un throttling ou un blocage temporaire de la part de certains serveurs.
Ce que la plupart des guides sur les erreurs SMTP ne précisent pas : les serveurs destinataires communiquent entre eux via les systèmes de réputation partagée (Spamhaus, Senderscore, Microsoft SNDS). Un expéditeur qui accumule des bounces permanents sur Gmail peut voir son IP warmup compromis sur Outlook quelques semaines plus tard, même s’il n’a jamais eu de problème direct avec ce serveur.
La bonne pratique, telle que documentée dans les directives expéditeurs Gmail mises à jour en 2024, recommande de maintenir le taux de spam sous 0,1 % et fixe le seuil dur de rejet à 0,3 %. La tolérance sur les rejets permanents répétés est dans le même ordre de grandeur.
Un 501 se lit. Trente secondes de plus qu’ignorer le rebond. C’est la seule différence entre une correction qui tient et une réexpédition qui aggrave.
