Azure App Service: How to configure a custom domain

[Updated on 2nd May 2016]

Azure App Service provides a default hostname on site creation. It is of the format <SITENAME> So when I create a website called Kaushalz then the hostname would be

Now the users can buy a custom domain via Azure portal. See this article:

If you decide to buy a custom domain externally then you would have to configure it. There is one requirement though, the pricing tier of the Web App needs to be in either SHARED or higher tiers. 

There is an article on on how to configure custom domain. Below is the URL:

However, I have still seen few customers running into issues in spite of this. In this post we will discuss adding custom domains to a MAWS site in detail.

There are 2 ways to configure domain names:

  1. Add an A Record.
  2. Add a CNAME.

NOTE: A records map a domain name to one or more IP addresses. They are used when the IP is not bound to change.

Example: points to

On the other hand CNAME (CANONICAL NAME) records map one domain name to another domain name. It is typically used when there are multiple hosted services.

Example: or points to

I have purchased the domain from GoDaddy. Here is also referred to as ROOT/NAKED domain. By design, ROOT domains have to be an A record, so they will point to an IP always.

Anything that is prefixed before this is referred to as sub-domain. Examples are,, *

As per DNS best practices, it is always recommended to point your sub-domains to CNAME records. This is because IP address can change dynamically for certain sites and this is not apt in case of an internet facing website.

STEP 1: Create a Website and scale it to SHARED/BASIC/STANDARD

Once the web app has been scaled to SHARED or higher tier, we can proceed further.

STEP 2: Configuration on the DNS Service Provider /DNS Server

In the Azure portal, select the web app and under settings browse to Custom Domains and SSL. In the  Custom Domains and SSL blade, click on Bring External Domains. This will launch a new blade as shown below.


It specifies an IP (Front-end VIP) which is to be used while configuring A Records on the DNS server. Additionally it also suggests that before we add custom domains for the site, Azure needs to verify that the user is authorized to use the domain name or not.

  • Add an A record pointing to the IP as seen above.

NOTE: Entering “@” for the host name is the same as entering your domain name, minus the “www“. Entering “www” for the host name is the same as entering your domain name, including the “www“.

To create a wildcard A record, enter an asterisk (“*“) for the host name. The wildcard makes the server respond with the IP address specified instead of an error, if the subdomain queried does not exist within your zone file.

  • Additionally for the ROOT DOMAIN ( you will have to add another CNAME entry. Here you will point to

  • My DNS service provider is GoDaddy, so I need to point www to Below is a snapshot of my DNS Manager. I have a CNAME entry pointing to the <sitename>

NOTE: Above step is only for verification purpose. Once the ROOT DOMAIN ( has been mapped to the site in Azure Portal, the awverify entry can be removed.

STEP 3: Map the domain name in the Azure Portal

Once the DNS entries have been made the DNS record propagation can take time. This depends on the DNS Provider. Once the records have been propagated, you could proceed with mapping this domain name to the specific website in Azure.

  • In the Azure portal, select the web app and under settings browse to Custom Domains and SSL. In the  Custom Domains and SSL blade, click on Bring External Domains. This will launch a new blade as shown below.
  • Enter the domain name and give it some time to verify. If it succeeds, then you would see something as shown below:


  • If the verification fails then you would get a corresponding warning message:



Verifying DNS Propagation

You can verify the DNS propagation by going to this URL

Specify the hostnames in the textbox and click on Dig. Verify the results to confirm if the recent changes have taken effect.

NOTE: The propagation of the DNS entries takes up to 48 hours or sometimes even more than that. In these cases you may have to wait for the propagation to succeed. The user needs to ensure that the awverify entry resolves to the corresponding entry which has been added in the DNS server while performing the look up.

I have observed that the DNS propagation is quicker with GoDaddy. This is my personal experience.



Now consider a scenario where the user wants to migrate his production website, which is on premise, to MICROSOFT AZURE WEB SITE, without affecting any of his existing sites. He would want to map the hostname (verification) to MAWS and then would modify his DNS records. What should he do?

For this he would have to create CNAME records on the DNS service provider as shown below:






We add 2 entries:

  • One for the ROOT DOMAIN (
  • One for the domain containing WWW (

Below is a snapshot on the DNS Provider (GoDaddy):

After adding the above 2 entries you could map the domain name to a site hosted on AZURE.



The Microsoft Azure Web Sites DNS verification logic has 2 steps:

  • First we try to validate using CNAME. That means we look whether the custom domain provided is a CNAME record. If it is, then it is expanded. If the next record in the chain is also a CNAME, it is further expanded. The expansion goes on until we get an A record or something ending with ““. If it is found that the custom domain is eventually pointing to <SITENAME>, it is verified that the <SITENAME> is really the site for which the custom domain is being added and verification is done.
  • If for some reason the validation of the CNAME fails, it proceeds with the alternative validation. That is useful for users when they want to just test their sites, but not really point the record to AZURE, or if it is a naked domain (some DNS registrars don’t support a CNAME for such hostname). The alternative validation puts “awverify” in front of the provided hostname and follows up the similar logic as above. The only difference is that this time the target has to be the awverify.<SITENAME>

TXT records are also supported. It is another alternative, because some DNS registrars don’t support CNAME’s pointing to invalid hostnames (the “awverify” version doesn’t truly exist). So one can also create just a TXT record instead of a CNAME (otherwise it is completely same setup as in validations above).

Thanks to Petr Podhorsky (DEV on MICROSOFT AZURE WEB SITES) for sharing the DNS verification logicwith us.