The Remote Smtp Service Rejected Auth Negotiation

Home ⁄ The Remote Smtp Service Rejected Auth Negotiation

The Remote Smtp Service Rejected Auth Negotiation

As anybody shifts more towards Azure and the use of M365 continues to exist widely adapted, we take been working with more than and more than 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 environs. At a loftier-level, it involves using the SMTP Windows Feature on a Windows Server which allows u.s. to utilise it every bit a Relay to an M365 mailbox.

I set up this upwardly in iii different environments and ran into the same effect. I would try to send an email out, and the emails would get stuck in the Relay Queue and never leave. I would see this warning in the Organisation Effect Log:

Message delivery to the host failed while delivering to the remote domain for the following reason: The remote SMTP service rejected AUTH negotiation.

Start idea (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 downwardly the normal troubleshooting path of: alter this setting, try again, fail. That usually gets you moving towards your answer. In 3 dissimilar environments, I miraculously stock-still the issue and have no idea what setting information technology was that I changed – each time promising myself I would only alter ane thing at a time. Somehow, I kept fixing it and final that it was some magic happening in Azure. So to relieve you lot the same headache, here is a super quick way to meet if you are having the same issue.

Step 1

Validate that you can even send email every bit that user via a uncomplicated PowerShell command.

In my instance, I could not even do this with that account. I would run into this mistake bulletin:

The SMTP server requires a secure connection or the customer was not authenticated. The server response was: 5.7.57 SMTP; Customer was not authenticated to send anonymous mail during Mail service FROM

I know I have the right credentials considering I can login to M365 with them via a browser. That points me right back to that "Authenticated SMTP" permission in M365. And so I rapidly dominion information technology out because it is enabled.

Pace ii

After more excavation, I come beyond some ExchangeOnline PowerShell commands that talk about disabling or enabling SMTP AUTH. Before just blindly setting the SmtpClientAuthenticationDisabled attribute, I wanted to go the mailbox and validate what I saw.

And in that location we go!!! That attribute is non ready, information technology is zero. Even though the M365 Admin Center shows that it is enabled, it is non. I become back to the Admin Heart, Uncheck the box, Save, Re-bank check the box, Salvage. And Voila!!! Emails showtime coming through!

You could also just run the following PS control to set information technology:

In my tenant, I never touched this which means that all my users appeared to accept this turned on when in fact they did not. Some organizations may already take policies or things in place that set these on users.

This is something that can be ready organization-wide or per-user via Hallmark Policies or PowerShell. To bank check arrangement-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 meet which Policies are applied.

If y'all get whatever results, you can then use the following control to see the configuration of an Authentication Policy.

Y'all may be reading this and laughing at something that you already knew or seems so simple. In my troubleshooting procedure, I was turning off that permission and turning information technology dorsum on just to see if I could become a different mistake which I never did. I would e'er simply turn it dorsum on and go down some other rabbit hole. In one case I finally gave upward and looked again the next day, emails would exist mysteriously coming through. Hopefully, there is someone out at that place googling right at present that stumbles beyond this.

Let us know if this is of help and feel free to achieve out through the Cireson Community for more tips and tricks!