Outlook Autodiscover problems with Microsoft 365: DNS checks and fixes

When classic Outlook can't find a Microsoft 365 mailbox, troubleshoot the Autodiscover lookup before the mailbox. Check three things in order: a CNAME record autodiscover.contoso.com pointing to autodiscover.outlook.com, a root domain web server that wrongly answers Autodiscover requests, and leftover client settings (SCP lookups, a cached Autodiscover URL, registry or Group Policy exclusions) that send Outlook to the wrong place. Microsoft's Remote Connectivity Analyzer and Outlook's Test E-mail AutoConfiguration tool show which of these is failing.

Who this is for and what you will have at the end

This guide is for administrators supporting classic Outlook for Windows with Exchange Online mailboxes, especially after a migration or a domain change. Typical reports are "Outlook keeps asking for the server", "the profile was created as IMAP", "shared mailboxes and free/busy don't work" or "Something went wrong and Outlook couldn't set up your account".

At the end you will understand the order in which Outlook tries each Autodiscover method, you will have the DNS checks and the client-side checks to find the failing step, and the specific fix for each cause. The Get Help troubleshooters Microsoft mentions in this area work with classic Outlook only; they aren't available for new Outlook for Windows.

How Outlook finds a mailbox

Autodiscover is how Outlook gets the server settings for a mailbox from just an email address. Microsoft documents the order that Outlook 2016 follows; the 16.0 registry path below is also used by Office 2019 and Microsoft 365 versions of Outlook. Each step can be skipped with a DWORD value under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover, or the same path under Software\Policies, which takes precedence.

For all values except PreferLocalXML, 1 means "skip this step". Two consequences follow from this order:

• An earlier step that returns a wrong but valid-looking answer stops the search. A root domain web server (step 6) or a stale SCP record (step 5) can win before the correct autodiscover CNAME is ever used.
• An exclusion value set long ago, for example during an on-premises deployment, can silently skip the step that would now work.

Prerequisites

• Access to your public DNS zone and to the Microsoft 365 admin center Domains page.
• A test mailbox you can use with the Remote Connectivity Analyzer.
• Local administrator or registry access on an affected client, plus access to Group Policy if Outlook settings are managed centrally.
• Whether the domain is cloud-only or in an Exchange hybrid deployment, because the correct DNS target differs.

Step 1: Check the Autodiscover DNS record

For a domain whose mailboxes are all in Exchange Online, Microsoft's record is:

The domain setup page calls this record optional but highly recommended, while Microsoft's Outlook troubleshooting guidance states that Autodiscover and the related DNS records are required for Outlook connectivity to Exchange Online. In an Exchange hybrid deployment, the public Autodiscover record for your existing SMTP domains must point to your on-premises Exchange servers instead, so don't "fix" a hybrid domain by pointing it at Microsoft 365.

Check what clients actually resolve, both from your internal DNS and from a public resolver:

Resolve-DnsName -Name autodiscover.contoso.com -Type CNAME
Resolve-DnsName -Name autodiscover.contoso.com -Type CNAME -Server 1.1.1.1
Resolve-DnsName -Name _autodiscover._tcp.contoso.com -Type SRV

Look for these problems:

• No record or an A record pointing to an old server or a web host.
• Split-brain DNS: the internal zone for contoso.com still has an old autodiscover record that the public zone no longer has.
• An SRV record left over from a previous hosting provider; it is only used late (step 10) but can still send Outlook to the wrong host.

You can also let Microsoft 365 check the zone: in the Microsoft 365 admin center go to Settings > Domains, select the domain, then DNS records to see the records Microsoft 365 expects for it, or use Troubleshoot on the domain where it is offered.

DNS changes during a cutover are covered step by step in the Google Workspace to Microsoft 365 migration guide, which includes the Autodiscover CNAME in its cutover record set.

Step 2: Run the Remote Connectivity Analyzer

The Remote Connectivity Analyzer runs the Autodiscover process from outside your network and shows each attempt.

1. Open the Outlook Autodiscover test on the Microsoft 365 tab of https://testconnectivity.microsoft.com.
2. Enter the email address and credentials of a test account, complete the verification and select Perform Test.
3. Select Expand All and read the attempts in order.

If the test succeeds, server-side Autodiscover works and the problem is on the client (step 3). If it fails, the details show which URL failed and why.

For the "profile is created as IMAP" problem, search the expanded results for IMAP. If <Type>IMAP</Type> is present and you didn't set the mailbox up for IMAP, a third-party web server is answering Autodiscover for your root domain. You will often see a reference to Apache, UNIX or Linux near the end of the results. When you test for this specific issue, the address and password don't have to be real; only the SMTP domain must be valid, because no authentication against Microsoft 365 takes place.

Another message you may see is "Autodiscover cannot process the given e-mail address. Only mailboxes and contacts are allowed." Microsoft lists the same causes for it as for the Outlook error "An encrypted connection to your mail services is not available": a wrong email address, an Outlook version without the required updates, a missing or wrong Autodiscover CNAME, or directory attributes that aren't set correctly for a synchronized user (see step 4).

Step 3: See what the client is doing

On an affected computer, run Outlook's built-in test:

1. Start Outlook.
2. Hold Ctrl, right-click the Outlook icon in the notification area and select Test E-mail AutoConfiguration.
3. Check the email address, enter the password if needed, clear Use Guessmart and Secure Guessmart Authentication, and select Test.
4. Read the Log tab.

