How to check Autodiscover, and the four ways it breaks

To check Autodiscover, run the domain through an external checker first, then run Outlook's own Test E-mail AutoConfiguration, and compare the two. The external check tells you what the DNS actually says; Outlook's log tells you which of the eleven lookups it stopped at. You need both, because they disagree more often than you would expect.

They disagree because Outlook works through those eleven places in a fixed order and stops at the first one that hands back something it can read as a configuration payload. Not the first one that hands back the right payload. The first one that hands back any.1

That single design decision is behind almost every Autodiscover problem I have ever been called about.2 One of our clients had Autodiscover and autoconfig records going back years, from when their mail was POP, each with its own TTL. Their staff were on old Outlook, new Outlook and Thunderbird, and all of them were still being pointed at the old server. We had to clear every one of those records out as part of their move to Google Workspace, so none of them could conflict with it.3

So before you touch anything, find out which of the eleven answered.

How do you check Autodiscover?

Run the domain through an external checker, then run Outlook's own test, and compare the two. The Autodiscover checker on this site does the first half: give it a domain and it probes the autodiscover CNAME, the _autodiscover._tcp SRV record, the legacy XML endpoint, the newer JSON v2 endpoint and the plain-HTTP redirect Microsoft 365 answers on port 80, plus the Thunderbird and Apple autoconfig paths, and reports whether each one answered, the TLS certificate on the autodiscover and autoconfig hosts, and the server names inside any autoconfig XML it finds.4

Do the external check first, because Outlook lies to you by caching. Once it has found a working endpoint it remembers it, and it will keep using a stale answer long after you have fixed the DNS.5 An external check has no memory and no opinion.

Then test inside Outlook, because that is where the cache lives. Classic Outlook for Windows has a diagnostic hidden behind a keyboard modifier, which is a strange place to keep something this useful, and most people who have administered Outlook for years have never opened it. Hold Ctrl, right-click the Outlook icon in the system tray, and choose Test E-mail AutoConfiguration. Untick Guessmart and Secure Guessmart Authentication, leave Use Autodiscover ticked, and hit Test.6 It is documented by Microsoft, in an archived troubleshooting article about registry keys, which tells you something about how much attention it gets.

You get three tabs. Log is the one you want: every URL Outlook tried and what came back, in order. XML is worth a look too, because it shows you the configuration Outlook was actually handed, server names and all.7 It is not a pretty tool, and it tells you what Outlook did rather than what it should have done, which is the only question worth asking at this point.

Microsoft documents it for classic Outlook on Windows only. On new Outlook and Outlook for Mac, the external check and Microsoft's Remote Connectivity Analyzer are the evidence you are getting.8

A 401 is the healthy answer, and a 200 is usually the broken one

This trips up everybody, including me the first time.9 On Microsoft 365 the 401 is also not where you would go looking for it.

Point a browser at https://autodiscover.yourdomain.com/autodiscover/autodiscover.xml on a Microsoft 365 domain and you get a connection error, not a page. Nothing is broken. autodiscover.outlook.com, which is what every Microsoft 365 autodiscover CNAME points at10, does not listen on port 443 at all. It listens on port 80, and it answers with a redirect:1112

$ curl -sD - -o /dev/null http://autodiscover.yourdomain.com/autodiscover/autodiscover.xml
HTTP/1.1 302 Found
Location: https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml

Follow it and there is the 401 you were looking for:13

$ curl -so /dev/null -w '%{http_code}\n' https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
401

That 401 is correct. You did not send credentials, so the endpoint refused you. It refused you as an Autodiscover endpoint, which is exactly the proof you were after. The plain-HTTP hop in the middle is a designed part of the path. It is Outlook's HTTP-redirect step.14

An on-premises or hybrid Exchange server is the case where https://autodiscover.yourdomain.com/... answers 401 on port 443 directly, because that host really is serving the endpoint itself.

A 200 OK with a page of HTML means something answered that is not a mail service, usually the web host, sometimes a parking page, occasionally a registrar's "this domain is registered with us" placeholder. Outlook will not accept a homepage as configuration and moves on to the next step.15 It has still told you that the name is aimed at a web server, and the day that web server starts issuing redirects or serving XML, Outlook will believe it.

