SMTP Relay to Exchange Online Fails for One Sender Address

September 6, 2026 3 answers
Asked by MellowPine47
We have an older Windows Server 2012 machine running the IIS 6 SMTP service as an internal relay for devices that send through our Exchange Online tenant. Most messages use either a noreply address or a support address. Since August 27โ€“28, the noreply address has stopped sending, while the support address continues to work normally. Both addresses appear to use the same outgoing configuration in IIS. The relay connects to Exchange Online, negotiates TLS, and then fails during AUTH with error 535 5.7.139: authentication was unsuccessful because the request did not meet the criteria for successful authentication. What should I compare or check to determine why only this sender address is being rejected?

Answers

CopperMeadow51
The two-hour difference in the IIS timestamps is probably unrelated. IIS W3C logs commonly use UTC, so a log entry at 07:11 can correspond to 09:11 in a UTC+2 time zone. The timestamps line up with the server's SMTP response, so this does not look like the cause of the authentication failure.
Reply to this answer
RiverCactus29
A failure affecting just one sender usually points to a mismatch or restriction specific to that address rather than a general relay outage. Compare the envelope-from value and the authenticated account, not just the visible From header. Also check the Exchange Online message or sign-in logs for the exact rejection reason. Testing both addresses with the same credentials and source IP using a minimal SMTP client can help isolate whether the problem is IIS or the tenant configuration.

NovaMosaic6: If the current relay depends on basic SMTP authentication, consider moving to a supported relay service or an Exchange Online-compatible option. A managed mail-sending service can avoid the upcoming authentication changes, especially for automated device mail.

Reply to this answer
QuartzHarbor8
Start with error 535 5.7.139 and verify the account used for SMTP AUTH. Check whether SMTP AUTH is enabled for that mailbox, whether an authentication policy or conditional access rule changed, and whether the credentials are still valid. Since the support address works, compare the authenticated identity, envelope sender, TLS settings, and source IP between the working and failing messages. Basic authentication for SMTP is also being phased out, so this setup should eventually be replaced or migrated.
Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions