Outlook cannot set up the account, or connects to the wrong server

Always start here. Autodiscover has a built-in test that shows the whole sequence and where it stopped, and guessing without it wastes hours.

1. Hold Ctrl and right-click the Outlook icon in the notification area, then choose Test E-mail AutoConfiguration.

   This is the single most useful diagnostic for this fault and almost nobody knows it exists. It is hidden behind Ctrl because it is a support tool rather than a user feature.

2. Enter the address, clear the Use Guessmart and Secure Guessmart Authentication boxes, leave Use AutoDiscover ticked, and press Test.

3. Read the Log tab, not the Results tab. It lists every URL tried in order with the outcome of each, and the first success is the answer Outlook is using.

   The Results tab tells you what it found. The Log tab tells you where it found it, which is what you actually need in order to fix it.

4. Note the URL of the first successful step. That is the thing to correct — everything after it is irrelevant.

The log shows an internal Exchange URL being found, on a network where the mailbox has moved to Microsoft 365.

1. List the service connection points published in Active Directory.

   PowerShellCopy

   ([adsisearcher]'(&(objectClass=serviceConnectionPoint)(serviceClassName=ms-Exchange-AutoDiscover-Service))').FindAll() | ForEach-Object { $_.Properties.servicebindinginformation }

   A domain-joined machine checks AD before it checks DNS, and it trusts what it finds. A decommissioned Exchange server that was never cleanly removed leaves its SCP behind, and every domain-joined client keeps being sent to it.

2. If the old Exchange server is genuinely gone, the SCP should be removed as part of decommissioning it. That is an Exchange administration task and should be done properly rather than by deleting objects by hand.

3. As an interim measure on affected clients, tell Outlook to skip the SCP lookup.

   PowerShellCopy

   $k='HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover'New-Item $k -Force | Out-NullSet-ItemProperty $k -Name ExcludeScpLookup -Type DWord -Value 1

4. Restart Outlook and run the AutoConfiguration test again to confirm it now moves past that step.

5. Treat the registry value as temporary. It is a client-side workaround for a server-side problem, and it has to be deployed to every machine and every new build until the SCP is actually removed.

   This is the step that turns a two-week fix into a permanent piece of estate debt if it is skipped. Record it somewhere and remove it once the SCP is gone.

Setup fails from any network, or the log shows a lookup failing at the DNS steps.

1. Check the autodiscover record for the mail domain.

   PowerShellCopy

   Resolve-DnsName autodiscover.yourdomain.com | Select-Object Name, Type, NameHost, IP4Address

   For Microsoft 365 this should be a CNAME to autodiscover.outlook.com. An A record pointing at an old server, or no record at all, is the usual finding.

2. Check whether anything is answering at the root of the domain on 443, since that step comes first.

   PowerShellCopy

   Test-NetConnection yourdomain.com -Port 443 | Select-Object RemoteAddress, TcpTestSucceeded

   A marketing website at the domain root will answer the https root-domain probe and return HTML rather than autodiscover XML. Outlook has to time out on it before moving on, which is why setup can take minutes and then fail.

3. Check for an SRV record, which is the supported alternative when the root domain is in use.

   PowerShellCopy

   Resolve-DnsName -Type SRV _autodiscover._tcp.yourdomain.com -ErrorAction SilentlyContinue

4. Run Microsoft's remote analyser against the address, which tests the whole sequence from outside your network and reports each step.

   PowerShellCopy

   Start-Process 'https://testconnectivity.microsoft.com/'

5. Correct the records at the DNS provider. Allow for the TTL before retesting, and remember that a negative answer can be cached too.

One machine behaves differently from the rest, or a certificate warning names an unexpected domain.

1. Read the whole AutoDiscover key. Anything in it is an override somebody applied deliberately at some point.

   PowerShellCopy

   Get-ItemProperty 'HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover' -ErrorAction SilentlyContinue

   ExcludeHttpsRootDomain, ExcludeHttpsAutoDiscoverDomain, ExcludeSrvRecord, PreferLocalXML and ExcludeExplicitO365Endpoint each remove a step from the sequence. A value copied from a forum years ago to fix something else is a common cause of a machine that will not set up now.

2. Check the policy hive as well, which overrides the user one.

   PowerShellCopy

   Get-ItemProperty 'HKCU:\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover' -ErrorAction SilentlyContinue

3. Back up the key before clearing it, so you can put back anything that turns out to have been load-bearing.

   PowerShellCopy

   reg export "HKCU\Software\Microsoft\Office\16.0\Outlook\AutoDiscover" "$env:USERPROFILE\Desktop\autodiscover-backup.reg" /y

4. Remove the overrides that are not deliberate, then restart Outlook and retest.

   PowerShellCopy

   Remove-Item 'HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover' -Recurse -Force -ErrorAction SilentlyContinue