550 5.7.57 Client Not Authenticated During MAIL FROM: Fix

550 5.7.57 Client was not authenticated to send anonymous mail during MAIL FROM is Exchange Online saying one thing: the session got as far as declaring a sender, and nobody had proved who they were. Microsoft 365 does not accept anonymous mail on its submission endpoint, so it stops the transaction at MAIL FROM.

It is almost never a person. It is a scanner, a CRM, a backup job, a web form or a line-of-business app that worked yesterday and broke after a tenant-side change. Below: what the code means, the causes in the order worth checking, and the three supported ways to submit mail to Microsoft 365.

What 550 5.7.57 actually means#

Read it literally. MAIL FROM is the command that opens the envelope and declares the sender. The server evaluated the session at that moment, found no authenticated identity, and refused it. The leading 5 means permanent, the 7 means policy or security: retrying unchanged gives the same result forever.

Microsoft documents this code for the smtp.office365.com endpoint: to submit or relay messages there you must authenticate as a user with an Exchange Online mailbox, and the bounce points at the configuration of the connecting application or device. Its own fix list is two items — verify the credentials, and verify the application can negotiate TLS, because TLS is required in order to authenticate.

That second requirement causes more of these than bad passwords do. A client that never completes STARTTLS never reaches the point where it can authenticate, so it sends MAIL FROM anonymously. The log reads like a permissions problem and is an encryption problem.

What causes it, and how to confirm each one#

The trigger is usually a tenant-side change, not the device. SMTP AUTH is off by default for organizations created after January 2020, Microsoft disabled it in tenants that were not using it during the basic authentication deprecation, and security defaults disable it too. The app did not change. The door did.

Work down this table in order. The first two rows account for most cases.

Pick the right submission path before you fix anything#

Microsoft supports three ways for a device or app to send through Microsoft 365, plus High Volume Email for internal bulk. Picking the wrong one is how a 5.7.57 becomes a 550 5.7.1 unable to relay a week later. Decide here, then run the matching procedure.

Fix 1: authenticated client submission (SMTP AUTH)#

The right choice when the app should send as a real mailbox, needs external recipients, and sends modest volume. It is also the only path that keeps a copy in Sent Items.

1. 1

   Confirm the sending account has a licensed Exchange Online mailbox

   Client submission authenticates as a mailbox user; an unlicensed account will not work.

2. 2

   Enable SMTP AUTH for that mailbox

   Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false. The per-mailbox value overrides the organization setting, so the tenant switch can stay off.

3. 3

   Check what else is blocking it

   Microsoft notes SMTP AUTH is already disabled when security defaults is on, and an authentication policy disabling basic auth for SMTP blocks clients even after you enable the setting above.

4. 4

   Point the client at smtp.office365.com, port 587, STARTTLS on

   Use the DNS name, not an IP, with TLS 1.2 or 1.3. Microsoft's tip: a device that defaults to port 465 does not support the TLS versions client submission requires.

5. 5

   Prefer OAuth over a stored password

   Microsoft recommends modern authentication here and has published a retirement timeline for basic auth on client submission. Check the current milestones before building on a password.

6. 6

   Grant Send As if the From differs from the sign-in account

   Without it you clear 5.7.57 and land on 5.7.60, client doesn't have permissions to send as this sender.

Fix 2: Microsoft 365 SMTP relay with a connector#

The right choice when the app cannot authenticate, sends from a mailbox-less address such as [email protected], or exceeds mailbox sending limits. The connector authenticates the source instead of the sender.

1. 1

   Find your tenant MX endpoint

   Microsoft 365 admin center, Settings, Domains, your domain, DNS records. Copy the points-to value: contoso-com.mail.protection.outlook.com.

2. 2

   Choose certificate or IP

   Microsoft recommends a TLS certificate whose Subject or SAN contains an accepted domain. Otherwise use a static public IP not shared with another organization — dynamic IPs are not supported.

3. 3

   Create the inbound connector

   Exchange admin center, Mail flow, Connectors: add a connector from your organization's email server to Office 365, authenticated by certificate subject or IP.

4. 4

   Configure the device

   Host = the MX endpoint, port 25, TLS on, From address in a verified accepted domain. No licensed mailbox, and nothing saved to Sent Items.

5. 5

   Update SPF, then test

   Add the sending IP or host to SPF so relayed mail is not filtered, then confirm a test message in message trace.

Fix 3: direct send#

The right choice only when a legacy device supports neither of the above and every recipient is inside your tenant. It sends unauthenticated to your MX endpoint, so the message is scanned exactly like anonymous mail from the internet.

1. 1

   Point the device at your tenant MX endpoint, port 25, no credentials

   TLS is optional. The From address must be in an accepted domain, but needs no mailbox.

2. 2

   Publish SPF, DKIM and DMARC for the source

   Microsoft recommends a static IP so it can be listed in SPF. Misconfiguration here is a security gap, not just a junk-folder problem.

3. 3

   Accept the hard limit

   Direct send cannot deliver to external recipients — mail to Gmail, Yahoo or a customer domain is rejected. If the device emails clients, this is the wrong path.

4. 4

   Check whether your tenant still allows it

   Exchange Online exposes a RejectDirectSend setting on Set-OrganizationConfig, and Microsoft has said it is working toward disabling direct send by default. Confirm the current default and your tenant's value before relying on it.

How to tell which cause you have, in about five minutes#

Triage from the wire, not from the app's error dialog. The question that splits the causes is whether the client ever attempted AUTH at all.

1. 1

   Get a real SMTP log from the sending host

   Microsoft recommends device-side SMTP logs for submission failures. MAIL FROM with no preceding AUTH means a client configuration problem, not a permissions one.

2. 2

   Test the endpoint by hand from that host

   Open a session with openssl s_client -starttls smtp -connect smtp.office365.com:587 and read the response. It also proves whether a firewall or ISP is blocking the port.

3. 3

   Check the mailbox flag

   Get-CASMailbox -Identity <mailbox> | Format-List SmtpClientAuthenticationDisabled. False = enabled, True = disabled, blank = inherits the organization setting.

4. 4

   Compare against the neighbouring codes

   An AUTH that was rejected is a different problem from one that never happened. Use the table below before changing anything.

How to stop it happening again#

5.7.57 is rarely a one-off. It arrives in clusters, because one tenant-level change touches every unattended sender at once.

• Keep an inventory of everything that submits mail: MFPs, scanners, CRM, ERP, backup, monitoring, forms, ticketing. Most of these outages are discovery problems.
• Give each app its own identity and its own path. Shared admin credentials in a printer are a security problem and a single point of failure.
• Treat basic authentication as time-limited. Microsoft has published — and revised — a retirement timeline for basic auth on client submission, so check the current announcement rather than a date you wrote down.
• Watch the tenant switches that silently break submission: security defaults, conditional access rules blocking legacy auth, the org-wide SMTP AUTH toggle, RejectDirectSend.
• Keep SPF, DKIM and DMARC matched to the path you chose, so the fix does not trade a bounce for a junk folder — and re-test every unattended sender after any mail-flow change.