The log lists each method in the order Outlook tried it. Compare it with the table above: a method that never appears has probably been excluded; a method that succeeds against an unexpected host is your culprit.

Then open Registry Editor and review both keys:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover

Look for ExcludeHttpsAutoDiscoverDomain, ExcludeHttpsRootDomain, ExcludeScpLookup, ExcludeSrvRecord, ExcludeHttpRedirect, ExcludeLastKnownGoodUrl, ExcludeExplicitO365Endpoint and PreferLocalXML. Microsoft's guidance when you aren't sure a value is still needed is to set it to 0 and test again. A value called ExcludeSrvLookup does nothing; Outlook only reads ExcludeSrvRecord.

Step 4: Apply the fix for the cause you found

Missing or wrong CNAME

Create or correct the autodiscover CNAME as shown in step 1, wait for the TTL to expire, and test again. For hybrid domains, point it at the on-premises Exchange endpoint.

A web server answers for the root domain

Ask your web host to stop responding to Autodiscover requests on the root domain. If that can't happen quickly, set ExcludeHttpsRootDomain to 1 on affected clients. Microsoft is explicit that this is temporary relief, not a long-term fix, and that the value must be removed once the host is fixed. In the meantime users can work in Outlook on the web.

Outlook still uses the old server after a migration

After a mailbox moves to Exchange Online, Outlook can keep using the pre-migration Autodiscover server cached in the profile. Symptoms include "Outlook cannot log on. Verify you are connected to the network and are using the proper server and mailbox name." and broken Out of Office, free/busy and MailTips. Either set ExcludeLastKnownGoodUrl to 1 (registry or the Disable AutoDiscover policy option Exclude the last known good URL), or create a new Outlook profile from Control Panel > Mail > Show Profiles > Add.

On domain-joined computers, the SCP lookup (step 5) queries Active Directory. If the SCP objects still describe an on-premises Exchange organization that no longer hosts the mailbox, Outlook may receive settings for the old organization. ExcludeScpLookup set to 1 skips that step; also review the on-premises Exchange configuration that publishes those SCP objects.

Group Policy blocks every method

If the Disable AutoDiscover policy excludes all local methods and Allow the use of connected experiences in Office is also disabled, Outlook has no Autodiscover method left. Users see "Something went wrong and Outlook couldn't set up your account. Please try again. If the problem continues, contact your email administrator." or "We're sorry, we couldn't set up your account automatically.", and File > Office Account > Connected Services may show "Office is currently offline." Fix it either by enabling Administrative Templates > Microsoft Office 2016 > Privacy > Trust Center > Allow the use of connected experiences in Office, or by making sure Administrative Templates > Microsoft Outlook 2016 > Account Settings > Exchange > Disable AutoDiscover no longer disables the local methods.

Hybrid user attributes are incomplete

In an Exchange hybrid deployment, run Get-RemoteMailbox on-premises for the affected user and check that primarySMTPAddress, alias, displayName, emailAddresses and remoteRoutingAddress (for example ted@contoso.mail.onmicrosoft.com) are set. Correct them with Set-RemoteMailbox, force a directory synchronization, then set up the profile again. In synchronized organizations the mail, mailNickname, displayName and proxyAddresses attributes must also be correct.

Outlook is too old

Microsoft's guidance for Outlook 2010 and earlier is to upgrade to the latest version of Outlook before troubleshooting further, and to make sure the updates Outlook needs to connect to Exchange Online automatically are installed.

Verify the fix

• Resolve-DnsName returns autodiscover.outlook.com (or your on-premises endpoint for hybrid) from both internal and public DNS.
• The Remote Connectivity Analyzer Outlook Autodiscover test succeeds and its results don't contain <Type>IMAP</Type>.
• Test E-mail AutoConfiguration on a client shows a successful result from the expected method.
• A new Outlook profile is created as an Exchange account, and free/busy, shared mailboxes and Out of Office work.

Troubleshooting quick reference

Microsoft doesn't support creating an Outlook profile for an Exchange Online mailbox manually, so don't try to bypass Autodiscover; fix the lookup instead.

Summary checklist

• Cloud-only domain: autodiscover CNAME to autodiscover.outlook.com, TTL 3600.
• Hybrid domain: public Autodiscover points to on-premises Exchange.
• Internal DNS matches public DNS for autodiscover.
• The root domain web server doesn't answer /autodiscover/autodiscover.xml.
• No leftover Exclude* or PreferLocalXML values on clients unless you know why they are there.
• Group Policy leaves at least one Autodiscover path available.
• Test with the Remote Connectivity Analyzer and Test E-mail AutoConfiguration after every change.

References

• Outlook 2016 implementation of Autodiscover
• Outlook can't set up a new profile by using Exchange Autodiscover for an Exchange Online mailbox
• Issues when using Autodiscover service
• Outlook can't set up a Microsoft 365 account
• Outlook cannot connect or web services cannot work after migrated to Microsoft 365
• Unexpected Autodiscover behavior if settings under the \Autodiscover key
• How to control AutoDiscover via Group Policy
• External Domain Name System records for Microsoft 365
• Connect your domain by adding DNS records
• Hybrid deployment prerequisites
• Resolve-DnsName
• Microsoft Remote Connectivity Analyzer