Azure Custom Domain Not Working? DNS, CNAME, TXT Records and HTTPS on App Service

October 14, 2026 · Azure Networking, Packet by Packet: NSGs, Route Tables, ASGs and Azure Firewall (part 7)

▶ Watch on YouTube & subscribe to The Stack Underflow

Your app works at its azurewebsites.net address. You type www.contoso.com, and nothing. Or it loads with a certificate warning. Getting a custom domain onto Azure takes four jobs: point the name, verify you own it, secure it with HTTPS, and know how to debug it. This page does each one in order, with the record names exactly as you type them and the documentation behind each rule.

The one-line version: a CNAME for www, an A record or an alias for the root; the asuid TXT note for App Service, the _dnsauth note for Front Door; a managed certificate with the CNAME pointing straight at the service. When it breaks: resolution, ownership, Azure binding, TLS, in that order.

Already broken? Jump to the debug ladder.

Last verified against Microsoft Learn: 12 October 2026. Names like contoso.com and contoso-web are generic teaching names.

What DNS has to do

The browser has a name. It needs an address to connect to. DNS is the lookup in between.

• The resolver. The browser never searches the internet itself. It asks a resolver, usually your internet provider’s or a public one like 1.1.1.1. If the resolver looked the name up recently, it answers from its cache.
• The chain. If it doesn’t remember, the resolver works down the tree: the root servers say who runs .com, the .com servers say who runs contoso.com. Neither knows your app’s address; each one points to the next server down.
• Your zone. The answers live in a zone, here an Azure DNS zone for contoso.com. Azure DNS public zones are authoritative: they answer for your zone. Azure DNS isn’t a registrar and doesn’t sell domains. At your registrar, replace the name servers with the four Azure gives you (ns1-XX.azure-dns.com, ns2-XX.azure-dns.net, ns3-XX.azure-dns.org, ns4-XX.azure-dns.info). Use all four. That’s delegation: the NS records say who keeps your zone.
• TTL. Every answer comes with a time to live: how many seconds a resolver may reuse it before asking again. When a DNS change seems slow to arrive, the TTL is usually why.

Point it: the CNAME for www

Can www.contoso.com be a CNAME, a record that says “look up this other name instead”? Yes. For App Service, www gets a CNAME to the app’s own Azure hostname. The resolver follows it, finds the app’s address, and the browser connects. The CNAME never holds an address itself, so if Azure moves the app, the name still works.

Copy the target from the app’s Overview page in the portal. Don’t type it, and don’t guess it. New apps can get a secure unique default hostname, <AppName>-<Hash>.<Region>.azurewebsites.net: the app’s name plus a hash and a region. Microsoft does that on purpose, so nobody outside your organization can create a resource with the same hostname.

Verify it: the TXT record

Pointing the name isn’t enough: Azure also wants proof the domain is yours. When you add a custom domain, App Service gives you a domain verification ID. Create a TXT record named asuid.www with that ID as its value. App Service reads it to verify you own the domain.

Microsoft calls this record “highly recommended”, and it does a second job: while an asuid TXT record exists, no other Azure subscription can validate your custom domain or take it over. Keep it for as long as you use the domain. With the CNAME and the TXT record in place, add the custom domain in the portal, and App Service creates the binding.

The trap at the root

Can contoso.com itself, with no www, be a CNAME? No. The DNS rules say a name with a CNAME can’t hold any other records, and the root (apex) of every zone must hold the zone’s NS and SOA (start-of-authority) records. Azure DNS won’t let you create a CNAME at the apex.

So for App Service, the root uses an A record: contoso.com points straight to the app’s IP address, which the portal shows you, and the ownership note is a TXT record named just asuid. An A record holds a real address, so if that address changes, you have to update it. Azure DNS has a smarter record for the root, the alias record, but an alias can’t target an App Service app: its targets are a Standard public IP, Traffic Manager, Azure CDN, Front Door, or another record set in the zone. You’ll meet it with Front Door below.

Secure it: HTTPS

DNS working isn’t HTTPS working. The browser needs a certificate for www.contoso.com, bound to the app. App Service can create one for free: a managed certificate. App Service renews it automatically, as long as the prerequisites you set up stay the same. It doesn’t support wildcard certificates. Two prerequisites: the App Service plan must be Basic or higher (Free and Shared can’t use it), and if your domain has a CAA record, it must allow the issuer, DigiCert (0 issue digicert.com).

The rule that catches people: for a subdomain, the CNAME must map directly to the app’s own azurewebsites.net default hostname, the one you copied from Overview, with the hash if it has one (or to trafficmanager.net). In Microsoft’s words, “mapping to an intermediate CNAME value blocks certificate issuance and renewal.” Everything resolves, the site even loads, but the certificate never arrives. If yours is stuck, check that the CNAME points straight at the app.

Production: Front Door in front

Many teams put Azure Front Door Standard or Premium in front: a global edge, a web application firewall, caching, and TLS at the edge. Front Door (classic) retires on 31 March 2027 and no longer accepts new profiles, so new designs use Standard or Premium.

• A reverse proxy. The browser’s TCP connection ends at a Front Door edge location close to the user; Front Door opens a separate connection to your app, now its origin. Two connections, not one. Every endpoint gets a hostname ending in azurefd.net.
• Its own ownership check. Add the custom domain in Front Door and it gives you a token. Create a TXT record named _dnsauth.www with that value. The token expires after seven days, so add it promptly. Once the domain is validated, Microsoft says you can safely delete this record. It’s a different note from App Service’s asuid.
• Move www. The www CNAME now points to the Front Door endpoint. Point it there directly: Front Door rotates its managed certificate automatically only when the CNAME points directly at a Front Door endpoint. Otherwise the domain drops into Pending revalidation before the certificate expires (45 days before) and needs a fresh TXT token. From now on browsers see Front Door’s certificate, and the app’s own managed certificate for www may stop renewing, because its HTTP validation no longer reaches the app.
• The root, again. It still can’t be a CNAME. An Azure DNS alias record answers as an ordinary A record, but Azure DNS keeps it pointed at an Azure resource, such as a Front Door endpoint. One catch: a root domain has no CNAME to Front Door, so its managed certificate can’t rotate on its own. At each renewal it waits in Pending revalidation until you add a fresh _dnsauth token.

