SMTP OAuth Configuration Issue - Unable to Send Emails via Outlook Setup

Hi,

I’m setting up an email account using the following servers:

  • IMAP: imap-mail.outlook.com, Port 993
  • SMTP: smtp-mail.outlook.com, Port 587

The IMAP connection works with OAuth, but sending via SMTP fails because OAuth doesn’t seem to be used. I set up the account through Outlook as I don’t have access to an Exchange server, and the standard installation assumes an Exchange server.

Are these the correct server settings for my setup, and what do I need to do to configure OAuth properly for SMTP so I can send emails?

Thanks!

Unfortunately you can’t send using SMTP for MS accounts. Since Microsoft’s issues with SMTP oAuth, we now use AirSync to send messages.

The account will be setup correctly, but you need to go to Menu > Accounts > Add Account and enter the email address in the automatic setup for that to happen.

Your address appears to be hosted on an Exchange server, so it will be setup that way, but if you want to setup using IMAP instead and for it to work correctly, go to Menu > Accounts > Add Account > Mail > Outlook.com and enter your email address there.

Thank you for your response. However, I see an issue with how the matter was handled. You first informed me that it’s not possible to send emails with my current SMTP configuration for Microsoft accounts. Then, you suggested using the automatic setup, even though I had already mentioned that this doesn’t work for my specific situation, as eM Client incorrectly assumes an Exchange server, to which I don’t have access. This assumption and the resulting recommendation are therefore not helpful in this case.

What I expect from eM Client is software that can handle my specific configuration (IMAP and SMTP for Outlook.com) correctly. An automation process that defaults to an Exchange server should consider the actual requirements and configurations instead of offering a generic solution that doesn’t work in my situation. This seems to be a design flaw, as an automation process should reasonably consider the specific needs and circumstances of the users rather than ignoring them.

An automation process should also allow alternative configurations and present these options to the user beforehand, rather than assuming one specific setup and not offering alternative configuration options.

In this context, I would like to ask if there are any plans to improve eM Client to offer this flexibility. If so, I would be interested in knowing the expected timeline for implementing such a change.

That is correct. Microsoft has issues with their oAuth implementation on SMTP so it is no longer possible to use SMTP to send messages using MS servers. Please see the link I gave above that explains how we work around the issue by using AirSync instead.

It doesn’t default to Exchange. eM Client receives the details of your account from your server and sets up the account according to that. If your server says the address is on an Exchange package, then that is how the account will be setup. If it is incorrect, please contact your email provider directly.

Until they can resolve that, I have also given a method to setup the account as IMAP. Please see my instructions above.

Hi Gary,

Thank you for your response and the suggestion to use AirSync. However, I’d like to clarify the situation a bit more, as this approach doesn’t seem to address the actual problem.

AirSync is primarily used to sync emails, calendars, and contacts with an Exchange server. When eM Client detects the presence of an Exchange server, it automatically configures the account accordingly. In my case, though, I don’t have access to the Exchange server, even if it is detected.

This means that just because an Exchange server exists, it doesn’t mean I can or am allowed to access it. In many situations like mine, a company may provide access only to IMAP and SMTP with OAuth authentication, while blocking access to the Exchange server. This often makes sense, as the company may want to limit access to internal data and functions on the Exchange server while still allowing email traffic via IMAP and SMTP.

The suggestion to use AirSync doesn’t resolve this issue, because it again requires the use of Exchange. This involves permissions and changes on the Exchange server that I am not allowed to have. The core requirement—IMAP and SMTP with OAuth—remains unresolved.

I have set up the correct server settings for IMAP (imap-mail.outlook.com, Port 993) and SMTP (smtp-mail.outlook.com, Port 587), and while IMAP works with OAuth, sending via SMTP fails because OAuth is not used. Other email clients allow direct SMTP configuration with OAuth, which would be the cleanest solution in my case. In fact, I’ve attached a graphic from another email client where I was able to configure the account without any issues.

I understand that eM Client defaults to the Exchange path when it detects an Exchange server, but in this scenario, that approach leads to a dead end since I can’t use Exchange.

Given that Microsoft now requires OAuth for SMTP, I’m wondering if eM Client would consider a more flexible solution—specifically, the ability to configure SMTP with OAuth independently of Exchange, without relying on workarounds like AirSync.

Are there any plans to support this in future updates? This could benefit many users who face similar access restrictions.

If I misunderstood something or overlooked a key detail, I apologize in advance, and I appreciate your patience.

Thank you again for your time and support.

Best regards,
Rene

We of course used this in the past, but some years ago Microsoft broke the oAuth implementation for SMTP. Please see the link I gave in my initial post which gives the reason why we moved to AirSync.

Hi,

Thanks for the explanation. However, I’m still a bit confused. As shown in the image I previously shared, SMTP with Microsoft OAuth 2.0 works successfully in another email client. Additionally, according to the IT department of the company managing my email domain, it’s also functioning properly in Outlook and Thunderbird.

This raises the question: why is this not possible in eM Client anymore? According to their IT team, Microsoft OAuth 2.0 should work for SMTP, as it does in these other clients. Are there differences in how eM Client implements OAuth that could explain this?

Thanks again for your time!

Best regards,
Rene