Printers and apps can't send via Microsoft 365: SMTP AUTH, relay connectors and 5.7.57

Scan-to-email stops working, a line-of-business app can't send its reports, and the log says "5.7.57 Client not authenticated to send mail". The error is blunt but honest: the device connected to Microsoft 365's authenticated submission endpoint and never proved who it was. In this post I'll explain the three supported ways devices and applications can send through Microsoft 365, why 5.7.57 appears, how to fix each cause, and what the gradual retirement of Basic authentication for SMTP AUTH means for your printers.

Symptoms#

The device or application fails to send and logs one of these responses from smtp.office365.com:

530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM
550 5.7.57 Client not authenticated to send mail. Error: 535 5.7.139 Authentication unsuccessful, basic authentication is disabled

• Variants of 5.7.139 name the exact blocker, for example that SMTP client authentication is disabled for the tenant or for the mailbox.
• A device that authenticates fine but sends as a different address gets 5.7.60 Client doesn't have permissions to send as this sender.
• Devices pointed at the MX endpoint instead of smtp.office365.com don't get 5.7.57; their failures look like spam filtering or rejected external recipients.

Why it happens#

Microsoft documents three ways for a device or application to send mail when your mailboxes are in Microsoft 365, plus High Volume Email for internal bulk mail. Each has different requirements and limits:

5.7.57 belongs to the first row. The client reached the submission endpoint and issued MAIL FROM without a successful AUTH. The common reasons:

• No credentials configured, or the device simply doesn't support authenticated SMTP.
• SMTP AUTH is disabled for the tenant (SmtpClientAuthenticationDisabled on the transport config) or for that mailbox; the per-mailbox setting overrides the tenant. Microsoft disables it by default for tenants created after January 2020.
• Security defaults are on. Microsoft states that with security defaults enabled, SMTP AUTH is already disabled. An authentication policy that blocks Basic authentication for SMTP, or a Conditional Access policy that blocks legacy authentication, has the same effect.
• MFA on the account with a client that can only do username and password.
• Wrong port or TLS, for example implicit SSL on port 465 (not supported for client submission) or a device that can't negotiate TLS 1.2. TLS is required before authentication can happen.

How to fix it#

1. Identify the method the device is actually using. smtp.office365.com on 587 is client submission; an address ending in mail.protection.outlook.com on 25 is relay or Direct Send. Match the fix to the method.
2. For client submission, enable SMTP AUTH on that mailbox only. Keep the tenant switch off and open the door per device mailbox.
   PowerShell

   # Tenant-wide: True means disabled for everyone unless a mailbox overrides it
   Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
   
   # Per mailbox: True = disabled, False = enabled, blank = inherits the tenant setting
   Get-CASMailbox -Identity scanner@contoso.com | Format-List SmtpClientAuthenticationDisabled
   
   Set-TransportConfig -SmtpClientAuthenticationDisabled $true
   Set-CASMailbox -Identity scanner@contoso.com -SmtpClientAuthenticationDisabled $false

   Then confirm security defaults aren't enabled, that no Conditional Access policy blocks legacy authentication for that account, and that the device uses port 587 with STARTTLS and TLS 1.2. If the device sends from a different address, grant the sign-in account Send As on that mailbox.
3. Prefer OAuth where the device or app supports it. For interactive apps, request the delegated scope https://outlook.office.com/SMTP.Send. For unattended services, use the client credentials flow with the application permission SMTP.SendAsApp on the Office 365 Exchange Online API, grant admin consent, register the app in Exchange and give it access to the sending mailbox. The token is presented with SASL XOAUTH2.
   PowerShell

   $appId = "11111111-2222-3333-4444-555555555555"      # Application (client) ID
   $spObjectId = "66666666-7777-8888-9999-000000000000" # Object ID of the enterprise application
   New-ServicePrincipal -AppId $appId -ObjectId $spObjectId -DisplayName "Scan-to-email app"
   Add-MailboxPermission -Identity scanner@contoso.com -User (Get-ServicePrincipal -Identity "Scan-to-email app").Identity -AccessRights FullAccess

4. For devices that can't authenticate, set up an SMTP relay connector. In the Exchange admin center go to Mail flow › Connectors › Add a connector, choose Connection from: Your organization's email server and Connection to: Office 365, name it, and on the authentication page either enter the accepted domain that appears in the subject or SAN of the device's certificate (recommended) or the device's static public IP address. Point the device at your MX endpoint on port 25, use any address in an accepted domain, and add the IP to your SPF record so recipients don't junk the mail. Dynamic and shared IPs aren't supported.
5. Use Direct Send only as a last resort, and only for internal recipients. Microsoft says most customers don't need it and is working on disabling it by default; you can already reject it yourself with Set-OrganizationConfig -RejectDirectSend $true, which is worth doing once no device depends on it.
6. Test from PowerShell, with a caveat. Send-MailMessage is marked obsolete because it doesn't guarantee a secure SMTP connection, and it only speaks Basic authentication, so treat it strictly as a quick probe. Microsoft's note points to Send-MgUserMail from the Microsoft Graph PowerShell SDK for real automation.
   PowerShell

   $cred = Get-Credential scanner@contoso.com
   Send-MailMessage -SmtpServer smtp.office365.com -Port 587 -UseSsl -Credential $cred `
       -From scanner@contoso.com -To helpdesk@contoso.com -Subject "SMTP AUTH test" -Body "Sent through client submission"

Verify the fix#

Get-MessageTraceV2 -SenderAddress scanner@contoso.com -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) |
    Format-Table Received, RecipientAddress, Subject, Status

• Delivered: authentication worked and the message was accepted.
• No trace entry: the submission still fails before acceptance. Re-read the device log for the exact 5.7.x text; a 5.7.139 that names the tenant or mailbox tells you which switch is still off.
• Delivered to Junk or quarantined (relay and Direct Send): authentication isn't the issue any more; fix SPF for the sending IP and review the connector.

The Microsoft 365 admin center also offers a "Send email using Microsoft 365" diagnostic, and the SMTP AUTH clients report under Reports › Mail flow in the Exchange admin center shows which accounts still submit mail and whether they use Basic authentication or OAuth.

Key takeaways#

• Keep SMTP AUTH off at the tenant level and enable it per mailbox; review that list with the SMTP AUTH clients report.
• Match the method to the device: authenticated submission for anything that supports credentials or OAuth, a certificate-based relay connector for the rest, Direct Send almost never.
• Start moving printers and apps to OAuth, High Volume Email for internal bulk mail, or Azure Communication Services Email now, so the eventual removal of Basic authentication is a non-event.

References#

• How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 (Microsoft Learn)
• Enable or disable authenticated client SMTP submission (SMTP AUTH) in Exchange Online (Microsoft Learn)
• Authenticate an IMAP, POP or SMTP connection using OAuth (Microsoft Learn)