I recently migrated a domain from an independent provider using IMAP/SMTP to a Microsoft 365 business tenant. The mail migration completed successfully, classic Outlook on Windows works, and MFA is configured.
Outlook Mobile on Android still refuses to add the account. I removed the old account, cleared Outlook's cache and data, uninstalled and reinstalled the app, and tried removing the old IMAP-related MFA entry. When I add [email protected] and choose the Work or School account option, Outlook displays:
"We're unable to complete your request — unauthorized_client: The client does not exist or is not enabled for consumers."
It seems as though Outlook Mobile may be using stale tokens or autodiscover information and is sending authentication to the Microsoft consumer service instead of the business tenant. Authenticator still shows the old account as a connected account and will not let me remove it, but I would prefer not to reinstall Authenticator because it contains around 20 other entries that would need to be revalidated.
The Microsoft 365 DNS records have been configured according to Microsoft's recommendations. What else can I try to get Outlook Mobile authenticated against the business tenant?
4 Answers
Try adding the account with the tenant's onmicrosoft.com address instead of the custom domain. That can bypass the consumer-account detection and send the Android app directly to the Microsoft 365 sign-in flow. Once authentication succeeds, the custom address may be usable afterward.
Also check whether the Android phones are enrolled in mobile-device management. An MDM profile can silently push an old Outlook configuration or account setting, causing the app to keep using the previous sign-in details even after reinstalling it.
Outlook Mobile can use different autodiscover behavior from desktop Outlook. After an IMAP-to-Microsoft 365 migration, stale autodiscover data may continue sending mobile clients to the old service or the wrong sign-in endpoint. Confirm the Microsoft 365 DNS records, especially autodiscover, and then allow time for cached information to expire. In some cases this may require waiting a day or two, and Microsoft Support may need to clear or investigate the cached service data.
Check the domain's autodiscover records and validate the whole Exchange Online configuration with Microsoft's Exchange connectivity test. This can help distinguish a DNS or autodiscover problem from an Outlook Mobile token problem.
The DNS records are configured according to Microsoft's guidance, so I'll keep checking them and allow some time for the old autodiscover information to expire.