As everyone shifts more towards Azure and the use of M365 continues to be widely adapted, we have been working with more and more with companies that use these in a hybrid way. I was doing some work around sending emails from an M365 mailbox via an on-prem Service Manager environment. At a high-level, it involves using the SMTP Windows Feature on a Windows Server which allows us to use it as a Relay to an M365 mailbox.
I set this up in 3 different environments and ran into the same issue. I would try to send an email out, and the emails would get stuck in the Relay Queue and never go out. I would see this warning in the System Event Log:
Message delivery to the host failed while delivering to the remote domain for the following reason: The remote SMTP service rejected AUTH negotiation.
First thought (google), I forgot to give that user “Authenticated SMTP” permissions in M365. Locate the User, go to Mail > Manage email apps and… they actually do have the permissions.
Googling that error above produces a ton of results that make it seem like a quick fix. Then I would go down the normal troubleshooting path of: change this setting, try again, fail. That usually gets you moving towards your answer. In 3 different environments, I miraculously fixed the issue and have no idea what setting it was that I changed – each time promising myself I would only change one thing at a time. Somehow, I kept fixing it and concluding that it was some magic happening in Azure. So to save you the same headache, here is a super quick way to see if you are having the same issue.
Validate that you can even send email as that user via a simple PowerShell command.
In my case, I could not even do this with that account. I would see this error message:
The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM
I know I have the right credentials because I can login to M365 with them via a browser. That points me right back to that “Authenticated SMTP” permission in M365. And then I quickly rule it out because it is enabled.
After more digging, I come across some ExchangeOnline PowerShell commands that talk about disabling or enabling SMTP AUTH. Before just blindly setting the SmtpClientAuthenticationDisabled attribute, I wanted to get the mailbox and validate what I saw.
And there we go!!! That attribute is not set, it is null. Even though the M365 Admin Center shows that it is enabled, it is not. I go back to the Admin Center, Uncheck the box, Save, Re-check the box, Save. And Voila!!! Emails start coming through!
You could also just run the following PS command to set it:
In my tenant, I never touched this which means that all my users appeared to have this turned on when in fact they did not. Some organizations may already have policies or things in place that set these on users.
This is something that can be set organization-wide or per-user via Authentication Policies or PowerShell. To check organization-wide, log into the M365 Admin Portal and navigate to Settings >> Org settings >> Modern Authentication. Look to see whether Authenticated SMTP is enabled. To check on a particular user, run the following command in PowerShell to see which Policies are applied.
If you get any results, you can then use the following command to see the configuration of an Authentication Policy.
You may be reading this and laughing at something that you already knew or seems so simple. In my troubleshooting process, I was turning off that permission and turning it back on just to see if I could get a different error which I never did. I would always just turn it back on and go down some other rabbit hole. Once I finally gave up and looked again the next day, emails would be mysteriously coming through. Hopefully, there is someone out there googling right now that stumbles across this.
Let us know if this is of help and feel free to reach out through the Cireson Community for more tips and tricks!