530 5.7.1 Client was not authenticated: fixing anonymous SMTP submission to Exchange

A scanner, line-of-business app or mail gateway tries to hand a message to Exchange and gets 530 5.7.1 Client was not authenticated straight after MAIL FROM. Exchange isn't broken: the receive connector that took the connection doesn't let anonymous sessions submit mail. In this post I'll show how to find that connector, read its protocol log, and choose the right fix on Exchange Server SE and 2019 (2016 behaves the same).

Symptoms#

• The device, application log or gateway queue shows 530 5.7.1 Client was not authenticated and the message is never accepted.
• A manual SMTP test from the device's network fails at the same point:

220 EX01.contoso.com Microsoft ESMTP MAIL Service ready at ...
EHLO test.contoso.com
250-EX01.contoso.com Hello [10.0.20.55]
...
MAIL FROM:<scanner@contoso.com>
530 5.7.1 Client was not authenticated

• It often starts after hardening, after a new receive connector is created, or when a device moves from port 25 to 587 without credentials.

Two neighbouring errors have different fixes: a 5.7.54 "unable to relay" rejection means the session was accepted but the recipient is outside your accepted domains, and a send-as error after a successful login means the account isn't allowed to use that From address.

Why it happens#

Every SMTP session lands on one receive connector, and that connector's permission groups decide what the session may do. To issue MAIL FROM, a session needs the ms-Exch-SMTP-Submit permission. An unauthenticated session only gets it when the connector includes the AnonymousUsers group (which grants submit, accept-any-sender, accept-authoritative-domain-sender and accept-routing-headers). Without it, Exchange answers with 530 5.7.1.

The two client-facing connectors that setup creates in the Front End Transport service behave very differently:

So the usual causes are:

1. The device uses port 587 without logging in, or it has credentials but doesn't start TLS. Because Basic authentication isn't advertised before STARTTLS, the device skips AUTH and sends MAIL FROM anonymously.
2. AnonymousUsers was removed from Default Frontend, for example by a hardening script or by clearing "Anonymous users" in the Exchange admin center.
3. A custom connector caught the session. When several connectors share the same IP address and port, the one whose RemoteIPRanges most specifically matches the client wins. A connector built for something else that includes the device's IP, but not AnonymousUsers, rejects it.
4. The device reaches a different server (a load balancer or DNS alias) whose connectors aren't configured like the one you checked.

How to fix it#

1. Find the connector that answered#

Get-ReceiveConnector -Server EX01 |
  Format-Table Name,TransportRole,Bindings,RemoteIPRanges,PermissionGroups,AuthMechanism -AutoSize -Wrap

Match the device's target port and IP address to Bindings, then look for the narrowest RemoteIPRanges entry that contains the device's IP. Ignore the Transport service connectors (Default on 2525, Client Proxy on 465). They only receive traffic the front end has already proxied.

2. Confirm it in the receive protocol log#

Protocol logging is off on most default connectors, so switch it on for the suspect connector, reproduce the failure and search for the device's IP:

Set-ReceiveConnector "EX01\Client Frontend EX01" -ProtocolLoggingLevel Verbose
$log = Join-Path $env:ExchangeInstallPath 'TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive'
Get-ChildItem $log -Filter *.log | Sort-Object LastWriteTime | Select-Object -Last 3 |
  Select-String -Pattern '10.0.20.55' -SimpleMatch | Select-Object -Last 20 -ExpandProperty Line

A failing anonymous session looks like this (trimmed):

...,EX01\Client Frontend EX01,08DDE6A1B2C3D4E5,1,10.0.0.21:587,10.0.20.55:50122,*,None,Set Session Permissions
...,EX01\Client Frontend EX01,08DDE6A1B2C3D4E5,7,10.0.0.21:587,10.0.20.55:50122,<,MAIL FROM:<scanner@contoso.com>,
...,EX01\Client Frontend EX01,08DDE6A1B2C3D4E5,8,10.0.0.21:587,10.0.20.55:50122,>,530 5.7.1 Client was not authenticated,

The second field names the connector that answered. None on the Set Session Permissions line means the session was granted nothing, and the missing AUTH and STARTTLS lines show that the client never tried to log in.

3. Apply the fix that matches the sender#

The device can authenticate (preferred): point it at port 587 with STARTTLS enabled, using the credentials of a mailbox account. If it sends as a different address, give that account Send As permission on it. The device must also trust the certificate and support a TLS version your servers allow (normally TLS 1.2). See my certificate renewal guide if the SMTP certificate is the problem.

The device can't authenticate and only mails internal recipients: use port 25. If someone removed anonymous access from Default Frontend, put the default groups back:

Set-ReceiveConnector "EX01\Default Frontend EX01" -PermissionGroups AnonymousUsers,ExchangeServers,ExchangeLegacyServers

If you'd rather keep devices on their own connector (easier to log and audit), create one in the Front End Transport service and scope it to the device IPs:

New-ReceiveConnector -Name "Devices EX01" -Server EX01 -TransportRole FrontendTransport -Custom `
  -Bindings 0.0.0.0:25 -RemoteIPRanges 10.0.20.55,10.0.20.56 -PermissionGroups AnonymousUsers -ProtocolLoggingLevel Verbose

The device must mail external recipients without logging in: that's anonymous relay. It needs a tightly scoped relay connector and an extra permission, and it fails with 5.7.54 rather than 530.

Connectors are per server, so repeat the change on every server the device can reach.

Verify the fix#

Test from the device's own subnet, because the source IP decides which connector you hit:

Test-NetConnection ex01.contoso.com -Port 25
telnet ex01.contoso.com 25
EHLO test.contoso.com
MAIL FROM:<scanner@contoso.com>
250 2.1.0 Sender OK
RCPT TO:<helpdesk@contoso.com>
250 2.1.5 Recipient OK

For authenticated submission, a quick check from Windows PowerShell works (Send-MailMessage is marked obsolete but is fine for a test):

Send-MailMessage -SmtpServer ex01.contoso.com -Port 587 -UseSsl -Credential (Get-Credential) `
  -From scanner@contoso.com -To helpdesk@contoso.com -Subject "587 test" -Body "test"

Good looks like this: the protocol log shows SMTPSubmit on the session permissions line (or a successful AUTH), and message tracking shows a RECEIVE event followed by DELIVER:

Get-TransportService | Get-MessageTrackingLog -Sender scanner@contoso.com -Start (Get-Date).AddMinutes(-30) |
  Format-Table Timestamp,ServerHostname,EventId,Source,Recipients -AutoSize

Prevent it next time#

• Keep an inventory of every SMTP sender: source IP, target server, port, authentication method and From address.
• Prefer authenticated submission on 587 with TLS for anything that supports it. Keep anonymous port 25 access for devices that can't authenticate.
• Re-test devices after hardening or connector changes, and keep verbose logging on custom connectors.
• Moving these senders to Microsoft 365 instead? The rules there are different. See printers and apps sending via Microsoft 365.

References#

• Receive connectors in Exchange Server (Microsoft Learn)