Consumer Outlook.com: IMAP OAuth session bind fails with "User is authenticated but not connected" (reproduces across two independent clients)

(Log analysis and write-up done with Claude Opus 5. Mailbox, logs, and cross-client reproduction are mine.)

IMAP against a consumer Outlook.com mailbox fails at session bind after the OAuth token is accepted. Reproduced 2026-09-03; unknown when it last worked on this mailbox, possibly many months.

Account: consumer Outlook.com, regional @outlook.es domain, personal Microsoft account. Not a work or school account, no tenant, no admin.

Server: outlook.office365.com:993, TLS, XOAUTH2.

Clients: Thunderbird 154.0 on Linux, and FairEmail on Android — separate OAuth app registrations, separate devices, separate networks. Both fail identically. Webmail works normally throughout.

Already ruled out: forcing IPv4 to outlook.office365.com makes no difference (this is the standard suggestion for this error string and it does not apply here); account.live.com/activity lists no blocked session to approve, only the browser sign-in, so this is not a pending security hold; the "domain other than @live.com/@hotmail.com/@outlook.com" note in the POP/IMAP settings article concerns connected accounts, since its stated remedy is to reconfigure the connected account as POP, so it does not apply either.

What the transcript establishes: the token is accepted, so the failure is at session bind rather than authentication. Two datacenters (namprd02 and namprd03) ten minutes apart give the identical result, so it is not one unhealthy server. Two frontend variants — one advertising LOGINDISABLED, one advertising AUTH=PLAIN AUTH=XOAUTH2 — also give the identical result, so it is not one bad frontend build.

Connection A — imap://…@outlook.office365.com:993/select>^INBOX
Connection B — imap://…@outlook.office365.com:993/discoverallboxes
Both against backend CH5PR02CA0014.namprd02.prod.outlook.com.
An earlier run at 18:08 UTC hit BN9PR03CA0296.namprd03.prod.outlook.com (sessions f99ac12f-1e63-4b8b-b642-574de4fb84a0 and 36b1d91c-f479-487c-b398-e08efc6e7cf6) with identical results on both connections.

18:18:06.912 * OK Microsoft Exchange IMAP4 service ready.
             20bd1262-3b87-4f2b-a807-7882c6c4d37b
             (tcpproxy/15.21.0382.004 BACKENDAUTHENTICATE)
18:18:06.918 43 capability
18:18:06.949 * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR
             UIDPLUS MOVE ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+
18:18:06.957 43 OK CAPABILITY completed.
18:18:06.963 XOAUTH2 auth
18:18:08.469 44 AUTHENTICATE XOAUTH2 <suppressed>
18:18:09.365 44 NO User is authenticated but not connected.
18:18:09.365 authlogin failed / Marking auth method 0x800000000 failed
18:18:09.365 No remaining auth method
18:18:09.875 login failed entirely
18:18:09.947 URL failed with code 0x80004005 (select>^INBOX)

18:18:10.637 49 NO User is authenticated but not connected.
18:18:10.656 login failed entirely
18:18:10.667 URL failed with code 0x80004005 (discoverallboxes)

Prior report: question 5673167, filed 2025-12-19, same error string on a consumer Outlook.com account, still unanswered with 10+ same-question votes. There the AUTHENTICATE succeeds and NAMESPACE returns BAD; here the AUTHENTICATE tag itself returns NO. Same BACKENDAUTHENTICATE stage per the server banner, plausibly the same defect surfacing one command earlier. That question is tagged Exchange Online, which is likely the wrong audience for a consumer mailbox, hence this one.

Request: investigation of the handoff between OAuth token validation and IMAP session establishment for consumer Outlook.com mailboxes.