Microsoft 365 "535 5.7.139 Authentication unsuccessful": how to fix it

What it means

Your application, website, printer or script connected to Microsoft 365 (smtp.office365.com) to send an email and tried to log in with a username and password. Microsoft refused the login. The error comes back during the SMTP conversation, before any email is sent. The most common variants are:

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.

The text after the comma tells you which setting blocked the login, so read it carefully. Logging in to send mail like this is called SMTP AUTH (or "authenticated client submission"), usually on port 587.

Why it happens

• SMTP AUTH is turned off for the whole organization (tenant) or for that mailbox. Microsoft recommends keeping it off and enabling it only for the accounts that need it, and it already turned it off in tenants that were not using it.
• Security defaults are on in Microsoft Entra ID. Microsoft's documentation says that with security defaults enabled, SMTP AUTH is disabled, even if you enable it on a mailbox.
• Basic authentication is blocked by an authentication policy or a Conditional Access policy that blocks "legacy authentication". The message then usually says the request "did not meet the criteria".
• Wrong credentials or MFA. A wrong password, an expired password, or an account protected by multifactor authentication cannot log in with a simple password. App passwords do not work with Basic authentication any more.
• The account has no usable mailbox: no Exchange Online license, or a shared mailbox whose sign-in is blocked.

The Basic authentication retirement

Microsoft is retiring Basic authentication (a plain username and password) for SMTP AUTH. The timeline has moved several times. At the time of writing, Microsoft's latest announcement (January 2026) says the behavior stays unchanged until December 2026; at the end of December 2026, Basic authentication for SMTP AUTH becomes disabled by default for existing tenants, admins can still re-enable it, and a final removal date will be announced in the second half of 2027. Check the Exchange Team blog for the current dates. The long-term fix is OAuth 2.0 ("modern authentication").

How to check

1. Copy the full error from your application's log. The part after "Authentication unsuccessful" points to the cause.
2. In Exchange Online PowerShell, check the organization and mailbox settings:

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

   True means disabled. On the mailbox, an empty value means "follow the organization setting".
3. In the Microsoft 365 admin center, go to Users > Active users, select the account, then Mail > Manage email apps and look at Authenticated SMTP.
4. In the Microsoft Entra admin center, check whether security defaults are enabled and whether a Conditional Access policy blocks legacy authentication. The Entra sign-in logs show the failed attempt and the policy that blocked it.
5. Test by hand with swaks (you will see the exact server answer):

   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

If the server instead answers that you must authenticate before MAIL FROM, your tool is not logging in at all: see 530 5.7.57 Client not authenticated.

How to fix it

Best option: switch the app to OAuth 2.0

If your application supports "Microsoft 365 / OAuth" sign-in, use it. Microsoft documents how to register an app in Microsoft Entra ID and use OAuth with SMTP AUTH. In nodemailer, for example, you pass an access token instead of a password:

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 }
});

For your own code, sending through the Microsoft Graph API (sendMail) avoids SMTP AUTH completely.

If you must keep a password for now

1. Enable SMTP AUTH only for the mailbox that sends, not for the whole organization:

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

2. If security defaults are on, SMTP AUTH stays blocked. The alternative is to replace security defaults with Conditional Access policies (this needs Entra ID P1 licensing) that still require MFA for people but allow this one service account. Think about the security impact before changing this.
3. Use a dedicated mailbox with a long, unique password, a license, and no MFA prompt, and make sure the app uses port 587 with STARTTLS (port 465 implicit TLS is not what Microsoft documents for this endpoint).
4. Changes are not instant: allow some time (often up to an hour) before testing again.

Devices that cannot do OAuth

Old printers and scanners often only support a password. Instead of SMTP AUTH, they can send through an SMTP relay connector (from a fixed public IP) or direct send to your MX endpoint. Both options are compared in the 5.7.57 guide.

Check that it is fixed

• Send an email from the application to the unique address shown on the Delivmail home page. If it arrives, the login works; the report also shows whether SPF, DKIM and DMARC pass for your domain through Microsoft 365. If they do not, follow SPF, DKIM and DMARC for Microsoft 365.
• Then send a real email to the recipient that should have received it.
• Plan the move to OAuth now, so the Basic authentication change does not break the app later.