Comment dépanner Gmail SMTP 535 5.7.80 en 2026 ?

Le client affiche « 535 5.7.80 » pendant l’envoi : la connexion existe, mais l’authentification SMTP est refusée.

Cette semaine, vérifiez d’abord le mécanisme AUTH réellement utilisé et l’identité associée aux identifiants ; après correction, contrôlez séparément l’authentification, l’acceptation du message et sa réception.

Cet article s’adresse aux développeurs qui diagnostiquent l’envoi depuis leur propre application de test.
Il est également destiné aux équipes QA qui doivent produire une preuve de réception, et non seulement constater un envoi sans erreur apparente.
Les indépendants qui maintiennent un environnement de test y trouveront aussi des précautions pour protéger les jetons et les liens de validation dans les journaux.

535 5.7.80 : ce que le rejet signifie, et ce qu’il ne prouve pas

Google associe la réponse « 535 5.7.80 » à des identifiants — nom d’utilisateur et mot de passe — que le serveur n’accepte pas. La documentation Google sur les erreurs SMTP Gmail permet donc de situer le problème du côté de l’authentification.

Cette indication ne révèle cependant pas, à elle seule, la cause exacte du refus. Elle ne prouve pas que le mot de passe est simplement mal saisi. Elle ne permet pas non plus de conclure que l’application a envoyé un courriel qui serait ensuite arrivé dans les indésirables. Si le serveur renvoie ce code pendant la phase AUTH, la transaction n’a pas encore atteint l’étape où le message est soumis.

Il faut distinguer trois résultats :

Authentification : le serveur accepte ou refuse les identifiants présentés par le client.
Soumission : après authentification, le client transmet un message et reçoit une réponse du serveur.
Réception : le message apparaît effectivement dans la boîte de contrôle, éventuellement dans un dossier autre que la boîte de réception principale.

Ces étapes répondent à des questions différentes. Un échec à la première ne renseigne pas sur la réception ; une authentification réussie ne garantit pas que le message a été accepté ; une soumission acceptée ne garantit pas que le destinataire l’a vu dans sa boîte de réception.

La distinction correspond aussi aux réponses SMTP documentées par les normes : une réponse 235 indique que l’authentification a réussi, tandis que 535 correspond à un échec d’authentification dans le cadre général de SMTP AUTH. La RFC 4954, qui décrit les réponses de la commande AUTH, ne permet pas pour autant d’identifier la configuration fautive d’un compte Gmail précis. Pour cela, il faut examiner la réponse Google et le comportement réel du client.

Gmail SMTP AUTH : OAuth 2.0 est-il réellement utilisé ?

Ne vous fiez pas au nom d’un paramètre dans un fichier de configuration. Une application peut disposer d’un réglage prévu pour OAuth 2.0 tout en ouvrant réellement la session avec un autre mécanisme AUTH, ou en ne transmettant pas le jeton comme prévu. Le contrôle utile porte sur la négociation effectivement exécutée par le client, pas seulement sur ce que l’équipe pense avoir configuré.

Google documente la prise en charge d’OAuth 2.0 pour SMTP et du mécanisme SASL XOAUTH2 dans sa documentation Gmail sur IMAP, POP et SMTP et dans la description du protocole XOAUTH2. Pour vérifier le chemin utilisé par votre propre produit, procédez ainsi :

Repérez dans la configuration du client le mécanisme d’authentification choisi pour SMTP. Cherchez une indication explicite de XOAUTH2, plutôt qu’une mention générale d’« OAuth ».
Activez, si votre environnement le permet, une journalisation du protocole qui masque les secrets. Elle doit permettre de voir que le client lance AUTH avec le mécanisme attendu, sans enregistrer le jeton lui-même.
Comparez l’identité d’utilisateur transmise par le client à l’adresse du compte pour lequel le jeton a été obtenu.
Vérifiez que le jeton est envoyé comme jeton porteur, selon le format SASL XOAUTH2 décrit par Google. Une chaîne d’authentification mal formée peut échouer même si l’application a obtenu un jeton.
Confirmez que la bibliothèque ou le composant SMTP de votre application utilise bien le chemin d’authentification sélectionné, plutôt qu’une option ignorée ou remplacée par une valeur par défaut.

