Autodiscover resolves in an order, and the order is the bug
Six lookup methods, first answer wins. After a migration the second one is usually a server that no longer exists.
Almost every post migration Outlook problem I have worked on comes back to one sentence: Autodiscover is an ordered list, and it stops at the first thing that answers. Not the first thing that answers correctly. The first thing that answers.
The order
A domain joined Outlook client works through roughly this sequence:
- A local XML file or policy override, if one has been placed on the machine.
- The service connection point published in Active Directory.
- The root domain over HTTPS.
- The autodiscover subdomain over HTTPS.
- An HTTP redirect, then an SRV record in DNS.
- The Microsoft 365 endpoint directly.
Your mailbox is at the bottom of that list. Everything above it is a chance to be intercepted.
Why the SCP is the one that gets you
The service connection point is an object in Active Directory that says "Autodiscover lives here". It was published when Exchange was installed. It does not know the migration happened, because nothing in the migration process removes it.
So the machine asks Active Directory, gets a confident answer pointing at the old server, and goes there. If the server is still running but no longer holds the mailbox, it responds with something unhelpful and the client accepts it as authoritative. If the server is off, some clients fall through and some sit there timing out.
The user experiences this as a password prompt. They type the correct password. It is rejected, because they are authenticating against a server that no longer has their mailbox. They type it again. This is the password loop, and it has nothing to do with passwords.
Why the usual fixes only appear to work
Clearing the credential store fixes it until the client asks Autodiscover again, which is soon. Recreating the profile fixes it until the new profile asks Autodiscover, which is immediately. Both of those actions are downstream of a lookup that is still returning the wrong answer.
This is why the same ticket comes back on Wednesday with a note saying it worked on Monday. It did work on Monday. The cause was never touched.
How to tell which step answered
Outlook will tell you, if you ask. Hold Ctrl, right click the Outlook icon in the notification area, and choose Test E-mail AutoConfiguration. Untick the guessmart options so you are testing the real path, run it, and read the Log tab.
The log lists each attempt in order with its result. The first successful one is the answer the client is using, and if that line points somewhere you decommissioned, you have found the problem in under a minute. I have watched this turn a two hour escalation into a one line answer more times than I can count.
Fixing it properly
There are two halves and both are necessary.
The estate half. Retire the service connection point deliberately as part of the cutover, not as cleanup. It sits in Active Directory and it will keep answering for as long as it exists. On the DNS side, make sure the autodiscover record points where you want the fallback to land.
The client half. Machines that already cached a bad answer need that cache cleared. This is what the fourth step of my repair toolkit does, and it is the step that stops the ticket coming back.
The part worth internalising
Ordered fallback chains fail in a specific way: a stale entry near the top makes everything below it unreachable, and the symptom appears at the bottom. You debug where the failure is visible, and the cause is several steps earlier in a lookup you were not thinking about.
When something resolves in a defined order, the bug is almost never in the step that failed. It is in the step that succeeded too early.
Autodiscover is the version of this I meet most often. It is not the only one.