Microsoft 365 "530 5.7.57 Client not authenticated to send mail": fix

What it means

Your application, printer or mail server connected to smtp.office365.com and tried to send an email without logging in first. That endpoint only accepts mail from authenticated users who have an Exchange Online mailbox, so it refused the message at the MAIL FROM step. The error usually looks like this:

530 5.7.57 Client not authenticated to send mail.
530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM

This is different from 535 5.7.139: with 5.7.139 the app tried to log in and was refused; with 5.7.57 it did not log in at all (or the login never happened).

Why it happens

• Authentication is not enabled in the app: the "SMTP authentication" box is unticked, the username is empty, or the plugin is set to "no authentication".
• TLS could not be negotiated. Microsoft requires TLS before it accepts a login. If the device cannot do STARTTLS (old firmware, TLS 1.0 only), it skips the login and then gets 5.7.57.
• Wrong port or mode: port 25 without authentication, or "SSL" on port 587 instead of STARTTLS.
• Postfix or another server relaying through Microsoft 365 without SASL authentication configured.
• You wanted relay without a login but pointed the device at smtp.office365.com. Unauthenticated sending uses a different host (your MX endpoint), see below.

How to check

1. Look at the app's SMTP log. If you see MAIL FROM right after EHLO or STARTTLS with no AUTH line, the app never logged in.
2. Check that TLS works from the same machine:

   openssl s_client -starttls smtp -connect smtp.office365.com:587 -crlf

   After the certificate, type EHLO test. You should see a line starting with 250-AUTH. If the TLS handshake fails, the device's TLS support is the problem.
3. Test the whole chain with swaks and a real login (--tls --auth LOGIN). If swaks works but the device does not, the device configuration is at fault.
4. Find your MX endpoint with dig +short MX yourdomain.com or on the domain scanner. It looks like yourdomain-com.mail.protection.outlook.com.

How to fix it

Microsoft offers three ways for applications and devices to send. Pick one and configure it completely.

Option 1: SMTP AUTH (client submission)

Best when the app can log in and must send to anyone, internal or external.

• Server smtp.office365.com, port 587, encryption STARTTLS.
• Username and password (or OAuth) of a licensed mailbox; the From address must be that mailbox or one it is allowed to send as.
• SMTP AUTH must be allowed for that mailbox; if login then fails, see the 5.7.139 guide linked above (it also covers the Basic authentication retirement timeline).

For Postfix relaying through Microsoft 365, the usual main.cf lines are:

relayhost = [smtp.office365.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

with /etc/postfix/sasl_passwd containing [smtp.office365.com]:587 app@yourdomain.com:password, then postmap /etc/postfix/sasl_passwd and systemctl reload postfix. Postfix rewrites nothing by itself: the sender address must match the mailbox, or you get SendAsDenied.

Option 2: direct send (no login, internal recipients only)

The device sends to your MX endpoint (yourdomain-com.mail.protection.outlook.com) on port 25 without logging in. This only delivers to mailboxes in your own organization, and your SPF record should include the device's public IP. At the time of writing, Microsoft also lets admins reject direct send entirely (Set-OrganizationConfig -RejectDirectSendEnabled $true), so check that this is not enabled if you rely on it.

Option 3: SMTP relay with a connector (no login, any recipient)

Create an inbound connector in the Exchange admin center (Mail flow > Connectors, from "Your organization's email server" to Microsoft 365) that recognizes your fixed public IP or a TLS certificate. The device then sends to your MX endpoint on port 25 and can reach external recipients. The From address must use one of your accepted domains, otherwise you risk 5.7.750 unregistered domain blocks.

Check that it is fixed

• Send a test from the device to the unique address on the Delivmail home page (with options 1 and 3; option 2 cannot reach external addresses). The report shows SPF, DKIM and DMARC results for the path you chose.
• With direct send, test with an internal mailbox instead and look at its headers.
• Resend the message that failed and confirm the device log shows 235 Authentication successful (option 1) or a 250 answer after DATA.