5.7.57: Client not authenticated to send anonymous mail (Microsoft 365)

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 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, which RFC 4954 §6 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, 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. Mail from on-premises servers through a connector that no longer matches gives 5.7.64 instead.

Related codes

• 530 5.7.0: Authentication or STARTTLS required
• 535 5.7.8: Username and password not accepted
• 5.7.64: TenantAttribution: relay access denied (Microsoft 365)

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.