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.

Comments (26)

  1. Anubhav says:

    Thanks for explaining so well. Helped a lot!

  2. Prabu says:

    Helped me a lot. You may want to add that any "forwarding" rules that may already exist in godaddy needs to be removed first before adding CNAME entries.

    In my case I already had "domain forwarding" enabled to my address which was an issue. I had to first remove all forwarding rules, wait for an hour, then "quick add" CNAME records in the DNS settings page in godaddy after which things strated working well.

  3. Bernard says:

    Useful post, thanks. However, I have set my domain up exactly the same at your post shows Kaushal (my DNS is also with GoDaddy) and the Azure custom domain still won't accept it. It has been several hours and NSLookup (with server as reflects the change accurately, so I don't understand why Azure is unable to see it. Any idea what I could be missing?

  4. Bernard says:

    Never mind, sorted now – just needed to have a bit more patience with the CNAME update propagation!

  5. Christian says:

    Thanks so much for this post! I was wondering how to resolve this issue and your article helped greatly!

  6. Ashfaq says:

    Thanks so much, very helpful

  7. Peterson says:

    That was so helpful. All of my azure websites were configured incorrectly and thanks to you article I could rectify all of them…

  8. David Douglas says:

    Very helpful – especially the handling the root domain part.

  9. Tawhid Khan says:

    Is giving 404, but is working (you may have some PHP errors)

    Same is happening on my site with www as prefix – any idea?

  10. I have removed my mapping for So I expect the 404 error.

    Regarding your site I'm not sure. Could you share your domain name?

  11. wizkid says:

    Great tutorial. i was having trouble because I had not mapped www as well.

  12. ChrisG says:

    This is still helpful. I'd love it if this complete example was in the documentation. Adding a CName for awverify.www (as well as awverify) was the missing piece of the puzzle for me…

  13. Suresh says:

    on Manage Domains under the DASHBOARD management page, you also need to add your domain name e.g Heck no where they mentioned this.

  14. Sarvesh says:

    It is very very useful for me .I really say thanx to you.

  15. Jantje says:

    Great article! Just the information I was looking for regarding the 'awverify' bit.

  16. Arvind S. Iyer says:

    Great article and nice screenshots, Kaushal!

  17. Tharkana says:

    This is a nice article….very helpful…thanks a lot. <3

  18. Ankit Singhal says:

    The article helped in setting up the custom domain really quickly. Thanks a lot, Kaushal!

  19. Irfan Hussain says:

    I understand that the Azure websites support TXT records and you mentioned. I would need the TXT value to map on to the custom domain. I can see CNAME value and A record which is the IP address. Any idea how can I find the TXT value?

  20. Raine says:

    The solution covers all the possible questions. I was able to resolve the issue by just following the instructions. Cheers!

  21. Aarthna Maheshwari says:

    Thanks you so much Kaushal. You are a blessing in disguise 🙂

  22. Sanjay says:

    Very helpful! Thanks. I have a question. If I want to redirect a “live” subdomain, how can I do that with minimum interruption? If I set up both CNAME and AWVERIFY records then it shows Azure 404 page till the propagation happens and I bring the custom subdomain to Azure. Can I just set up awverify first and wait for its propagation to just add the custom subdomain to Azure? Or, it always wants the CNAME record too to set it up. If yes, that’s a problem.

    1. Unfortunately, there is only so much you can do control this. The best way to do this is to map the awverify entries so that the domain is mapped ot azure and then update the CNAME or A records to point to the Azure front-ends. Do this during non-business hours to avoid user inconvenience.

  23. Fasil says:

    thanx buddy. helped a lot

  24. marika says:

    Hi i have only on answer. I have configured 1 forest in Acitve Direcory Windows server 2012 on azure cloud virtual machine. If i want to integrate my forest installed on Azure active directory for single-sign on on office 365 and other cloud app it is possible without public domain?

  25. Steve Culshaw says:

    Excellent article.
    Thanks for sharing and especially for updating it.

Skip to main content