# 5.7.57 Bounce: Client Not Authenticated (Microsoft)

URL: https://email-validation.org/bounce-codes/5-7-57/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

**At a glance**

- **Type:** permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
- **Basic code:** varies; the enhanced code is the part that identifies the problem.
- **Enhanced code 5.7.57:** not in the IANA registry; the group is security or policy status (RFC 3463 §3.8).
- **Who uses it:** Microsoft (Exchange Online): client was not authenticated to send anonymous mail during MAIL FROM.

A 5.7.57 bounce from Microsoft 365 means an app, printer, scanner or script connected to `smtp.office365.com` and tried to send without signing in first. The service does not accept anonymous mail there.

## What it means

This is Microsoft's code, not one from the IANA registry. Microsoft's [Exchange Online NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) describes it as a client that was not authenticated to send anonymous mail during MAIL FROM. In plain terms: the connection reached the step where the sender is named, and no account had signed in yet.

The general SMTP equivalent is [530 5.7.0](https://email-validation.org/bounce-codes/530-5-7-0/), which [RFC 4954 §6](https://www.rfc-editor.org/rfc/rfc4954) defines for a server that requires authentication before it takes commands other than AUTH.

## Common causes

- A device or app was set up with `smtp.office365.com` as its server but with no username and password.
- The authentication setting is off, or set to "none", in the device's mail settings.
- TLS is off, so the device never gets to the point where it can sign in.
- A script or library sends MAIL FROM without calling AUTH first.
- The device signed in once, but stored credentials were cleared after a firmware update or reset.

## How to fix it

1. Open the outgoing mail (SMTP) settings of the app or device.
2. Turn on authentication, and enter the full address and password of a Microsoft 365 mailbox that is allowed to send.
3. Turn on TLS or STARTTLS, so the password is not sent in the clear.
4. Make sure the From address the device uses is that mailbox, or one it is allowed to send as.
5. Send a test message. If the reply changes to [535 5.7.8](https://email-validation.org/bounce-codes/535-5-7-8/), the device now signs in but the credentials are wrong.
6. If the device cannot authenticate at all, it needs a different way to send. Ask your Microsoft 365 admin which option fits; the admin center and Microsoft's documentation describe the choices for devices and applications.

## If you are the admin

The bounce is about the client, so the fix is usually on the device. Check that the mailbox it uses exists and has not been blocked from sending. A mailbox blocked for spam gives a different code, [5.1.8](https://email-validation.org/bounce-codes/5-1-8/). Mail from on-premises servers through a connector that no longer matches gives [5.7.64](https://email-validation.org/bounce-codes/5-7-64/) instead.

## Related codes

- [530 5.7.0](https://email-validation.org/bounce-codes/530-5-7-0/): Authentication or STARTTLS required
- [535 5.7.8](https://email-validation.org/bounce-codes/535-5-7-8/): Username and password not accepted
- [5.7.64](https://email-validation.org/bounce-codes/5-7-64/): TenantAttribution: relay access denied (Microsoft 365)

See [every bounce code](https://email-validation.org/bounce-codes/) in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our [free email checker](https://email-validation.org/email-checker/), or [clean a whole list](https://email-validation.org/bulk-email-verification/) before you send.