The symptom will look like a mail problem. Go and look at what is answering on that hostname before you touch anything in Microsoft 365.

The Autodiscover SRV record is the fallback, and users click it away

The record looks like this:

_autodiscover._tcp.yourdomain.com.  SRV  0 0 443 mail.yourhost.com.

Priority, weight, port, target. Port 443, always.

That example is for hosted or on-premises Exchange. Microsoft 365 publishes no SRV value, and Outlook reaches Microsoft's own endpoints at step four, long before it gets to SRV.16

You need it when you cannot put a CNAME on the autodiscover name itself. Some registrars are strange about it, and occasionally the name is already in use for something else. Outlook checks SRV near the end of its list, after both HTTPS attempts have failed17, so it only ever runs when the ordinary route is genuinely unavailable.

It works, with one catch worth knowing before you deploy it. When Outlook follows an SRV record it shows the user a dialog asking whether to allow the site to configure their settings, naming a host that is not their domain (Microsoft documents this for SRV in its Outlook 2007 article, last updated January 2021).18 Users click No. Of course they click No. Somebody has trained them for years to be suspicious of exactly that dialog, and now the correct answer is Yes.

If you are rolling this out to more than a handful of people, tell them the dialog is coming and what to click. Otherwise it works perfectly and nobody can use it.

Three failures cover nearly all the rest

The CNAME is an A record

For Microsoft 365 the record is a CNAME:19

autodiscover.yourdomain.com.  CNAME  autodiscover.outlook.com.

Not an A record pointing at whatever IP autodiscover.outlook.com resolved to on the day someone set it up. That IP will change, and in the meantime Microsoft does not answer HTTPS on it at all. Outlook falls through to the plain-HTTP redirect, and the user gets a dialog asking whether to let autodiscover-s.outlook.com configure their settings, naming a host they have never heard of.20

Look up the record type rather than trusting what you remember it being, and if you want the whole subdomain picture at once, the CNAME checker walks the common sub-hosts and follows each alias to its target.21 This one is frequently inherited from a previous IT provider along with everything else.

The record still points at the old host

You migrated to Microsoft 365 in March. The autodiscover record still points at the old shared hosting server, which is still up, still answering, and still holding a copy of a mailbox that stopped receiving new mail four months ago.

The symptom is a password prompt that keeps coming back. The user types the correct password, it is accepted by nothing, the box reappears. Everyone reasonably concludes it is an account problem, and the next hour goes into resetting passwords, checking MFA, and looking at sign-in logs that show nothing wrong, because nothing is wrong with the account. Outlook is authenticating against the wrong server, and it found that server because you told it to, in DNS, in March.

Check the DNS before you touch the account. The Microsoft 365 record check reads the whole tenant-facing set in one pass, so you can see at a glance whether autodiscover is the only leftover or whether the MX and SPF records were left behind too.22 The account is almost never the problem when the prompt loops, and if mail itself is also going missing rather than just prompting, that is a different investigation.

Google Workspace domains do not do Autodiscover at all

Autodiscover is a Microsoft protocol, and none of Google's Outlook setup routes use an Autodiscover record.23 If your mail is on Google Workspace there is no Autodiscover record to fix, and any autodiscover CNAME sitting in your zone pointing at Microsoft is a leftover that can only cause harm.

That does not mean setting it up is manual. In new Outlook for Windows you add the account by picking Google and signing in, Google's OAuth flow hands the settings over, and mail, calendar and contacts arrive without you typing a server name anywhere. Classic Outlook gets mail only that way; calendar and contacts need Google Workspace Sync.24 It feels exactly like Autodiscover working. It isn't. Nothing in that exchange ever looked at your DNS.

The other two routes are Google Workspace Sync for Microsoft Outlook and IMAP entered by hand, which is now a fallback rather than a normal choice: Google turned off username-and-password sign-in for third-party apps on 14 March 2025, so IMAP means OAuth or an app password, never the account password.25 None of the three consult an Autodiscover record, so no amount of DNS work will improve any of them.

