IMAP XOAUTH2 returns "User is authenticated but not connected" for a single Outlook.com account — other accounts work fine

Question

IMAP XOAUTH2 returns "User is authenticated but not connected" for a single Outlook.com account — other accounts work fine

huang huan 0

I have a Java backend application using JavaMail (javax.mail 1.6.7) to pull emails from Outlook.com consumer mailboxes via IMAP with OAuth2 (XOAUTH2). One specific mailbox started failing a few days ago with the error "User is authenticated but not connected." Other Outlook.com mailboxes work perfectly with the exact same code and configuration. No code or configuration changes were made.

Configuration:

IMAP server: outlook.office365.com, port 993, SSL/TLS
SMTP server: smtp.office365.com, port 587, STARTTLS
Authentication: XOAUTH2 (OAuth2)
Token endpoint: https://login.microsoftonline.com/consumers/oauth2/v2.0/token
Scope: https://outlook.office.com/SMTP.Send https://outlook.office.com/Mail.ReadWrite https://outlook.office.com/Mail.Read https://outlook.office.com/IMAP.AccessAsUser.All offline_access
Account type: consumer Outlook.com (personal)

Key findings:

Same OAuth2 access token works for SMTP but fails for IMAP — SMTP AUTH XOAUTH2 succeeds, proving the token is valid
CAPABILITY returns LOGINDISABLED — see IMAP log below
4 consecutive retries all fail — not intermittent
Other Outlook.com mailboxes work fine with the same code and config
Mozilla Thunderbird with OAuth2 also fails on the same account
Outlook Web Access (outlook.live.com) works fine — can log in and send/receive emails normally
IMAP is enabled in Outlook web settings
No code or configuration changes were made — this account worked fine until a few days ago

IMAP protocol log (redacted):


* OK Microsoft Exchange IMAP4 service ready. (tcpproxy/15.21.0406.000 BACKENDAUTHENTICATE)

A0 CAPABILITY

* CAPABILITY IMAP4 IMAP4rev1 AUTH=XOAUTH2 LOGINDISABLED SASL-IR UIDPLUS MOVE ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+

A0 OK CAPABILITY completed.

AUTHENTICATE XOAUTH2

A1 NO User is authenticated but not connected.

(retried 4 times: A1, B1, C1, D1 — all return the same error)

SMTP protocol log (redacted, for comparison — this succeeds):


220 Microsoft ESMTP MAIL Service ready

EHLO [redacted]

250-SIZE 157286400

250-STARTTLS

250 AUTH LOGIN XOAUTH2

STARTTLS

220 2.0.0 SMTP server ready

AUTH XOAUTH2

AUTH XOAUTH2 succeeded    ← SMTP succeeds with the same token

Error stack trace:


javax.mail.AuthenticationFailedException: User is authenticated but not connected.

    at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:708)

    at javax.mail.Service.connect(Service.java:342)

    at javax.mail.Service.connect(Service.java:222)

Question:

Has anyone encountered this issue where a single Outlook.com consumer account returns "User is authenticated but not connected" for IMAP while SMTP works fine with the same token? Is this an account-level IMAP restriction on the server side? How can this be resolved?

0 comments

1 answer

Your answer

Answer 1

Hi huang huan,

Based on your testing, it’s notable that the same OAuth token works successfully with SMTP while IMAP returns "User authenticated but not connected", and the behavior is isolated to a single Outlook.com account. The fact that another mail client reproduces the same result also suggests the issue is not limited to your JavaMail implementation.

As I have checked and validated, these steps from AI answer are pointing us at the right direction:

Sign in to your Microsoft account and review Recent Activity for any unusual or blocked sign-in events related to IMAP access.
Verify that IMAP access remains enabled in your Outlook.com mail settings.

If both checks look correct, try testing again with a newly acquired access token to rule out a temporary authentication state.

If the issue continues and other Outlook.com accounts work normally with the same application and configuration, the remaining evidence points toward a condition specific to this mailbox's IMAP access rather than the client configuration itself.

At that stage, it may be worth contacting Microsoft Support for further account-specific investigation, as there may not be any additional client-side changes available to test.

Please note that this is a user-to-user support forum. Moderators, contributors including external Microsoft employees cannot directly intervene in Microsoft product features or access back-end systems. Our role is limited to providing technical guidance on reported issues, requests, or ideas.

I understand how frustrating it can be when a configuration that previously worked suddenly affects only one account. Let me know if you need further assistance, feel free to ask me by clicking "Add Comment" or "Add Answer" if you cannot add comment so your response will be visible. Thanks for your effort.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

huang huan 0 Reputation points

2026-09-17T07:01:17.51+00:00

Hi,Thank you for your reply. I've completed all the checks you suggested:

Recent Activity — Reviewed it, no unusual or blocked IMAP sign-in events found

IMAP settings — Confirmed it is enabled

New token — I revoked the old authorization and recompleted the full OAuth2 flow to get brand-new tokens

Also, an important update: after completing the captcha challenge at https://outlook.live.com/owa/0/captchachallenge.aspx, the IMAP connection now succeeds intermittently — it occasionally pulls emails but still fails most of the time. This further confirms the issue is a security restriction on this specific account that is being gradually lifted across Microsoft's IMAP server nodes, but hasn't fully propagated yet.
Hendrix-V 19,115 Reputation points Microsoft External Staff Moderator

2026-09-17T07:11:15.1633333+00:00

Hi huang huan,

Thank you for the detailed update and for sharing the outcome of your testing.

Since authentication is clearly succeeding and the same account can sometimes retrieve messages, this suggests the OAuth flow, token generation, and application configuration are functioning as expected.

At this stage, there appears to be little additional client-side troubleshooting to perform. A practical next step would be to continue monitoring the account for a short period and retest IMAP access periodically, as intermittent success may indicate that account-related security or access changes are still being recognized across the service.

If the behavior remains inconsistent, please consider contacting Microsoft Support and providing your observations - these details can help focus further investigation on the specific account's IMAP connectivity rather than the application itself.