Microsoft 365 « 535 5.7.139 Authentication unsuccessful » : comment corriger

Ce que ça veut dire

Votre application, votre site, votre imprimante ou votre script s'est connecté à Microsoft 365 (smtp.office365.com) pour envoyer un email et a tenté de s'authentifier avec un nom d'utilisateur et un mot de passe. Microsoft a refusé la connexion. L'erreur revient pendant l'échange SMTP, avant l'envoi du moindre email. Les variantes les plus courantes sont :

535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant.
535 5.7.139 Authentication unsuccessful, the user credentials were incorrect.
535 5.7.139 Authentication unsuccessful, user is locked by your organization's security defaults policy.
535 5.7.139 Authentication unsuccessful, the request did not meet the criteria to be authenticated successfully.

Le texte après la virgule indique quel réglage a bloqué la connexion : lisez-le attentivement. Ce mode d'envoi avec identifiant s'appelle SMTP AUTH (ou « authenticated client submission »), généralement sur le port 587.

Pourquoi cela arrive

• SMTP AUTH est désactivé pour toute l'organisation (le tenant) ou pour cette boîte mail. Microsoft recommande de le laisser désactivé et de ne l'activer que pour les comptes qui en ont besoin, et l'a déjà désactivé dans les tenants qui ne l'utilisaient pas.
• Les security defaults sont activés dans Microsoft Entra ID. La documentation de Microsoft indique qu'avec les security defaults activés, SMTP AUTH est désactivé, même si vous l'activez sur une boîte mail.
• L'authentification de base est bloquée par une stratégie d'authentification ou une stratégie d'accès conditionnel (Conditional Access) qui bloque la « legacy authentication ». Le message indique alors généralement que la requête « did not meet the criteria ».
• Mauvais identifiants ou MFA. Un mot de passe faux ou expiré, ou un compte protégé par l'authentification multifacteur, ne peut pas se connecter avec un simple mot de passe. Les mots de passe d'application ne fonctionnent plus avec l'authentification de base.
• Le compte n'a pas de boîte mail utilisable : pas de licence Exchange Online, ou une boîte partagée dont la connexion est bloquée.

La fin de l'authentification de base

Microsoft retire l'authentification de base (un simple nom d'utilisateur et mot de passe) pour SMTP AUTH. Le calendrier a changé plusieurs fois. Au moment où nous écrivons ces lignes, la dernière annonce de Microsoft (janvier 2026) indique que le comportement reste inchangé jusqu'en décembre 2026 ; fin décembre 2026, l'authentification de base pour SMTP AUTH sera désactivée par défaut pour les tenants existants, les administrateurs pourront encore la réactiver, et une date de suppression définitive sera annoncée au second semestre 2027. Consultez le blog de l'équipe Exchange pour les dates à jour. La solution durable est OAuth 2.0 (« authentification moderne »).

Comment vérifier

1. Copiez l'erreur complète depuis le log de votre application. La partie après « Authentication unsuccessful » oriente vers la cause.
2. Dans Exchange Online PowerShell, vérifiez les réglages de l'organisation et de la boîte mail :

   Connect-ExchangeOnline
   Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
   Get-CASMailbox -Identity app@yourdomain.com | Format-List SmtpClientAuthenticationDisabled

   True signifie désactivé. Sur la boîte mail, une valeur vide signifie « suivre le réglage de l'organisation ».
3. Dans le centre d'administration Microsoft 365, allez dans Users > Active users, sélectionnez le compte, puis Mail > Manage email apps et regardez Authenticated SMTP.
4. Dans le centre d'administration Microsoft Entra, vérifiez si les security defaults sont activés et si une stratégie Conditional Access bloque la legacy authentication. Les journaux de connexion Entra montrent la tentative échouée et la stratégie qui l'a bloquée.
5. Testez à la main avec swaks (vous verrez la réponse exacte du serveur) :

   swaks --server smtp.office365.com --port 587 --tls \
     --auth LOGIN --auth-user app@yourdomain.com --auth-password 'your-password' \
     --from app@yourdomain.com --to you@example.com

Si le serveur répond plutôt que vous devez vous authentifier avant MAIL FROM, votre outil ne se connecte pas du tout : voir 530 5.7.57 Client not authenticated.

Comment corriger

Meilleure option : passer l'application en OAuth 2.0

Si votre application propose une connexion « Microsoft 365 / OAuth », utilisez-la. Microsoft explique comment enregistrer une application dans Microsoft Entra ID et utiliser OAuth avec SMTP AUTH. Dans nodemailer, par exemple, vous transmettez un jeton d'accès au lieu d'un mot de passe :

const transporter = nodemailer.createTransport({
  host: 'smtp.office365.com',
  port: 587,
  secure: false,       // STARTTLS on port 587
  requireTLS: true,
  auth: { type: 'OAuth2', user: 'app@yourdomain.com', accessToken: token }
});

Pour votre propre code, envoyer via l'API Microsoft Graph (sendMail) évite complètement SMTP AUTH.

Si vous devez garder un mot de passe pour l'instant

1. Activez SMTP AUTH uniquement pour la boîte mail qui envoie, pas pour toute l'organisation :

   Set-CASMailbox -Identity app@yourdomain.com -SmtpClientAuthenticationDisabled $false

2. Si les security defaults sont activés, SMTP AUTH reste bloqué. L'alternative consiste à remplacer les security defaults par des stratégies Conditional Access (licence Entra ID P1 nécessaire) qui exigent toujours la MFA pour les personnes mais autorisent ce seul compte de service. Mesurez l'impact sur la sécurité avant de changer cela.
3. Utilisez une boîte mail dédiée avec un mot de passe long et unique, une licence et aucune demande de MFA, et vérifiez que l'application utilise le port 587 avec STARTTLS (le TLS implicite sur le port 465 n'est pas ce que Microsoft documente pour ce serveur).
4. Les changements ne sont pas instantanés : laissez passer un peu de temps (souvent jusqu'à une heure) avant de retester.

Appareils incapables de gérer OAuth

Les anciennes imprimantes et anciens scanners ne gèrent souvent qu'un mot de passe. Au lieu de SMTP AUTH, ils peuvent envoyer via un connecteur de relais SMTP (depuis une IP publique fixe) ou en direct send vers votre point de terminaison MX. Les deux options sont comparées dans le guide 5.7.57.

Vérifier que c'est corrigé

• Envoyez un email depuis l'application à l'adresse unique affichée sur la page d'accueil de Delivmail. S'il arrive, la connexion fonctionne ; le rapport indique aussi si SPF, DKIM et DMARC passent pour votre domaine via Microsoft 365. Sinon, suivez SPF, DKIM et DMARC pour Microsoft 365.
• Envoyez ensuite un vrai email au destinataire qui aurait dû le recevoir.
• Planifiez dès maintenant le passage à OAuth, pour que le changement sur l'authentification de base ne casse pas l'application plus tard.