Azure Static Web Apps custom domain with GoDaddy DNS

Attaching www.example.com to an Azure Static Web App is a five-minute job. Attaching example.com — the bare domain, no subdomain — is where people lose an afternoon, and the reason has nothing to do with Azure.

Why the bare domain is the hard part

DNS does not allow a CNAME record at the zone apex. That is a rule in the protocol, not a limitation of any particular provider: the apex already holds SOA and NS records, and a CNAME cannot coexist with other records at the same name.

Azure Static Web Apps has no fixed IP you are meant to depend on — it sits behind a globally distributed front end. So the natural way to point a name at it is a CNAME, which is exactly what you cannot use at the apex.

Providers solved this with non-standard record types — ALIAS, ANAME, or CNAME flattening — that behave like a CNAME but resolve to addresses at query time. GoDaddy does not offer one. Neither did Google Domains before Squarespace absorbed it. If your DNS is there, that door is closed.

The three options

Use www and forward the apex. A CNAME for www pointing at your *.azurestaticapps.net hostname, and a domain forward from the bare name to https://www.example.com as a permanent 301. You keep the global distribution, the certificate is automatic, and there is nothing exotic in the zone. The cost is that www is the real address.

Point the apex at an IP. Azure exposes a stableInboundIP on the Static Web App resource, and you can put an A record on it plus a TXT record for ownership validation. This works, and Microsoft documents it — but read their warning: traffic then routes to a single regional host, so you lose the global distribution that made the platform fast. For a site serving one country that may be an acceptable trade. Know that you are making it.

Move DNS to a provider with flattening. Cloudflare’s free tier does CNAME flattening, so the bare domain works properly with full CDN behaviour. This is the best technical outcome. It is also the riskiest change, because you re-create every record — and if the domain carries email, getting an MX or SPF record wrong takes down mail rather than a website. On a domain with no mail on it, the risk is close to zero.

There is no universally right answer. On a domain with live Microsoft 365 email I would take the www option every time; on a fresh domain with nothing but a website, Cloudflare.

The order matters

This is the part that wastes the most time. Azure validates the CNAME at the moment you register the hostname, not afterwards. Register first and you get:

(BadRequest) CNAME Record is invalid.
Please ensure the CNAME record has been created.

So: DNS first, Azure second.

# only after the CNAME resolves
Resolve-DnsName www.example.com -Type CNAME -Server 1.1.1.1

az staticwebapp hostname set `
  --name <your-swa> `
  --resource-group <your-rg> `
  --hostname www.example.com

The registration walks through RetrievingValidationToken → Validating → Adding → Ready, which takes a few minutes. The certificate is issued and renewed by Azure automatically once it reaches Ready. Nothing to buy, nothing to diary.

The failure mode nobody warns you about

Here is one worth knowing, because it looks like a DNS problem and is not.

The certificate is bound to the hostname registration on the Static Web App, not to DNS. If that registration is removed — someone tidying resources, an app recreated through a path that rebuilds it — your DNS keeps pointing at a perfectly healthy site that no longer has a certificate for that name. Azure falls back to serving its internal platform certificate, something along the lines of *.msha-slice-…-ase.p.azurewebsites.net, and every visitor gets a browser security warning.

The CNAME is fine. The site is up. The name is just no longer registered on it.

Diagnose it by looking at the certificate actually being served rather than at DNS:

$h = 'www.example.com'
$tcp = [System.Net.Sockets.TcpClient]::new($h, 443)
$ssl = [System.Net.Security.SslStream]::new($tcp.GetStream(), $false, {$true})
$ssl.AuthenticateAsClient($h)
([System.Security.Cryptography.X509Certificates.X509Certificate2]$ssl.RemoteCertificate).Subject

If the subject is an Azure infrastructure wildcard rather than your hostname, the registration is missing. Confirm with az staticwebapp hostname list and re-add it. Since the CNAME already exists, validation passes immediately.

Two things to change afterwards

Once the domain is live, update the framework’s site URL and your robots.txt sitemap line to the real domain. Canonical tags and sitemap entries are generated from that value, and if it still points at the old *.azurestaticapps.net host — or at a domain that does not resolve yet — you are telling search engines the authoritative version of every page lives somewhere else.

And set up the apex redirect properly: 301, not 302, and forwarding rather than masking. Masking serves your site inside a frame at the old address, which breaks bookmarking, hides the real URL, and gives search engines two addresses serving identical content.

---

Ingot Solutions builds custom software and Azure architecture for Microsoft-first organizations. Get in touch if you would rather someone else spent the afternoon on this.