Office 365 Exchange Hybrid Deployments Busting The Autodiscover Myth

When configuring an Exchange Online hybrid deployment, there are many things to consider.  Asides from the various networking, certificate and client discussions there is also a requirement to ensure that Autodiscover is functioning correctly.  In addition to having Autodiscover correctly published to the Internet an additional wrinkle commonly pops up, which takes people down the wrong garden path...  This is the helpful DNS page in the Office 365 admin center.

Before we move on, be clear that we are discussing Exchange hybrid and in this deployment model Autodiscover must point to the on-premises Exchange infrastructure.

Taking The Wrong Path

When opening  up the admin center, the below sight will greet many – note that there is a reported “issue” with the custom domain which was previously added (

Office 365 Admin Center - DNS Possible Service Issues

Clicking the “Fix Issues” link will show something like the below.  We are interested in the highlighted Autodiscover line for the purposes of this discussion:

Office 365 Admin Center - Add The Following DNS Entries

 The Office 365 admin center is deeply unhappy since the Autodiscover namespace is NOT pointing to Office 365.  If this were a simple cloud only deployment, then the UI is correct.  However the UI is not checking to see if Exchange Hybrid is/was deployed, and this is where the wrinkle comes in.  I have seen multiple deployment consultants blindly repoint Autodiscover to Office 365 just because the portal indicated so.


Taking The Correct Path

We must add and verify all of the required domains to use them with Office 365.  Not adding a domain is not really a fix as it cannot then be used.  What was added to help with this issue is actually on the previous screenshot, but is often skipped.  The relevant area on the upper right hand side of the screen is highlighted below:

Office 365 Admin Center - Ignore These False Prophets

If we check the box to disable the DNS record checks, the page is updated to:

Office 365 Admin Center - DNS Check Disabled


Clicking close will return us to the previous page.  Note the difference compared to the very first image that we looked at. In the one below, note that there are no issues reported, but it does state that the DNS check is turned off.  By doing this, the visual temptation to reconfigure Autodiscover is removed.

Office 365 Admin Center - DNS Check Disabled

If there is a requirement to see what DNS records are required, for example to update the SPF or MX, the DNS check can be temporarily re-enabled the records reviewed and then disabled once again.



The Autodiscover lookup process for an Office 365 Outlook client is discussed in detail in this previous post.

Additionally there seems to be a desire to disable the SCP lookup for users when the mailbox is moved to Office 365.  We need to ensure that the Autodiscover redirect process is applied so that the correct address is then used for the chase down.  I can certainly see why people want to exclude the root domain lookup (, and that is something which I commonly do.  This reviewed in Outlook Prompts For Domain Certificate Unexpectedly.

A lot of the online documentation is written for the cloud only customer, and the hybrid deployment is not the intended target for those pieces of documentaiton – example and example.  This page does mention that the Autodiscover CNAME should not be created in the Exchange hybrid scenario, though the warning is not highlighted and is at the end of the section.

Do Not Add Office 365 CNAME DNS For Hybrid Deployments




Comments (8)
  1. David says:

    Can you confirm as well as doing these Externally. Should the same records be done Internally for O365 mailboxes even on a hybrid configuration. And also should the SCP Internal Autodiscover be set to NULL

  2. Dkpileitor says:

    Hi Rodherik,

    I have the url of the internal virtual directories with the default name of the server. In a hybrid scenario … does it need to change the address of internal virtual directories?

    1. This does touch upon some older issues with Exchange that go all the way back to 2007, but I’ll try and keep this brief.

      If you have Outlook Anywhere enabled, Exchange should be presenting the correct external VDir information to the external requestor.

      When I last looked at this many years ago, the internal directories were handed out if OA was not enabled. But that was many moons ago…..

      Is it working as expected? Do you have OA enabled? What version of Exchange is on-premises ?


      1. Dkpileitor says:

        Dear Rhoderik,
        Thanks for answering.
        Outlook anywhere is enabled…Exchange 2010 SP3 RU 16.

  3. Xorax says:

    Can you explain us why from some days ago autodiscover.json is called instead of autodiscover.xml ? No notices anywhere. It break a lot oif things.

  4. Mike Crowley says:

    Is there any documentation that suggests the best time to update the autodiscover record from on-premises to O365 (e.g. after the migration is 100% complete?). I usually move the record after the last mailboxes / public folders are done, but it’d be nice to reference something official. We need to keep an Exchange server long-term for recipient management, but there often isn’t a need to keep services like autodiscover healthy (especially if removing the SCP)

    1. Steven Provo says:

      Certainly now the newer build of Outlook 2016 are skipping some parts of the Autodiscover process and go directly to O365…

Comments are closed.

Skip to main content