Outlook 2016 doesn't accept password or app password

@Robdstef,

If you have M365 Personal the best experience would be to use the M365 Outlook that is part of your subscription. It connects with modern auth and is not affected by this recent issue. If you prefer Thunderbird, it would be best to follow the guidance of Thunderbird to use OAuth as noted in this article, Microsoft OAuth Authentication and Thunderbird in 2024 | Thunderbird Help (mozilla.org). I will keep sharing feedback to the service team to work on addressing the issues with basic auth, but you could skip all that with the other two options you have. Modern auth is also a more secure connection method so worth the effort to switch if you can.

This is, to the best of my knowledge, not true? I have this issue, and I'm running version 2401 (Build 17231.20194 CtR) with M365. The issue doesn't seem to be isolated to older builds.

It is not the IP address assigned on your end (source IP). It is the destination IP returned by DNS when your client looks up "outlook.com" or whatever you've specified for server (there are many aliases that all point to the same place). They load balance amongst many, many servers and only certain ones seem to have the issue.

My guess is if you are dormant for a while the connection goes away (or maybe a blip on your internet, weak wifi signal, etc) then when it re-establishes it hits a different IP at MS. Bouncing your network connection will get you a new random server (that hopefully doesn't have the issue).

A small update from my side too:

A few days ago, the error only seemed to occur when I changed the network (WLAN, mobile network) and thus the IP. Now, however, the connection is unstable even after some time on the same network.

For example, for two days I always had the error after the forced resconnection of my private Internet connection at home. Now it also happens during the day when definitely no new IP address has been assigned.

I also confirm that several attempts (clicking away errors and synchronizing again) eventually lead to success, so I also assume that it is only due to certain Auth servers.

In general, I thought it has become a bit more stable in the last few days. Unfortunately, this is not the case.
I have also noticed that even with a working connection (i.e. no password request), some of the mails are not pushed, but are sent collectively after some time. This could also have something to do with the problem, so I'll mention it here.

Edit: What I did not mention here is: I use BlackBerry Hub+ Services and my client supports both, EAS and EWS connection.

Edit2: Just to test I deleted the account and tried to set it up again with new App Password. First witih autodiscover and EAS, no way. Even after 20 tries. Then with "manual settings" and EWS, no problem to set it up.

I will monitor when I will receive the first password prompt error and give you feedback here.

This issue is certainly frustrating, and I'm seeing the exact same thing I see at my job, development and support outsourced and fixes, even to stuff far more critical, take weeks or even months to fix.

That being said, it has not been "down". Webmail (accessible via phone browser) has been fine, albeit inconvenient, and bouncing network or cancelling password prompts has worked for most.

They need to fix it, they need to roll back whatever they did, but honestly even with 49 pages of comments here, my guess is the impact is to a small percentage of their user base. Large corporate clients are their main concern, and only ones that aren't using modern auth correctly (which has been required since last year) seem to be impacted, at least from what I've seen here.

I guess it is a good illustration of how reliant people are on email as a primary means of communication, and they forget that there is good old fashioned talking to the other person.

Had email for work been down for even a few days and people were missing customer meetings, the only people facing termination would be those responsible for the email infrastructure. The rest of us would have found a workaround, even if it came down to writing on a physical calendar (but I'm confident they'd find a better workaround like telling us to stay logged into webmail and web Teams).