I'm troubleshooting a small Microsoft 365 tenant with about six Basic-licensed accounts. Security defaults were disabled at some point, and the users do not use MFA. Most users are running Outlook 2016 and connect normally, but one mailbox suddenly stopped working.
The affected user can sign in and use webmail without any trouble. Outlook initially showed connection errors, eventually could not display the mailbox folders, and then closed. The saved credentials and cached credentials were removed, the user was signed out of other Office applications, and the Outlook profile was deleted. After that, creating a new profile failed with an "Outlook cannot create an encrypted connection" error.
The original computer had several registry changes applied from online troubleshooting guides, including settings related to modern authentication, so I tested the account on three different computers instead. The same encrypted-connection error occurred on a new Windows 11 system with the latest Microsoft 365 installation. The authentication prompt appears briefly and disappears too quickly to use.
Microsoft's connectivity analyzer reports a 401 error during the final MAPI test, although autodiscover appears to work. I also tested the analyzer with two known-working accounts from other tenants, and they produced the same MAPI result, so I'm not sure how meaningful that test is. MAPI is enabled for the affected mailbox.
Since every other account in the tenant works, this seems more likely to be a mailbox- or account-specific problem than a client-computer issue. What Microsoft 365 settings or mailbox properties should I check next, and could this indicate a problem that may eventually affect the other users?
3 Answers
Because the same account fails on multiple clean computers while webmail works, I’d focus on the mailbox rather than Outlook or the local registry. Check the user’s license, sign-in status, assigned service plans, and especially whether MAPI is enabled for that specific mailbox. You can verify it in Exchange Online PowerShell with Get-CASMailbox and enable it with Set-CASMailbox if necessary. Also check whether an Exchange access policy, authentication policy, or mailbox protocol restriction is blocking Outlook. Outlook 2016 may be old or unsupported depending on the licensing and update level, but that would not normally explain one mailbox failing everywhere while the others work.
A 401 from the MAPI test is an authentication or authorization failure, not necessarily proof that MAPI itself is broken. Since the analyzer gives the same result for known-good accounts, I would not treat that test as conclusive. Compare the affected user with a working user in the Microsoft 365 admin and Exchange portals: license assignment, mailbox type, account sign-in state, usage location, client access settings, and any conditional-access or authentication policies. Removing and recreating the Outlook profile will not fix a server-side permission or policy issue.
The very brief authentication window can happen when modern-authentication registry overrides or stale Office identity data interfere with the sign-in process, but the fact that it follows the account to three machines makes that less likely. On the test computer, use a fully updated Microsoft 365 Apps installation, remove the old Office identity and credential entries, and avoid applying random registry fixes. More importantly, compare the mailbox’s Exchange properties with one that works. If needed, temporarily disable and re-enable the affected protocol setting through the supported Exchange tools, then test again.
The outage mentioned elsewhere would not explain this if the problem began a week earlier and affects only one mailbox. I’d treat the timing as unrelated and continue with the account-level checks.
That matches what I’m seeing. MAPI already reports as enabled, but I’m going to compare the affected mailbox’s CAS and authentication settings directly with a working user instead of relying only on the connectivity test.