If the domain's MX records point at Google, there is nothing to set up, only leftovers to delete. Our client moving to Google Workspace needed exactly that clean-up, and their records did not share a TTL, so they did not all disappear at the same moment. Lower each record's TTL and wait out the old value before you delete it, or expect some resolvers to keep serving the old answer for as long as the longest TTL allows.26

Thunderbird and Apple Mail never look at Autodiscover either

Autodiscover is Microsoft's. The rest of the world uses autoconfig, which is a different mechanism with different records, and a domain can quite easily satisfy one and fail the other.

Thunderbird looks for https://autoconfig.yourdomain.com/mail/config-v1.1.xml, then https://yourdomain.com/.well-known/autoconfig/mail/config-v1.1.xml, then falls back to Mozilla's public ISPDB, a database of settings for known providers, which is why Thunderbird configures Gmail perfectly while knowing nothing about your domain.27 There are also RFC 6186 SRV records (_imaps._tcp, _submission._tcp and friends) that some clients honour and many ignore.28

So "Autodiscover is fine" and "our users can set up mail" are two different statements. If the complaint comes from someone who is not in Outlook, checking the Autodiscover record tells you nothing at all.

Some mail clients never look at any of it. The same client had one person still on Outlook Express, which nobody knew about. It was hard-coded to the old server and never used Autodiscover at all, so no DNS change could move it, and nothing showed until the password failed when they tried to connect.29 Find out who is on what before you start deleting records.

The domain-chain fallback is a real credential leak, not a theoretical one

In September 2021, Guardicore published research on Autodiscover clients (Outlook, mobile mail apps, anything else that speaks the protocol) that, having failed to find Autodiscover inside a user's own domain, backed off up the domain chain and requested autodiscover.<tld> instead, a domain nobody at the company owned.30 The researchers registered twenty such names and, between April and August 2021, collected 372,072 Windows domain credentials, 96,671 of them unique31, sent to them by mail clients that had simply run out of places to look. Worse, the clients did not wait to be challenged: they attached the credentials to the request up front rather than after a 401.32

The twenty domains were TLD variants like autodiscover.fr, autodiscover.xyz and autodiscover.com.br. No .co.za in the set33, so if you are reading this from Johannesburg you were not in that particular catch. But nothing about the mechanism was specific to those TLDs, and the reason your TLD was clean is that nobody had got round to registering it. That is not a security control.

Microsoft's public response was to dispute how the research was disclosed rather than to describe a fix.34 The mitigations Guardicore published are the customer's: block the autodiscover.<tld> names at the firewall, and turn off basic authentication so there is no plaintext password to leak.35 The lesson underneath survives either way: a domain with no valid Autodiscover configuration is not neutral. Clients keep looking, and where they look next is not up to you. Configure it properly, or make sure it fails fast, which mostly means not leaving half a configuration behind after a migration.

Read the log in order, not the error at the end

Whatever tool you use, the useful information is the sequence rather than the final message. The final message is nearly always the same tired string about not being able to connect. The sequence tells you which step answered, and the step that answered is your bug.

Microsoft publishes the order for current Outlook builds, and it runs to eleven steps: a restart check, an administrator-deployed XML file, the last-known-good cached payload, Microsoft's direct 365 endpoint, the SCP lookup in Active Directory if the machine is domain-joined, the root domain over HTTPS, the autodiscover subdomain over HTTPS, the local XML file a second time, an HTTP redirect on the autodiscover name, the SRV record, and finally a less fussy second attempt at the 365 endpoints.36

Last known good is step three, ahead of every lookup that touches the network. That is why the DNS you fixed this morning may not show up in Outlook for days, and why the external check has to come first.37

That is Microsoft's list rather than mine, and a domain-joined desktop behaves differently to a laptop that is not.38 Read your own log rather than trusting any list. The order in front of you is the order that matters.

Run the domain through the checker, take the Log tab from Test E-mail AutoConfiguration, and put them side by side. The step that answered when it should not have is the one to go and delete.