L’objectif n’est pas de déduire le mécanisme à partir d’une ligne d’erreur isolée. Il est de réunir deux preuves concordantes : la configuration attendue et la commande AUTH effectivement émise. Si le journal ne permet pas de confirmer le mécanisme sans exposer de secret, réduisez le niveau de détail ou ajoutez une trace ciblée dans un environnement contrôlé, puis retirez-la après le diagnostic.

Attention : une capture de session SMTP peut contenir des éléments d’authentification réutilisables. Ne partagez jamais une trace brute ; masquez les jetons, mots de passe et chaînes d’authentification avant tout transfert.

Si le mécanisme observé diffère de celui prévu

Corrigez d’abord le réglage qui détermine la négociation AUTH. Ne modifiez pas simultanément le compte, la bibliothèque et la gestion des jetons : si plusieurs variables changent ensemble, un nouvel essai réussi n’indiquera pas laquelle était en cause. Relancez ensuite un test court et comparez la séquence de commandes avant et après le changement.

Le guide Google sur OAuth 2.0 pour les applications côté serveur décrit le parcours d’autorisation et la gestion des jetons. Il aide à vérifier la manière dont l’application acquiert un jeton, mais ne remplace pas l’inspection de la commande SMTP. Il faut contrôler séparément l’acquisition du jeton et son utilisation effective par le client Gmail SMTP.

Un jeton OAuth valide, mais toujours refusé : quoi contrôler ?

Un jeton obtenu sans erreur ne prouve pas que la session SMTP présente les bons identifiants. Il peut correspondre à une autre adresse, ne pas être transmis dans la connexion testée, ou ne pas disposer de l’autorisation attendue pour l’opération. Évitez donc de traiter « le jeton existe » comme une preuve que l’authentification SMTP doit réussir.

Reprenez la chaîne depuis le début, en conservant une seule variable à la fois :

Identité du compte : comparez l’adresse associée au jeton à celle que le client annonce dans XOAUTH2. Vérifiez les comptes de test et les secrets de déploiement ; une valeur héritée d’un autre environnement est une cause possible à examiner, pas une conclusion automatique.
Autorisation demandée : vérifiez les portées OAuth demandées au moment de l’autorisation et celles réellement accordées. Si l’application a changé de configuration, elle peut encore utiliser un ancien consentement ou un jeton obtenu avant cette modification.
Jeton utilisé pendant le test : établissez que la connexion SMTP emploie le jeton courant, et non une valeur mise en cache ou lue depuis une variable d’environnement différente.
Format de XOAUTH2 : contrôlez l’assemblage de la chaîne SASL et la transmission des caractères de séparation attendus par le protocole. Ne copiez pas dans un ticket ou un journal une chaîne complète contenant un jeton.
Réponse complète du serveur : conservez le code et le texte reçus, avec l’étape de la session où ils apparaissent. Une réponse différente, même si son texte semble proche, ne doit pas être assimilée à 535 5.7.80 sans vérification.

La documentation Google peut présenter plusieurs réponses d’authentification au même endroit. Leur proximité ne signifie pas qu’elles décrivent la même situation. Pour attribuer le refus, partez du code exact renvoyé dans cette session, puis confrontez-le aux paramètres réellement utilisés. La réponse de Google sur 535 5.7.80 est une indication liée à des identifiants non acceptés ; elle n’établit pas une cause unique, par exemple une portée OAuth précise, une expiration ou un défaut de bibliothèque.

C’est aussi une limite importante de la RFC 4954 : elle définit le sens général des réponses SMTP AUTH, pas les règles internes d’autorisation d’un compte Google ni la raison particulière pour laquelle un jeton est refusé. Si les indices divergent, conservez cette incertitude dans le compte rendu au lieu d’annoncer un diagnostic plus précis que les éléments disponibles.

