SMTP Relay to Exchange Online Fails for One Sender Address

0
6
Asked By MellowPine47 On

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?

3 Answers

Answered By QuartzHarbor8 On

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.

Answered By RiverCactus29 On

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.

Answered By CopperMeadow51 On

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.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.