Configure Custom Domains for Apps

You've got your Python app running beautifully on Azure App Service, but the default URL looks like yourapp.azurewebsites.net. For production, that's not how you want customers finding your service. A custom domain—www.yourcompany.com—builds trust, makes your service memorable, and is often a hard requirement for any serious deployment. In this lesson, you'll learn exactly how to configure custom domains for apps hosted on Azure, covering DNS setup, domain verification, and SSL binding, so you can go live with a URL that reflects your brand.

The problem this lesson solves

Every Azure App Service gets a default domain like yourapp.azurewebsites.net. While that's fine for dev, it's not acceptable for production. Customers expect a URL that matches your brand; a long Azure-generated hostname looks unprofessional and undermines trust. Also, some third-party services (like OAuth providers or payment gateways) require a custom domain for redirect URIs and webhooks. The core problem: mapping your own domain to an Azure-hosted app requires coordinated steps between your DNS registrar, your Azure resource, and the SSL certificate provider. Getting one of those wrong leads to 404s, SSL warnings, or domains that never validate.

This lesson solves that by giving you a crystal-clear path: from adding the domain in Azure, to updating DNS at your registrar, to validation, and finally binding an SSL/TLS certificate for HTTPS. By the end, your app will respond on your custom domain with a green padlock in the browser.

Core concept / mental model

Think of DNS as the phonebook of the internet. When someone types www.yourcompany.com, their browser asks DNS, "Where do I find this site?" and DNS answers with an IP address or a hostname. To point your custom domain at your Azure app, you create a DNS record that says, "This domain points to yourapp.azurewebsites.net." Azure then needs to verify you own the domain before it starts serving traffic, and finally, you bind an SSL certificate so traffic is encrypted.

There are two main DNS record types for this:

• CNAME – maps a subdomain (www.yourdomain.com) to another hostname (yourapp.azurewebsites.net). Used for www and other subdomains.
• A record – maps a domain (like yourdomain.com or www.yourdomain.com) to a static IP address. Azure gives you a static IP (often called the Public IP Address or Inbound IP Address) that you can point the A record at.

Pro tip: For the naked/apex domain (e.g., yourdomain.com), you often need an A record because some DNS providers don't support CNAME on the root. Azure provides a special IP address and a verification ID for this purpose.

Azure validates your domain ownership by checking for a specific TXT record or by having a CNAME/A record that points to a domain verification ID. Once validated, you bind the domain to your app service, and optionally attach an SSL certificate.

How it works step by step

Here's the logical sequence you'll follow:

1. Add the custom domain in Azure – In your App Service, go to Custom domains blade and click Add custom domain. Enter your domain name.
2. Get the verification token – Azure shows you a Domain verification ID (a long hex string) and the IP address you'll need for the DNS record.
3. Create DNS records at your registrar – Go to your DNS provider (GoDaddy, Cloudflare, etc.) and add the records: - For www.yourdomain.com: add a CNAME www -> yourapp.azurewebsites.net with the TXT record asuid.www -> verification ID. - For yourdomain.com (apex): add an A record @ -> your Azure IP address, plus a TXT record asuid -> verification ID.
4. Wait for DNS propagation – DNS changes can take from minutes to hours. Azure will keep checking.
5. Validate the domain – Once DNS is live, Azure validates the TXT record. Click Validate in the Azure portal.
6. Bind the domain – After validation, click Add to bind the domain to your app.
7. Add SSL/TLS binding – Upload or create a certificate (App Service Managed Certificate is free) and bind it to your domain.

Hands-on walkthrough

Prerequisite: An existing App Service

If you don't have an app yet, create one:

az appservice plan create --name myplan --resource-group myrg --sku B1 --is-linux
az webapp create --name mypythonapp --resource-group myrg --plan myplan --runtime "PYTHON:3.11"

Step 1: Add the custom domain via Azure CLI (or portal)

az webapp config hostname add --resource-group myrg --webapp-name mypythonapp --hostname www.yourdomain.com

If you get an error, you need the verification ID first. It's simpler to do it in the portal: Your App Service -> Custom domains -> Add custom domain. Enter www.yourdomain.com and note the Domain verification ID (e.g., ABCDE123...) and the Inbound IP address (e.g., 20.30.40.50).

Step 2: Create DNS records

At your registrar, create these records:

To test DNS propagation, use nslookup or dig:

nslookup www.yourdomain.com

You should see it resolving to your Azure app's default hostname (or the IP address).

Step 3: Validate and bind

In the Azure portal, click Validate. If everything is correct, you'll see a green checkmark. Click Add. After a few seconds, your domain is bound.

Step 4: Enforce HTTPS (optional but recommended)

Enable the HTTPS Only setting on your App Service:

az webapp update --resource-group myrg --name mypythonapp --https-only true

Step 5: Add an SSL/TLS certificate

If you have a third-party certificate, upload it. Otherwise, create a free App Service Managed Certificate:

1. In the portal, go to TLS/SSL settings -> Private Key Certificates -> Create App Service Managed Certificate.
2. Pick your custom domain.
3. After it's issued, go to TLS/SSL bindings and add a binding for the domain, setting the TLS/SSL type to SNI.

Now visit https://www.yourdomain.com — you should see your app with a padlock icon.

Compare options / when to choose what

• Choose CNAME if you're mapping a subdomain like www — it's simpler and works even if the IP changes.
• Choose A record if you're mapping the apex domain (yourdomain.com) — some registrars don't support root CNAME records.
• If you have multiple regions or want CDN, use Azure Front Door and map a CNAME to its endpoint.

Pro tip: For most users, www.yourdomain.com is sufficient. You can set up a redirect from the apex to www using a URL redirect in Azure or a web.config/routes.py rewrite.

Troubleshooting & edge cases

Domain validation fails – Common causes: - Missing TXT record: Ensure you added the exact TXT record with the asuid prefix. Double-check the value, it's case-sensitive. - DNS not propagated: Use nslookup -type=TXT www.yourdomain.com to see if the TXT record is visible. Wait up to 48 hours. - Wrong record type: Make sure you're using CNAME for subdomain, A for apex.

404 Not Found after binding – The app service isn't configured to handle the new hostname. Check that the domain is listed in Custom domains in the portal. Also, ensure your app's routing (e.g., Django/Flask) accepts the new Host header.

SSL certificate not working – - The cert must match the domain. App Service Managed Certificates auto-renew, but they may take a few minutes to become active. - If using a self-signed cert, browsers will warn. Use a public CA. - Ensure the TLS binding is enabled for the domain (SNI or IP-based).

Apex domain points to IP but shows Azure default page – If you're using an A record, make sure the IP is the one Azure provided (the Inbound IP address) and that the app's https-only setting isn't blocking it.

What you learned & what's next

In this lesson, you learned how to map a custom domain to your Azure App Service. You can now: - Explain the need for custom domains in production. - Add a custom domain to an App Service and get the verification token. - Create CNAME and A records with TXT verification at a DNS provider. - Validate and bind the domain to your app. - Configure HTTPS with a free App Service Managed Certificate.

This is the final step before your app goes live. Next in the Azure Tutorial, you'll dive into monitoring your app with Application Insights—so you can see traffic, errors, and performance in real-time. Knowing your app is accessible via a clean domain is great, but knowing how it behaves is even better.

Pro tip: Always test in a staging slot before applying DNS changes to production. You can bind the custom domain to a staging slot first, verify, then swap.