Configuration du client : distinguer une panne de connexion d’un refus AUTH

Avant de modifier les identifiants, confirmez que l’application se connecte au serveur SMTP prévu et qu’elle établit le mode de sécurité attendu par sa configuration. Les documents Gmail décrivent les modalités de connexion prises en charge ; consultez la documentation officielle de Gmail pour SMTP plutôt que de reprendre un paramètre recopié depuis un ancien exemple.

Relevez les éléments suivants dans l’environnement où le défaut apparaît :

le nom d’hôte SMTP réellement utilisé par l’application ;
le mode de connexion sécurisée configuré et la réussite, ou non, de son établissement ;
le mécanisme AUTH effectivement négocié ;
l’adresse de compte présentée par le client ;
la réponse serveur complète et l’étape correspondante.

Une erreur avant l’établissement de la connexion sécurisée ne se diagnostique pas comme un rejet reçu après le début de AUTH. De même, si le serveur répond 535 5.7.80 à l’étape d’authentification, cela signifie que le client a atteint un point différent d’un échec de résolution d’hôte ou de négociation TLS. Cette séparation évite de changer des réglages de transport alors que les traces montrent déjà un refus d’identifiants.

Le cas d’une application de test qui envoie un courriel de validation

Prenons un parcours de test du produit : un compte est créé, l’application demande l’envoi d’un lien de validation, puis le client SMTP répond 535 5.7.80. La bonne conclusion à ce stade est limitée : la tentative de soumission n’a pas franchi l’authentification SMTP observée. Il est prématuré d’accuser le filtrage du destinataire, le contenu du message ou le dossier des indésirables, car le message n’a pas encore été soumis dans cette transaction.

Une fois l’authentification corrigée, le même parcours doit être rejoué avec un identifiant de test que l’équipe peut reconnaître. La vérification de la boîte de destination fait partie du test, mais elle vient après les contrôles de connexion et d’acceptation. Si vous devez choisir cette destination pour un scénario temporaire, notre guide sur le choix d’une adresse de test selon son usage aide à distinguer une boîte de contrôle ponctuelle d’une adresse nécessaire à la récupération durable d’un compte.

Après le rétablissement de l’authentification, comment prouver la réception ?

Procédez par étapes et gardez une trace distincte pour chaque résultat :

Relancez le scénario dans l’environnement autorisé. Utilisez un compte de test de votre propre produit et déclenchez une seule opération identifiable, comme une validation ou une réinitialisation.
Notez le résultat d’AUTH. Une réponse 235 est définie comme une authentification réussie par la RFC 4954. Elle confirme ce point de la session, pas la livraison d’un message.
Vérifiez la soumission. Conservez la réponse retournée après la transmission du message. Une réponse positive 250 du serveur SMTP indique l’acceptation de la transaction à ce stade ; la RFC 5321 sur le protocole SMTP précise la responsabilité du serveur qui accepte un message. Cela ne démontre pas que le message est visible dans la boîte de réception du destinataire.
Examinez l’adresse de contrôle. Cherchez le message dans la boîte prévue et, si nécessaire, dans les dossiers de courrier indésirable ou les autres catégories disponibles. Ne concluez à une réception réelle qu’après avoir observé le message à destination.
Rapprochez les éléments. Utilisez un identifiant de scénario, un sujet de test distinctif ou une autre référence non sensible pour relier le déclenchement du produit, la réponse SMTP et le message reçu.

Cette séquence évite deux faux positifs courants : appeler « succès d’envoi » une authentification qui a simplement abouti, ou appeler « courriel reçu » une soumission acceptée par le serveur. Dans un système distribué, des événements ultérieurs peuvent survenir après l’acceptation SMTP. Il faut donc vérifier la boîte de contrôle plutôt que déduire la réception d’un journal côté application.

Pour les essais qui manipulent des données de compte, utilisez des valeurs fictives et limitez les informations personnelles présentes dans les messages. Notre page consacrée à la protection de la vie privée lors des tests par courriel peut servir de repère pour éviter de mélanger les données de démonstration et celles de personnes réelles.

