What Is Autodiscover? Outlook's Setup Mechanism Explained

You finish the cutover, point MX at the new tenant, send a test message, and it lands. Then a user opens Outlook and it still connects to the old Exchange server. That's Autodiscover doing its job — just not the job you wanted. Autodiscover is the service Outlook uses to find mail-server settings from an email address, and it's responsible for more "the migration looked fine until users opened Outlook" tickets than any other single piece of plumbing. Here's what it is, how it works, and how to keep it from sabotaging your next cutover.

The short definition#

Autodiscover is a Microsoft protocol that lets Outlook (and other compatible clients) work out where to connect using only an email address. Type alice@contoso.com, and Outlook asks: where do I find the mailbox for contoso.com? Autodiscover returns the server name, the protocol (MAPI/HTTP or EWS), the URLs for free/busy and Out-of-Office, and a bundle of other client settings.

It was introduced in Exchange 2007 and is still how every Outlook for Windows version sets up a profile in 2026.

How Outlook actually looks it up#

When Outlook starts profile setup for alice@contoso.com, it walks an ordered chain. The exact list shifts between versions, but the core sequence is:

1. SCP lookup in Active Directory — only if the machine is domain-joined to an AD with on-prem Exchange.
2. HTTPS POST to https://autodiscover.contoso.com/autodiscover/autodiscover.xml
3. HTTPS POST to https://contoso.com/autodiscover/autodiscover.xml
4. DNS SRV lookup for _autodiscover._tcp.contoso.com — returns a host and port to try.
5. HTTP redirect chain — follows 302 responses.
6. Office 365 fallback — tries autodiscover-s.outlook.com.

The first step that returns a valid XML response wins. Outlook then caches the result and reuses it for hours. That cache is the single biggest reason a migration "doesn't take."

The DNS records you actually publish#

For a clean Microsoft 365 tenant, the standard record is a CNAME:

autodiscover.contoso.com.   CNAME   autodiscover.outlook.com.

For a hybrid setup you might keep it pointed at your on-prem Exchange edge:

autodiscover.contoso.com.   A       203.0.113.10

For multi-domain or split configurations, the SRV record gives you per-target flexibility:

_autodiscover._tcp.contoso.com.  SRV  0 0 443 mail.contoso.com.

A CNAME and an SRV can coexist. Outlook will try the CNAME first; if it fails or returns a redirect Outlook can't follow, it falls back to the SRV. Belt-and-braces is fine here — the only thing you must not do is leave a record pointing at the wrong tenant.

How Autodiscover breaks during migrations#

Five failure modes show up over and over.

The record still points at the old tenant. Easy to fix, but if Outlook has cached the old answer, users will need to recreate the profile or wait out the cache. Restart Outlook with /cleanautodiscovercache from a run prompt, or simpler: rebuild the profile.

The SRV record is missing or wrong. Some registrars don't expose SRV records in their default UI. Use a proper DNS provider (Cloudflare, Route53, Azure DNS) where you can publish SRV records cleanly.

Hybrid is still publishing the on-prem endpoint. If you ran Exchange hybrid during a long migration and then decommissioned on-prem, Exchange Online keeps using your hybrid Autodiscover until you change the TargetAutodiscoverEpr value on the relevant organization relationship. See the hybrid Exchange explainer for the wider picture.

TLS certificate mismatch. Autodiscover requires HTTPS. If autodiscover.contoso.com resolves to a host whose certificate doesn't include that name, Outlook will refuse the response and silently fall through. Check the certificate covers every Autodiscover hostname you publish.

MX is right but Autodiscover isn't. Mail flows. Outlook breaks. This is the classic late-night ticket. The fix is to update Autodiscover and force Outlook to rediscover, which usually means Ctrl+right-click on the Outlook tray icon → Test E-mail AutoConfiguration.

How Autodiscover fits with everything else#

Autodiscover is one of three DNS pieces that have to be right for a cutover to land cleanly. The other two are MX (where mail goes) and SPF/DKIM/DMARC (whether mail is trusted). See the MX record explainer for the inbound-mail half of the story.

For a wider migration playbook, the Microsoft 365 migration guide and the Exchange migration guide both treat Autodiscover as a first-class cutover step. If you're moving from on-prem to the cloud specifically, the Exchange to Microsoft 365 walkthrough has the exact PowerShell to flip the TargetAutodiscoverEpr value on cutover day.

Testing Autodiscover quickly#

Microsoft's Remote Connectivity Analyzer at testconnectivity.microsoft.com is the gold standard — pick "Outlook Autodiscover" and feed it a real user account. It walks the same chain Outlook walks and prints each step's response, which is invaluable when something is "almost" working.

From an Outlook client, hold Ctrl and right-click the Outlook tray icon, then choose "Test E-mail AutoConfiguration." That dialog shows the URLs Outlook tried, the response it got, and the discovered settings — useful for confirming a fix actually took.