Failure one: “propagation”

You change a record, and some users still reach the old address. New or updated records appear on Azure DNS name servers within 60 seconds. But a resolver that cached the old answer keeps using it until its TTL runs out. What people call propagation is mostly caching. Before a planned move, lower the TTL first, then wait at least the old TTL before making the change, because answers cached earlier can live that long. Raise it again afterwards (RFC 1034 §3.6).

Failure two: the deleted app

You delete the web app, and the CNAME stays. Safe? No: a risk. Deleting the app doesn’t delete the DNS record. Your www now points to a name you no longer own: a dangling record. For apps without the unique hostname, someone else could create that name in their own subscription and serve their content on your domain: a subdomain takeover. Delete the DNS record together with the resource, and while you still own the domain, keep the asuid record.

The debug ladder

Climb from the bottom. Don’t step up until the rung below passes.

1. Resolution. Does the name return the CNAME or address you intended? If not, it’s a DNS problem.

   nslookup www.contoso.com
   nslookup www.contoso.com ns1-XX.azure-dns.com   # ask Azure DNS directly, skipping your resolver's cache

   If Azure’s name server has the new answer and your resolver doesn’t, wait out the TTL.
2. Ownership. Is the TXT note there, with the right value? For Front Door, check _dnsauth.www only while the domain is pending validation or revalidation; after that, it may rightly be gone.

   nslookup -type=TXT asuid.www.contoso.com
   nslookup -type=TXT asuid.contoso.com          # the root, App Service
   nslookup -type=TXT _dnsauth.www.contoso.com   # Front Door, while pending

3. Azure binding. Does App Service, or Front Door, show the custom domain as validated and associated? A correct DNS answer doesn’t prove Azure knows the name.
4. TLS. Is a certificate issued and bound for that hostname?

Only when all four pass, and the request reaches the app, look at routing, access rules and the app itself. DNS finds the address. Routing gets you there.

Pause & Prove: the questions from the video

1. Can www.contoso.com be a CNAME?

Yes. A subdomain can forward to another name. For App Service, www is a CNAME to the app’s default hostname, copied from the Overview page, plus a TXT record asuid.www.

2. Can contoso.com, the root, be a normal CNAME?

No. A name with a CNAME can’t hold other records, and the root must hold the zone’s NS and SOA records. For App Service, use an A record to the app’s IP plus TXT asuid. With Front Door, an Azure DNS alias record can point the root at the endpoint.

3. You delete the web app and the CNAME stays. Safe, or a takeover risk?

A takeover risk. The record is now dangling: it points at a name you no longer own, which someone else may be able to claim. Delete the record with the resource, and keep asuid while you own the domain.

Before / after this video

• Start of the playlist, inside Azure: Azure CIDR & Subnets (addresses, subnets, routes, and the private side of DNS)
• Where a packet goes once the name resolves: How Azure NSGs Allow or Deny a Packet, Azure Route Tables and NVAs, Azure Subnet NSG vs NIC NSG and How Azure Firewall Decides
• DNS across the hybrid boundary: Why Your Azure VM Can’t Reach On-Premises: VPN vs ExpressRoute

Sources

Read on 11 and 12 October 2026; certificate prerequisites, Front Door and TTL re-checked 16 October 2026:

• Set up an existing custom domain name for your app (App Service): CNAME for a subdomain, A record + TXT asuid for the root, asuid.<subdomain>, the TXT record “highly recommended”
• Prevent subdomain takeovers (App Service): secure unique default hostnames with a hash and a region
• Prevent dangling DNS entries and avoid subdomain takeover: dangling records, “no other Azure subscription can validate the custom domain or take it over”
• Install a TLS/SSL certificate for your app (App Service): free managed certificate, Basic tier or higher, CAA 0 issue digicert.com, no wildcards, renewal while prerequisites stay the same, the direct-CNAME rule
• App Service Managed Certificate (ASMC) changes: HTTP token validation to the hostname
• Azure DNS delegation overview, Host your domain in Azure DNS and What is Azure Public DNS?: authoritative zones, not a registrar, use all four name servers
• DNS zones and records overview: TTL, no CNAME at the zone apex, NS and SOA at the apex
• Alias records overview: supported targets, alias at the zone apex
• Azure DNS FAQ: changes on Azure DNS name servers within 60 seconds, resolver caching by TTL
• Azure Front Door (classic) retirement FAQ: retires 31 March 2027, no new profiles
• Traffic acceleration (Front Door): split TCP, a separate connection to the origin
• Add a custom domain (Front Door) and Domains (Front Door): _dnsauth validation, the seven-day token, deleting the TXT record after validation, rotation only with a direct CNAME, Pending revalidation
• Apex domains in Azure Front Door: alias at the root, no autorotation, a new token at renewal
• IETF: RFC 1034 (DNS concepts, resolvers, CNAME; §3.6 TTL: reduce it before an anticipated change) and RFC 2181 (clarifications, CNAME)

Change notes

• 16 Oct 2026: first published.

Not affiliated with or endorsed by Microsoft. Azure is a trademark of Microsoft Corporation. Azure changes, so check the current pages. Found a mistake? Tell us in the video’s comments and we’ll correct this page.