Outil de décision : quelle vérification lancer ensuite ?

Cochez le premier état qui correspond aux traces de votre session. Appliquez l’action associée, puis rejouez le test avant de passer à l’étape suivante. Cette liste évite de modifier plusieurs paramètres à la fois ou de confondre un rejet d’authentification avec une absence de réception.

[ ] La connexion sécurisée ou la connexion au serveur échoue avant AUTH. Examinez le nom d’hôte réellement contacté et l’établissement du transport ; ne changez pas les identifiants OAuth tant que le client n’atteint pas l’authentification.
[ ] Le client atteint AUTH, mais le mécanisme observé n’est pas XOAUTH2 alors que c’est celui attendu. Corrigez la configuration effective du client, puis vérifiez à nouveau la commande AUTH. Ne concluez pas encore que le compte ou le jeton est en cause.
[ ] XOAUTH2 est observé et le serveur renvoie 535 5.7.80. Comparez l’identité transmise, le compte auquel le jeton correspond, l’autorisation obtenue et le jeton réellement utilisé. Si ces vérifications ne révèlent pas de différence, consignez un refus d’authentification dont la cause précise reste à établir.
[ ] AUTH réussit, mais aucune réponse de soumission n’est enregistrée. Inspectez la suite de la transaction SMTP et la gestion des erreurs de l’application ; l’envoi n’est pas encore validé.
[ ] Le serveur accepte le message, mais la boîte de contrôle reste vide. Passez à l’examen de la réception et de l’acheminement. Ne revenez à l’hypothèse AUTH que si une nouvelle réponse SMTP l’étaye.
[ ] Le message est visible dans la boîte de contrôle. Validez la réception pour ce scénario, cet environnement et ce destinataire seulement ; ne généralisez pas le résultat à tous les parcours ou toutes les boîtes.

L’ordre compte : le premier contrôle non validé détermine la prochaine action. Si la connexion n’atteint pas AUTH, les contrôles sur le contenu du message sont prématurés. Si AUTH réussit, répéter le renouvellement du jeton sans examiner la soumission risque de faire perdre du temps. Si le serveur a accepté le message, mais que la boîte reste vide, la vérification doit porter sur la réception, pas sur une authentification déjà confirmée.

Consigner le diagnostic sans divulguer les secrets

Le compte rendu doit permettre à un collègue de comprendre le défaut sans lui donner les moyens de réutiliser les identifiants. Notez le texte exact de l’erreur, la phase SMTP où elle apparaît, le mécanisme AUTH observé et l’environnement concerné. Ajoutez une référence de test non sensible qui relie l’événement applicatif à la vérification du destinataire.

En revanche, retirez des journaux et des captures les mots de passe, jetons d’accès, chaînes XOAUTH2 et liens de validation complets. Si un lien doit être rapproché du test, conservez un identifiant interne ou une version masquée plutôt que le secret présent dans l’URL.

Pour l’acceptation finale, formulez trois constats distincts : authentification acceptée ou refusée ; message accepté ou non par le serveur SMTP ; message effectivement observé ou non dans la boîte de test. Le dernier constat doit rester limité au scénario exécuté. Un essai réalisé sur une application et un destinataire de contrôle ne garantit pas le comportement de tous les comptes, toutes les configurations ni tous les parcours de production.

Si le test porte seulement sur une inscription temporaire, un essai d’interface ou une vérification de courriel, une adresse de réception temporaire peut compléter votre dispositif de test. SendTmp permet d’obtenir une adresse sans inscription et de l’utiliser immédiatement, sans exposer l’adresse principale aux messages de test. Cette option ne garantit pas que tous les chemins d’envoi fonctionneront ni que chaque message arrivera ; elle sert à vérifier un scénario contrôlé. Pour les comptes importants, les besoins de réponse ou les messages à conserver, préférez une adresse durable que votre équipe contrôle.