Gmail SMTP « 535-5.7.8 Username and Password not accepted » (et 534-5.7.9) : la solution

Ce que ça veut dire

Votre application, votre site, votre imprimante ou votre serveur mail a tenté de se connecter au serveur SMTP de Gmail (smtp.gmail.com) et Google a refusé la connexion. Aucun email n'a été envoyé. Les deux réponses les plus courantes sont :

535-5.7.8 Username and Password not accepted. For more information, go to
535 5.7.8  https://support.google.com/mail/?p=BadCredentials

534-5.7.9 Application-specific password required. For more information, go to
534 5.7.9  https://support.google.com/mail/?p=InvalidSecondFactor

535-5.7.8 signifie que le couple nom d'utilisateur et mot de passe a été refusé. 534-5.7.9 est plus précis : le compte utilise la validation en deux étapes, donc Google n'accepte pas le mot de passe normal du compte en SMTP et exige un mot de passe d'application à la place. Une troisième variante, 534-5.7.14 « Please log in through your web browser », signifie que Google a bloqué la connexion comme suspecte jusqu'à ce que vous vous connectiez depuis un navigateur.

Pourquoi cela arrive

Google n'accepte plus le mot de passe normal d'un compte pour le SMTP, l'IMAP ou le POP depuis des applications tierces (les fameuses « applications moins sécurisées »). Cette possibilité a été désactivée pour les comptes Gmail personnels en 2022, et pour tous les comptes Google Workspace le 14 mars 2025. Seules deux méthodes fonctionnent encore :

• OAuth 2.0 (connexion avec Google, puis l'application utilise un jeton). C'est ce que Google recommande.
• Les mots de passe d'application : un mot de passe de 16 caractères généré pour une seule application. Ils n'existent que sur les comptes où la validation en deux étapes est activée.

Les causes habituelles sont donc :

• Vous avez saisi votre mot de passe Gmail normal dans l'application (534-5.7.9 si la validation en deux étapes est activée, 535-5.7.8 sinon).
• Le mot de passe d'application a été révoqué. Changer le mot de passe de votre compte Google révoque tous les mots de passe d'application.
• Le nom d'utilisateur est faux : ce doit être l'adresse complète, par exemple you@gmail.com ou you@yourdomain.com.
• Des espaces ou une faute de frappe en collant le mot de passe d'application, ou un ancien mot de passe encore en cache dans l'application.
• Les mots de passe d'application ne sont pas disponibles pour le compte : pas de validation en deux étapes, Protection avancée activée, ou politique d'un administrateur Google Workspace qui ne les autorise pas.

Comment vérifier

1. Connectez-vous sur myaccount.google.com, ouvrez Sécurité (Security) et vérifiez si la validation en deux étapes est activée et si les mots de passe d'application sont proposés.
2. Testez la connexion depuis un terminal avec swaks (remplacez les valeurs, utilisez le mot de passe d'application) :

   swaks --server smtp.gmail.com:587 --tls \
     --auth LOGIN --auth-user you@gmail.com --auth-password 'abcdabcdabcdabcd' \
     --from you@gmail.com --to you@gmail.com

   Une réponse 235 2.7.0 Accepted signifie que les identifiants fonctionnent et que le problème vient des réglages de votre application.
3. Une fois l'envoi fonctionnel, envoyez un test à l'adresse unique de la page d'accueil de Delivmail et vérifiez SPF, DKIM et DMARC pour votre adresse From.

Comment corriger

Option 1 : utiliser OAuth 2.0 (le mieux)

Si votre logiciel propose « Se connecter avec Google » ou une option OAuth pour Gmail (la plupart des clients mail, beaucoup de plugins SMTP pour WordPress, nodemailer, PHPMailer), utilisez-la. Vous créez des identifiants OAuth dans un projet Google Cloud, puis l'application envoie avec un jeton. Aucun mot de passe n'est stocké, et cela continue de fonctionner après un changement de mot de passe.

Option 2 : utiliser un mot de passe d'application

1. Activez la validation en deux étapes sur le compte Google.
2. Créez un mot de passe d'application dans les réglages de votre compte Google (cherchez « Mots de passe des applications » ou « App passwords » dans la barre de recherche du compte). Donnez-lui un nom, par exemple « Site web ».
3. Collez les 16 caractères dans votre application, sans espaces, comme mot de passe SMTP. Gardez l'adresse complète comme nom d'utilisateur.

Exemple avec nodemailer :

const transporter = nodemailer.createTransport({
  host: 'smtp.gmail.com',
  port: 465,
  secure: true,          // or port 587 with secure: false (STARTTLS)
  auth: { user: 'you@gmail.com', pass: process.env.GMAIL_APP_PASSWORD }
});

Pour les sites PHP, les mêmes valeurs vont dans PHPMailer ; les autres erreurs de connexion y sont traitées dans PHPMailer « SMTP Error: Could not authenticate ». Les imprimantes et scanners sont traités dans scan-to-email avec Office 365 ou Gmail.

Google Workspace : pensez au relais SMTP

Pour un appareil ou un serveur qui ne gère pas OAuth et ne doit pas détenir le mot de passe d'un utilisateur, un administrateur Workspace peut utiliser à la place le service de relais SMTP (smtp-relay.gmail.com) avec une authentification par adresse IP. Ses propres erreurs sont traitées dans relais SMTP Google Workspace « 550 5.7.0 Mail relay denied ».

534-5.7.14

Connectez-vous au compte dans un navigateur, si possible depuis le même réseau, confirmez l'éventuelle alerte de sécurité (« Oui, c'était moi »), puis réessayez. Si cela se reproduit, passez à OAuth ou à un mot de passe d'application.

N'oubliez pas que les comptes Gmail ont des limites d'envoi quotidiennes ; un envoi en masse via smtp.gmail.com finit en « 550 5.4.5 Daily user sending limit exceeded ».

Vérifier que c'est corrigé

Envoyez un message depuis l'application à l'adresse unique de la page d'accueil de Delivmail. S'il arrive, la connexion fonctionne. Lisez le rapport : quand vous envoyez via Gmail avec votre propre domaine, le DKIM doit être signé par votre domaine (à configurer dans la console d'administration Workspace), et SPF et DMARC doivent passer. Relancez ensuite l'envoi d'origine.