SMTP AUTH (OAuth2/XOAUTH2) fails with 535 5.7.139 on personal Outlook.com account while IMAP OAuth2 works fine — is there any supported way to enable it, or is Graph sendMail the only path?

(Please note that this is Spanish Q&A Forum, any threads should be posted in Spanish. However, I will still provide an answer in English based on your initial response.)

Hi, Luis Ernesto Daza Firma

Your OAuth setup appears correct. The delegated SMTP scope is https://outlook.office.com/SMTP.Send, and OAuth2/XOAUTH2 is documented as supported for both Microsoft 365 and Outlook.com users. However, a valid token does not override the mailbox’s SmtpClientAuthenticationDisabled setting. If SMTP AUTH is disabled on the mailbox, the service rejects OAuth2 SMTP with 535 5.7.139 before the message is submitted. Authenticate an IMAP, POP, or SMTP connection using OAuth

There is no documented self-service setting, alternative scope, token audience, or preview flag that lets the owner of a personal Outlook.com mailbox change that backend SMTP AUTH flag. The documented Set-CASMailbox -SmtpClientAuthenticationDisabled $false method applies to Exchange Online organizations and requires administrative access. A consumer Outlook.com user does not have access to Exchange Online PowerShell or the Microsoft 365 admin controls needed to change it. Enable or disable authenticated client SMTP submission

Before abandoning SMTP, I would make one final change: use smtp-mail.outlook.com on port 587 with STARTTLS. That is the SMTP endpoint currently listed for personal Outlook.com accounts, while smtp.office365.com is normally used for Exchange Online organizational mailboxes. Keep the same OAuth scope and XOAUTH2 format. If the supported Outlook.com endpoint returns the same SmtpClientAuthentication is disabled for the Mailbox response, changing the scope, consent, Nodemailer settings, or token will not resolve it. POP, IMAP, and SMTP settings for Outlook.com

For a backend service, Microsoft Graph is therefore the practical supported migration path when SMTP AUTH is disabled. Register the application for personal Microsoft accounts, request the delegated Microsoft Graph Mail.Send permission, obtain the user’s token through an authorization-code flow using common or consumers, and submit through POST /me/sendMail. The Graph documentation specifically lists delegated Mail.Send support for personal Microsoft accounts. The endpoint accepts JSON or MIME messages and normally saves sent messages in Sent Items. Microsoft Graph sendMail

For personal accounts, /me/sendMail is the clearest choice because the token represents the signed-in mailbox owner. Do not redesign this as an app-only, client-credentials service expecting unrestricted access to personal Outlook.com mailboxes. Keep the delegated authorization and refresh-token model you already use, but request the Graph Mail.Send scope and obtain a Graph access token rather than reusing the Outlook-resource token. Access tokens are resource-specific.

I would not describe the behavior as applying uniformly to every Outlook.com account or as a formally announced account-age policy. Current reports show the problem more consistently with recently created consumer mailboxes, while some older accounts continue to accept OAuth2 SMTP. However, the current public documentation still states that Outlook.com supports OAuth2 SMTP and does not publish an account creation date, rollout rule, or consumer control for SmtpClientAuthenticationDisabled. Similar reports from February through August 2026 describe the same new-account pattern, but they do not establish an authoritative universal policy.

So the concise answer is: there is no supported owner-accessible switch to enable mailbox-level SMTP AUTH on an affected personal account. Test once with the documented smtp-mail.outlook.com endpoint. If the same 5.7.139 response remains, move the sending path to delegated Microsoft Graph Mail.Send and /me/sendMail. Graph is a documented API for personal Microsoft accounts, although no public cloud API can be guaranteed never to change. Microsoft normally handles such changes through published deprecation and migration notices rather than promising permanent behavior.

Thank you for your patience in reading, I hope this information has been helpful to you. 

If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment."    

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.