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 eight lookups it stopped at. You need both, because they disagree more often than you would expect.

They disagree because Outlook checks those eight places in a fixed order and stops at the first one that answers. Not the first one that answers correctly. The first one that answers at all.

That single design decision is behind almost every Autodiscover problem I have ever been called about. Somebody's website politely returns a page at https://yourdomain.com/autodiscover/autodiscover.xml, Outlook takes that as the answer, and now you are debugging a mail client using a web server's homepage.

So before you touch anything, find out which of the eight 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 and the newer JSON v2 endpoint, plus the Thunderbird and Apple autoconfig paths, and reports what each one returned: HTTP status, TLS validity, and the actual server names inside the XML.

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. 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. It is documented by Microsoft, tucked into a support article about a cross-forest mailbox fault, 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. 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.

It is Windows and classic Outlook only. New Outlook and Outlook for Mac both resolve settings through Microsoft's cloud service and expose nothing equivalent, so on those the external check is all the evidence you are getting.

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

This trips up everybody, including me the first time.

Fetch https://autodiscover.yourdomain.com/autodiscover/autodiscover.xml in a browser and a working Microsoft 365 setup returns HTTP 401 Unauthorized. That 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.

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 treats that as a reply, tries to parse it as configuration XML, fails, and reports something unhelpful about not being able to connect to the server.

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 autodiscover.outlook.com.

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

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 failed, 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. 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:

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 worse, an IP has no name for TLS to validate against, so users get a certificate warning naming a host they have never heard of. People click through certificate warnings, which is its own problem for another day.

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. 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. 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. Google does not implement it. 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 and current Microsoft 365 builds 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. 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: since May 2025 Google Workspace has refused plain username-and-password sign-in from third-party clients, so you are using OAuth either way. None of the three consult an Autodiscover record, so no amount of DNS work will improve any of them.

I have watched people spend a genuinely sad amount of time trying to make a protocol work for a provider that does not speak it. If the domain's MX records point at Google, stop here.

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. There are also RFC 6186 SRV records (_imaps._tcp, _submission._tcp and friends) that some clients honour and many ignore.

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.

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

In September 2021, Guardicore published research on Outlook implementations 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. The researchers registered twenty such names and, between April and August 2021, collected 372,072 Windows domain credentials, 96,671 of them unique, 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.

The twenty domains were TLD variants like autodiscover.fr, autodiscover.xyz and autodiscover.com.br. No .co.za in the set, 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 has since changed the back-off behaviour and the specific hole is narrower than it was. The lesson survives: 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.

Rough order, from a client that has never connected before: policy or registry overrides and any local XML file, then Microsoft's direct 365 endpoint for supported builds, then the SCP lookup in Active Directory if the machine is domain-joined, then the root domain over HTTPS, then the autodiscover subdomain over HTTPS, then an HTTP redirect on that same name, then the SRV record. Then it gives up and falls back to the last setting it knows worked.

I would not swear to that order to the digit across every Outlook build. Microsoft has moved the 365 direct-connect step around more than once, and a machine joined to a domain behaves differently to a laptop that is not. Read your own log rather than trusting my list or anybody else's. 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 the record turns out to be a leftover from a migration that never finished, the wider version of that job — dropping TTLs first, verifying propagation before you flip, and the order to change things in — is a post of its own, coming shortly. And if mail is being rejected rather than misconfigured, that is the blocking article above, not this one.

Source: the credential-leak research is Guardicore's "Autodiscovering the Great Leak", published 22 September 2021 and now hosted by Akamai: https://www.akamai.com/blog/security/autodiscovering-the-great-leak