Forum Discussion

barooder's avatar
barooder
Copper Contributor
Sep 23, 2026

Need help with scan-to-email function on printer

Exchange Online SMTP AUTH returns 535 even though SMTP AUTH is enabled

I'm troubleshooting SMTP AUTH for a Ricoh MP C2011 multifunction printer that needs to send scanned documents through Microsoft 365.

The Ricoh is configured for:

  • SMTP server: smtp.office365.com
  • Port: 587
  • STARTTLS/TLS
  • SMTP authentication enabled
  • Username: full Microsoft 365 email address

The Ricoh consistently reports:

SMTPC: username or password wasn't correct. [535] (5001)

Initially I suspected the printer/network, but I have now reproduced the authentication failure independently from PowerShell.

A direct SMTP test using Send-MailMessage against smtp.office365.com:587 returns:

5.7.57 Client not authenticated to send mail. Error: 535 5.7.3 Authentication unsuccessful

The SMTP server is definitely reachable. Test-NetConnection smtp.office365.com -Port 587 succeeds.

I also performed a raw SMTP/STARTTLS capability test. The server responds:

220 ... Microsoft ESMTP MAIL Service ready

STARTTLS succeeds with TLS 1.2, and after TLS the server advertises:

250-AUTH LOGIN XOAUTH2

So the server is offering both LOGIN and OAuth authentication to my connection.

Exchange Online configuration

Using Exchange Online PowerShell:

Get-TransportConfig SmtpClientAuthenticationDisabled : False AllowLegacyTLSClients : True

For the test mailbox:

Get-CASMailbox SmtpClientAuthenticationDisabled : False

I explicitly set the test mailbox to:

Set-CASMailbox email address removed for privacy reasons -SmtpClientAuthenticationDisabled $false

and verified it returns False.

There is no authentication policy assigned:

AuthenticationPolicy :

There is also no organization-wide default authentication policy:

DefaultAuthenticationPolicy :

and:

Get-AuthenticationPolicy

returns no policies.

Security Defaults are disabled.

Test mailbox

To rule out the original mailbox, I created a completely new Exchange Online mailbox.

I can log into Outlook on the web with this account.

I tested:

  • Normal mailbox password
  • App password
  • MFA enabled
  • MFA disabled

All combinations still produce the SMTP authentication failure.

After disabling MFA on the test mailbox, the SMTP test still returned:

5.7.57 Client not authenticated to send mail. 535 5.7.3 Authentication unsuccessful

So MFA does not appear to be the cause.

Printer/network testing

The Ricoh MP C2011 also produces the same type of 535 response.

The network itself appears to be fine. TCP 587 is reachable, TLS 1.2 negotiation succeeds from the PC, and Microsoft returns SMTP responses.

I also tested the legacy endpoint:

smtp-legacy.office365.com

The Ricoh eventually reached it but still received:

535 username or password wasn't correct. [535] (5001)

Exchange Online reports:

AllowLegacyTLSClients : True

What I'm trying to determine

I'm trying to understand why Exchange Online is rejecting SMTP AUTH LOGIN when:

  • Organization SMTP AUTH = enabled
  • Mailbox SMTP AUTH = enabled
  • No authentication policy exists
  • Security Defaults = disabled
  • MFA disabled for the test account
  • Test mailbox is valid and accessible through Outlook on the web
  • smtp.office365.com:587 is reachable
  • TLS 1.2 succeeds
  • The SMTP server advertises AUTH LOGIN XOAUTH2

The main question is:

What other Exchange Online or Microsoft 365 control could cause AUTH LOGIN to be rejected with 535 5.7.3 / 5.7.57 while SmtpClientAuthenticationDisabled is False at both the organization and mailbox level?

I'm particularly interested in whether there is another tenant/service-side restriction on Basic SMTP authentication that isn't exposed through the usual Get-TransportConfig / Get-CASMailbox settings.

The device is an older Ricoh MP C2011 and does not have an OAuth 2.0 SMTP option in its Web Image Monitor, so determining whether Basic SMTP AUTH is actually available to this tenant is important.

Any guidance on additional Exchange diagnostics or commands I can run would be appreciated.

1 Reply

  • hi barooder​ Based on the testing you've done, the SMTP AUTH settings themselves appear to be enabled, so the 535 error needs further investigation.

    One important clarification: Microsoft's current SMTP AUTH deprecation timeline does not say Basic SMTP AUTH was removed in April 2026. The January 27, 2026 Exchange Team update says that, for existing tenants, Basic SMTP AUTH remains unchanged until December 2026 and will then be disabled by default. Administrators can still enable it during that transition.

    So I wouldn't use the Basic Auth retirement as the explanation for this failure yet.

    At this point, the most useful next step would be checking the Exchange Online SMTP AUTH client submission logs/report and Entra sign-in logs for the failed authentication attempt. That should help identify whether Exchange is actually receiving the LOGIN attempt and what is causing the 535 response.

    The fact that `SmtpClientAuthenticationDisabled` is `False` at both organization and mailbox level is useful, but it doesn't by itself tell us why this particular authentication attempt is being rejected.

    Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline | Microsoft Community Hub