The Do’s and Don’ts of Autodiscover

Autodiscover is a function in Microsoft Exchange, introduced in 2006, which provides e-mail clients (smartphones, tablets, Microsoft Outlook etc.) a way to find and connect to your Exchange server automatically. The purpose is saving end users from having to know intricate details like your mail server’s public name and so forth when they want to connect their device/e-mail client. If you implement this right, your end users will effortlessly be able to connect to your company mail server without calling support for help.

Hand in hand with the autodiscover feature is enabling a UPN suffix to your users’ domain accounts, and enable logon with a UPN name. This has the look and feel of an e-mail address (, and my advice is to keep the UPN name consistent with the user’s primary e-mail address if you can. How to go about this will be described in an upcoming post.

A prerequisite for Autodiscover to work is that you buy a commercial certificate from a certificate provider. Unless you’re Microsoft – you shouldn’t issue your own. So don’t be a cheapskate and think you will use a Self-Signed certificate instead. Time is money, you (or your support staff) will spend much more time worth on user support trying to make their various clients work with your self-signed certificate than the modest USD 50 (and upwards) a certificate costs nowadays. This article aims to help you choose the right method for autodiscover for your scenario, and the right type of certificate to go hand in hand with that.

Now, onto the different types of Autodiscover:

The short name URL method:

The first option you’re given if you follow the otherwise excellent Certificate Wizard included with Exchange 2010. This method depends on contacting your public domain name directly with no prefix.

What it looks like in public DNS:

Type    Content                                          Target (host)

A             ->    IP

Avoid. Who in their right mind came up with this idea? Of course you want to reserve the root address of your domain for your company website, right? So locking your website to the same address as your e-mail server is a bad idea, even if you for the time being have a Small Business Server that hosts both your public web site and your e-mail. Certificate requirements: Works with the simplest form of certificate; the single name SSL.

When to use: Only if by chance you DO have a Small Business Server that for the time being is hosting both your public website as well as your e-mail AND you plan on keeping it like that forever.

When not to use: When you are smart enough to realize that the above mentioned is a bad idea…



The long name URL method:

This uses the prefix “autodiscover” in front of your public domain name.

What it looks like in public DNS:

Type          Content                                                                Target (host)

CNAME    -> (x)

(It is possible to use an A-record pointing to the IP-address of your server instead of using CNAME-record, but why would you?)

Until 2007 this was the only option to the short name approach. Since this (together with Short Name method) is the oldest form of autodiscover out there, it also offers the broadest client support.

The long name approach requires that your server certificate covers the name in addition to (typically) This can be achieved either by use of a SAN (Subject Alternate Name) -certificate or a wildcard certificate (*). A SAN certificate can cover more than one domain, with different prefixes for each – i.e., and mailsrv1.yourdomain.local (y) whereas the wildcard certificate gives you unlimited prefixes for one domain only (

Because of the nature of certificates, the long name method is good for a setup that doesn’t cover a lot of public mail-enabled domains. A SAN (Subject Alternate Name) certificate typically gives you minimum 4 names to begin with, and can be expanded for an extra fee. But if you run a hosting centre with i.e. 20 customers who have one public domain each, you would need 20 entries for and 20 more entries for This would be cost prohibitive, not to mention the administrative burden of adding and removing domains from your certificate (with re-issuing and re-installation) as customers come and go.

However, if you plan on integration with Office 365 in a Rich Coexistence Scenario, the long-name approach is the required way to configure autodiscover. For the domain that is to be integrated with Office 365, a CNAME record in public DNS with autodiscover pointing to your public mail server’s A-record, and the certificate on the Client Access-server must contain the name

When to use: When your company has a limited number of mail-enabled domains and/or you plan on integrating your Exchange organization with Office 365 in a Rich Coexistence Scenario.

When not to use: When you serve a large number of public domains on your mail server.


The Service Locator redirect method (SRV)

Introduced in June 2007 this method lets you use a Service-Record in DNS to show your clients the way to your mail server.

What it looks like in public DNS:

Type    Content                                                                  Port           Target (host)

SRV    433    ->

(You also have to set values for Priority and Weight, but they can be set to whatever, it will work regardless.)

This is a good method for environments that host many e-mail domains, for example hosting centres. Your e-mail server only needs one public name in its certificate –i.e. and on each of your e-mail domains you will then publish this SRV record pointing them to the server registered on your domain, which in turn has a certificate installed with corresponding name. This way you can make a single-name certificate work with as many domains as you like. Also, as customers (and e-mail domains) come and go there is no need to change the certificate. Just for the sake of spoon-feeding, the public DNS of Customer1 will look like this:

Type    Content                                                                      Port           Target (host)

SRV    433    ->

You see that the target mail server is on a different domain than that of the SRV record.

The drawback with this method is somewhat limited client support. Even though this method was introduced already in 2007, most phones and tablets simply do not support it. No problem with Windows Phone or RT. Microsoft Outlook supports it from 2007 SP1 and later versions. There is nothing wrong, however, to use this method in co-existence with the HTTP redirect method described further down on the page.

Some Domain Name Registrars will not let you configure SRV-records through the control panel, but will limit you to create or edit A, CNAME and MX-records exclusively. While some will offer to configure it for you if you send an e-mail to customer support, others might state that they simply do not offer SRV records, and deny your request. If this is the case, move all the domains you are in charge of to a Registrar that take their job more seriously.

When to use: When you serve a large number of mail-enabled domains on your mail server.

When not to use: If you have an obligation to provide Autodiscover service for iOS or Android powered devices. When you plan on integrating your Exchange organization with Office 365 in a Rich Coexistence Scenario, which requires the long name URL method.


The HTTP redirect method

This method has some similarities with the SRV redirect method. It has the power to direct requests from one domain to a server name on a different domain. Therefore it also has the same benefits – simple and affordable certificate and certificate management for mail servers with many SMTP domains.

The difference is that instead of using an SRV-record to point to the server it is a redirection of the http header. When the client looks for the HTTP redirect record will forward the client to an URL of your choosing. This could be on the same domain or a different one, in my example it is

What it looks like in public DNS:

Type        Content                                                                     Target (host)

A         ->     IP     (z)

Notice that I have used an A-record here. I am fully aware that some Domain Registrars offer a HTTP redirection to be configured directly in the Zone file of the public DNS. Unfortunately, you cannot use this to redirect autodiscover directly to your mail server holding the Client Access Role, as the server (or rather: site) receiving the unencrypted HTTP request on port 80 cannot have an active binding to port 443, as it will then immediately switch over to encrypted mode, and then fail the autodiscover request. Therefore this method requires more labour on the server side of things than any other autodiscover method.

The nature of HTTP redirect is that it provides no support for HTTPS, which any client will try first for autodiscover. Therefore the HTTP autodiscover request is sent after all other methods have failed for your client. In the case of Microsoft Outlook, it even stops and prompts the user if she/he wishes to proceed with an unencrypted autodiscover attempt. It is then left to chance whether your users will choose “yes” or freak out and press “cancel”, depending on their mood of the day, the weather etc.

Despite its drawbacks, this method is supported by a wider range of clients than the SRV redirect method. And as earlier mentioned it is nothing wrong with using the two in coexistence. That way, your users who use Microsoft Outlook on the road will have autodiscover provided by the SRV record (which Outlook will try first), and will not be prompted whether or not to use an unencrypted autodiscover attempt, and you iOS/Android users will have better chance of connecting to your server without bugging you or your support department.

As mentioned, this method takes a bit of configuration on the server side. I promise to come back with a step-by-step guide on how to do this in different scenarios. For now, I will just mention that if you only have one public IP you need to split port 80 traffic and port 443 traffic to separate internal IP-addresses, and configure a site (or server) for each. Now, port 443 must be routed to the Default Web Site of your Exchange Client Access server. Port 80 must be routed either to a new Web Site on the same server, bound to a different internal IP-address, or on a separate server altogether. This site must have no bindings to port 443 whatsoever. Instead you must configure bindings for each autodiscover name on port 80. On that site, create a virtual directory Autodiscover, and configure the HTTP redirect to redirect directly to the autodiscover directory/configuration file on the Client Access Server – i.e. . For the options on the HTTP redirect settings, tick both “Redirect all requestes to exact destination (instead of relative to destination)” and “Only redirect requests to content in this directory (not subdirectories)”. For status code, select: Found (302)

When to use: When you serve a large number of mail-enabled domains on your mail server, and support a wide range of devices.

When not to use: When you have only one public IP-address and splitting unencrypted HTTP traffic from your Default Web Site is out of the question. When you plan on integrating your Exchange organization with Office 365 in a Rich Coexistence Scenario, which requires the long name URL method.

In this article I have chosen not go in depth on the configuration of HTTP redirect, since I feel it will be outside the scope of this article. However, there are some very good in-depth articles around about this, covering many scenarios including Forefront TMG etc. and here is a link to the one I consider the best of them, written by Microsoft MVP Steve Goodman:

Recommended external link:



We have reached the end of this article, which is the first one to go on my blog. I hope it has given you a good overview of the different forms of autodiscover for Exchange, and that you are now confident about which method(s) to use for your scenario. Comments, questions and criticism welcome!


x)    In my example I use the domain prefix mail for simplicity’s sake. This is meant to reflect the public address of your mail server, and could just as well be “remote” – for your SBS 2008 or SBS 2011 server, or “MX1” etc.

y)    From the 1st of November 2015, it will no longer be possible to buy or renew a certificate that publishes the local domain name of your server. Please look at – article coming up – for information on how to work around this issue.

z)    You will of course substitute with the actual public IP of your server.


© 2015 Jon Hilmar Edvardsen. Link, browse and print freely, do not reproduce or redistribute without permission.

Welcome to my Blog!

A quick intro:

I am an IT consultant and administrator on technical infrastructure, and has been working in this field since early 2007.

The mission of this blog is to make technical “how-to” information more accessible to system administrators. Nothing I write here is strictly magical information, or impossible to find elsewhere. But I hope to bring a new level of accessibility to you, the reader, and hopefully organize the information I have mined over the years in a way that will lead not only to the solution to your immediate problem, but also to a better understanding of how things interact.

If I catch your interest, let me hear from you.

Best wishes,

Jon Hilmar aka “Merlin’s Apprentice”