Outlook can't connect or set up the account: Autodiscover troubleshooting for Exchange Online

"Something went wrong and Outlook couldn't set up your account", a profile that keeps asking for a password, or a mailbox that was migrated last night and now shows Disconnected: nearly every one of these traces back to Autodiscover, the lookup Outlook uses to learn where a mailbox lives and how to talk to it. In this post I'll explain how classic Outlook for Windows actually performs that lookup against Exchange Online, which tools show you where it fails, and how to fix the causes you'll meet most often.

Symptoms#

• Adding the account fails with "Something went wrong and Outlook couldn't set up your account", or the wizard offers IMAP/POP instead of Exchange.
• Outlook connects but keeps prompting for credentials, or the prompt is an old-style Windows dialog rather than the Microsoft Entra sign-in page.
• After a hybrid migration, Outlook stays Disconnected or still points at the on-premises server; Outlook on the web works fine.
• Free/busy, Out of Office or shared mailbox mapping fail even though mail flows, which means Outlook got a mailbox connection but not the Exchange Web Services URLs that Autodiscover supplies.

Why it happens#

For Exchange Online the only DNS record you need is a CNAME: autodiscover.contoso.com pointing to autodiscover.outlook.com. Outlook doesn't go straight there, though. The current Click-to-Run implementation tries an ordered list and stops at the first payload it gets: a restart cache and an admin-deployed local XML file (rarely used), the last known good URL cached in the profile, then, if Outlook is confident the account is a Microsoft 365 account, the Microsoft 365 endpoint https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml directly. Only after that comes the classic sequence: the Active Directory SCP lookup on domain-joined machines, https://contoso.com/autodiscover/autodiscover.xml, https://autodiscover.contoso.com/autodiscover/autodiscover.xml, the local XML again, an HTTP redirect check, the _autodiscover._tcp SRV record, and finally the Microsoft 365 endpoint once more as a failsafe. Each step has a registry switch under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover (or the Policies equivalent), such as ExcludeScpLookup, ExcludeHttpsRootDomain, ExcludeHttpsAutoDiscoverDomain, ExcludeHttpRedirect, ExcludeSrvRecord, ExcludeExplicitO365Endpoint and ExcludeLastKnownGoodURL; a value of 1 skips that step.

So the failures cluster into a few families: the DNS record is missing or points somewhere else; an earlier step answers before Exchange Online gets a chance (an on-premises SCP or Autodiscover service that no longer knows the mailbox, or a web host answering on the root domain); the client is too old or configured for legacy authentication and Exchange Online, which no longer accepts Basic authentication for Outlook, rejects it; or the profile and cached credentials are wrong and Outlook keeps reusing them. Repeated modern-authentication prompts that show the Entra sign-in page are usually an identity problem (Conditional Access, token lifetime, a stale device state) rather than an Autodiscover one.

How to fix it#

1. Check the record from outside your network.
   PowerShell

   Resolve-DnsName autodiscover.contoso.com -Type CNAME
   # Expected: autodiscover.contoso.com  CNAME  autodiscover.outlook.com
   Resolve-DnsName _autodiscover._tcp.contoso.com -Type SRV   # only if you rely on SRV instead

   Internal DNS matters too: split-brain zones often still hold an A record for the old on-premises server. Fix the zone users actually query.
2. Run Test E-mail AutoConfiguration on the affected PC. With Outlook running, hold Ctrl, right-click the Outlook icon in the notification area and choose Test E-mail AutoConfiguration. Enter the address, clear the two Guessmart boxes, leave Use AutoDiscover selected and run it. The Log tab lists every step in the order above with its result; the XML tab shows the payload that won. For a healthy Exchange Online mailbox you should see the autodiscover-s.outlook.com attempt succeed and the XML pointing at outlook.office365.com. If the log shows an SCP or an on-premises URL returning an error before that, you've found the step that's getting in the way.
3. Test from the internet with the Microsoft Remote Connectivity Analyzer. At testconnectivity.microsoft.com pick the Exchange Online tests, run the Outlook Autodiscover and Outlook Connectivity scenarios with a working account, and read the step-by-step results. It uses a dedicated set of source IP addresses (listed on its Microsoft Learn page), so allow those through if everything fails instantly with no detail.
4. Stale on-premises Autodiscover after migration. In a healthy hybrid, the on-premises Autodiscover service answers for a moved user with a redirect to the user's mail.onmicrosoft.com target address, and Outlook follows it. That breaks if the on-premises object is no longer a remote mailbox, if the SCP points at a decommissioned server, or if the record still points on-premises after the last mailbox left. Microsoft documents ExcludeScpLookup = 1 for the hybrid delay/wrong-result case, and removing the SCP objects once Exchange Server is gone. Once all mailboxes are in the cloud, point the CNAME at autodiscover.outlook.com and let the on-premises namespace go.
5. Old clients and legacy authentication. Office 2016 and 2019 left support in October 2025; Microsoft 365 Apps, Office LTSC 2021/2024 and new Outlook use modern authentication by default. If a user is on an unsupported build or a profile created with Basic authentication, update the client and recreate the profile rather than hunting registry keys.
6. Profile and credential corruption. Remove the account's entries from Windows Credential Manager, create a new Outlook profile (Control Panel › Mail › Show Profiles) and let Autodiscover rebuild it. Repairing the existing profile re-runs Autodiscover too, but a fresh profile also clears the cached last-known-good URL.
7. Let Microsoft's diagnostics look. The Microsoft Support and Recovery Assistant (SaRA) is deprecated; its Outlook diagnostics moved into the Windows Get Help app (Classic Outlook troubleshooters), and admins can script the command-line version with GetHelpCmd.exe -S ExpertExperienceAdminTask -AcceptEula, which writes its report under %LocalAppData%\GetHelp. In the Microsoft 365 admin center, Help & support also offers the Outlook User Connectivity diagnostic, which checks service-side settings for a specific user without touching their PC.

Verify the fix#

• Hold Ctrl, right-click the Outlook icon and open Connection Status: the mailbox connection should show outlook.office365.com with status Established, and new connections should appear without prompts.
• Test E-mail AutoConfiguration completes with a Microsoft 365 payload; free/busy for a colleague and Automatic Replies both open, proving the EWS settings arrived.
• The Remote Connectivity Analyzer Autodiscover test is green for the domain, so the fix isn't specific to one machine.

Prevent it next time#

• Keep one Autodiscover answer per namespace: when you add a domain to Microsoft 365, create the CNAME at the same time as the MX record.
• In hybrid, migrate in waves but decommission in one step: don't leave an on-premises Autodiscover service answering for a namespace with no mailboxes behind it.
• Deploy the Autodiscover policy settings through the Office administrative templates rather than per-machine registry edits, and document any Exclude* value you set so it doesn't surprise the next admin.
• Keep clients on supported builds; most "mystery" prompts disappear with a current Microsoft 365 Apps channel.

References#

• Outlook 2016 implementation of Autodiscover (Microsoft Support)
• Delay when Outlook retrieves Autodiscover information in a hybrid environment (Microsoft Learn)
• Microsoft Remote Connectivity Analyzer (Microsoft Learn)