If our checker and Outlook's log disagree and you cannot see why, send me both at [email protected] and I will tell you which step answered.

If the record turns out to be a leftover from a migration that never finished, the wider job is the same shape one record at a time: drop the TTL, verify propagation, then flip. And if mail is being rejected rather than misconfigured, that is a blocking problem, not an Autodiscover one.

Source: the credential-leak research is Guardicore's "Autodiscovering the Great Leak", published 22 September 2021 and now hosted by Akamai39.

Sources checked

Each claim above was checked against the source named here on 3 October 2026, and every source was fetched again on 4 October 2026. Vendor pages move and change, so follow the link rather than trusting the date.

1. “Every time that Outlook needs Autodiscover information, it uses a set of ordered steps to try to retrieve an XML payload that contains configuration settings”. Source: Outlook 2016 implementation of Autodiscover, Autodiscover timing, read 3 October 2026. ↩
2. From the author's own client work. No outside source. ↩
3. From the author's own client work. No outside source. ↩
4. Our own tool, checked against its code. Source: TamingDNS Autodiscover checker. ↩
5. “When Autodiscover retrieves an XML payload successfully through any step, the payload may be cached locally as the "last known good" configuration”. Source: Outlook 2016 implementation of Autodiscover, Step 3: Check for Last Known Good (LKG) data, read 3 October 2026. ↩
6. “Press the CTRL key, right-click the Outlook icon in the notification area, and then click Test E-mail AutoConfiguration”. Source: Unexpected Autodiscover behavior if settings under the \Autodiscover key, More information, read 3 October 2026. ↩
7. “Click the XML tab, locate the <OABUrl> and </OABUrl> tags, and then copy the path that's displayed between the tags”. Source: How to troubleshoot the Outlook Offline Address Book in a Microsoft 365 environment, read 3 October 2026. ↩
8. “Applies to: Outlook 2019, Outlook 2016, Outlook 2013, Outlook 2010, Office Outlook 2007”. Source: Unexpected Autodiscover behavior if settings under the \Autodiscover key, read 3 October 2026. ↩
9. From the author's own client work. No outside source. ↩
10. “Helps Outlook clients to easily connect to the Exchange Online service by using the Autodiscover service”. Source: External Domain Name System records for Microsoft 365, External DNS records required for email in Microsoft 365 (Exchange Online), read 3 October 2026. ↩
11. Measured with dig +short A/AAAA autodiscover.outlook.com; for each address: curl --resolve autodiscover.example.com:443:<ip> https://.../autodiscover/autodiscover.xml and curl -sD - --resolve autodiscover.example.com:80:<ip> http://.../autodiscover/autodiscover.xml; curl https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml Run on 3 October 2026. ↩
12. Measured with dig +short A/AAAA autodiscover.outlook.com; for each address: curl --resolve autodiscover.example.com:443:<ip> https://.../autodiscover/autodiscover.xml and curl -sD - --resolve autodiscover.example.com:80:<ip> http://.../autodiscover/autodiscover.xml; curl https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml Run on 3 October 2026. ↩
13. Measured with dig +short A/AAAA autodiscover.outlook.com; for each address: curl --resolve autodiscover.example.com:443:<ip> https://.../autodiscover/autodiscover.xml and curl -sD - --resolve autodiscover.example.com:80:<ip> http://.../autodiscover/autodiscover.xml; curl https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml Run on 3 October 2026. ↩
14. “If the response is a valid redirect URL, Outlook follows the redirect and tries to retrieve a payload XML from the new URL”. Source: Outlook 2016 implementation of Autodiscover, Step 9: Check for HTTP redirects, read 3 October 2026. ↩
15. “If this step does not retrieve a payload, Outlook moves to step 7”. Source: Outlook 2016 implementation of Autodiscover, Step 6: Check root domain, read 3 October 2026. ↩
16. “Step 4: Check for O365 as priority”. Source: Outlook 2016 implementation of Autodiscover, read 3 October 2026. ↩
17. “If this step does not retrieve a payload, Outlook moves to step 10”. Source: Outlook 2016 implementation of Autodiscover, Step 9: Check for HTTP redirects, read 3 October 2026. ↩
18. “In Microsoft Office Outlook 2007, you cannot suppress the Autodiscover redirect warning for HTTP and SRV redirections”. Source: You cannot suppress the Autodiscover redirect warning in Outlook 2007, Symptoms, read 3 October 2026. ↩
19. “Helps Outlook clients to easily connect to the Exchange Online service by using the Autodiscover service”. Source: External Domain Name System records for Microsoft 365, External DNS records required for email in Microsoft 365 (Exchange Online), read 3 October 2026. ↩
20. Measured with dig +short A/AAAA autodiscover.outlook.com; for each address: curl --resolve autodiscover.example.com:443:<ip> https://.../autodiscover/autodiscover.xml and curl -sD - --resolve autodiscover.example.com:80:<ip> http://.../autodiscover/autodiscover.xml; curl https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml Run on 3 October 2026. ↩
21. Our own tool, checked against its code. Source: TamingDNS CNAME checker. ↩
22. Our own tool, checked against its code. Source: TamingDNS Microsoft 365 check. ↩
23. “If you don't want to use GWSMO, go to Add a Gmail account to Outlook”. Source: Get started syncing Google Workspace data, Windows, read 3 October 2026. ↩
24. “This is also available for Gmail and Yahoo accounts in new Outlook for Windows”. Source: Sync your account in Outlook to the Microsoft Cloud, read 3 October 2026. ↩
25. “Access to less secure apps will be turned off for all Google Accounts. CalDAV, CardDAV, IMAP, SMTP, and POP will no longer work with legacy passwords (basic authentication)”. Source: Transition from less secure apps to OAuth, Timeline for transition, read 3 October 2026. ↩
26. “a 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted”. Source: RFC 1035, §3.2.1. ↩
27. “The ISPDB is a central database that contains the configurations for most mail providers with a market share larger than 0.1%”. Source: Autoconfig (draft-ietf-mailmaint-autoconfig-06, Internet-Draft), §4.2, read 3 October 2026. ↩
28. “_submission._tcp SRV 0 1 587 mail.example.com”. Source: RFC 6186, §3.1. ↩
29. From the author's own client work. No outside source. ↩
30. “Between April 16th, 2021 to August 25th, 2021 we have captured:”. Source: Autodiscovering the Great Leak (Guardicore, now Akamai), read 3 October 2026. ↩
31. “372,072 Windows domain credentials in total”. Source: Autodiscovering the Great Leak, Executive summary, read 3 October 2026. ↩
32. “with the Authorization header already populated with credentials in HTTP basic authentication”. Source: Autodiscovering the Great Leak, Abusing the leak, read 3 October 2026. ↩
33. “Autodiscover.com.br – Brazil”. Source: Autodiscovering the Great Leak, read 3 October 2026. ↩
34. “Unfortunately, this issue was not reported to us before the researcher marketing team presented it to the media, so we learned of the claims today”. Source: Autodiscover flaw in Microsoft Exchange leaking credentials (SearchSecurity), Disclosure dispute, read 3 October 2026. ↩
35. “make sure that support for basic authentication is disabled”. Source: Autodiscovering the Great Leak, Mitigation, read 3 October 2026. ↩
36. “Step 3: Check for Last Known Good (LKG) data”. Source: Outlook 2016 implementation of Autodiscover, read 3 October 2026. ↩
37. “The first commonly successfully method to get an Autodiscover payload is from this last known good file”. Source: Outlook 2016 implementation of Autodiscover, Step 3: Check for Last Known Good (LKG) data, read 3 October 2026. ↩
38. “If the computer is domain-joined, Outlook performs an LDAP query to retrieve Service Connection Point data that returns a path of the Autodiscover XML”. Source: Outlook 2016 implementation of Autodiscover, Step 5: Check for SCP data, read 3 October 2026. ↩
39. “Written by Amit Serper September 22, 2021”. Source: Autodiscovering the Great Leak, read 3 October 2026. ↩