Azure Static Web App custom domain kcvue.mmoser.com stuck.

Hi @70797005

Greetings for the day, Thanks for reaching out to Q&A.

Your CNAME is configured correctly - kcvue.mmoser.com resolving to ambitious-tree-08d7b6e00.2.azurestaticapps.net is exactly what it should be. Nothing you've described points at a mistake on your side, so let's get you past the blocked Generate code button first, then work out why the portal is throwing that error.

FIRST - get the TXT token without the portal

The Generate code button isn't the only route to the validation token. The API exposes it directly:

az staticwebapp hostname show --name <STATIC_WEB_APP_NAME> --resource-group <RESOURCE_GROUP> --hostname kcvue.mmoser.com --query "validationToken"

To verify: if a token comes back, add it to DNS straight away and skip the broken button entirely. Create the TXT record as _dnsauth.kcvue.mmoser.com with that token as the value, TTL 300.

If it returns null or empty, the token hasn't been generated yet - request it explicitly:

az staticwebapp hostname set --name <STATIC_WEB_APP_NAME> --resource-group <RESOURCE_GROUP> --hostname kcvue.mmoser.com --validation-method dns-txt-token --no-wait

Use --no-wait as shown, otherwise the command sits waiting for validation to complete and looks hung. Then re-run the show command above to read the token.

Then confirm the record is live before expecting validation to pass: nslookup -q=txt _dnsauth.kcvue.mmoser.com SECOND - find out what the portal error actually is

"domainName is invalid. The domain name given was not found." is a generic portal message sitting over at least two different backend faults with different owners. The CLI returns the real error body that the portal hides. Re-run with --debug and read the ExtendedCode, not the message text:

az staticwebapp hostname set --name <STATIC_WEB_APP_NAME> --resource-group <RESOURCE_GROUP> --hostname kcvue.mmoser.com --validation-method dns-txt-token --debug

ExtendedCode 51021, alongside "Please ensure the custom domain is not linked to another site", means kcvue.mmoser.com is still registered against another Azure resource - another Static Web App, an App Service, or a Front Door profile. Worth knowing: that registration survives deletion of the owning resource, so a long-deleted app can still be holding the name.

ExtendedCode 51017, alongside "Certificate creation failed unexpectedly", means the fault is inside the platform's certificate pipeline and there's nothing further to configure on your side.

If you get a third code, or no ExtendedCode at all, post what you did get - that's still useful and tells us we're looking at something else

nslookup -q=CAA kcvue.mmoser.com

nslookup -q=CAA mmoser.com

Static Web Apps obtains its managed certificates from DigiCert. If a CAA record exists on either name and doesn't permit digicert.com, issuance can fail without a clear error. Either no CAA record, or one including 0 issue "digicert.com", is what you want.

FOURTH - grab the correlation ID

In the portal, open the Static Web App, go to Activity log, filter to the custom domain operation and open the Failed entry. The correlation ID is a GUID and is safe to post publicly. Include the event timestamp in UTC.

On the certificate you're seeing

*.msha-slice-2-hk1-1-ase.p.azurewebsites.net matches the slice your app sits on - the same "2" that appears in ambitious-tree-08d7b6e00.2.azurestaticapps.net. The most likely explanation is that no certificate is bound for kcvue.mmoser.com at the edge, so the connection falls back to that slice-level certificate. I'd treat that as the strongest reading rather than documented behaviour, but it lines up with the Generate code failure telling us the same thing from the other side: the binding never completed.

An almost identical certificate common name was reported in August 2025 and Microsoft confirmed it as a platform-level issue at the time, not a customer configuration problem.

Two things not to do yet

Don't delete the custom domain and re-add it. That's the usual advice for certificate problems, but the docs note that deleting a custom domain mapped to your account can take up to 48 hours to propagate - so if the underlying entity is in a bad state you can end up worse off with no quick way back. Let's read the ExtendedCode first.

And on sequencing: enterprise-grade edge lists a configured custom domain (TTL under 48 hours) and the Standard hosting plan as prerequisites. The domain needs to be healthy on the Static Web App itself before the edge side will validate, so chasing edge validation while the SWA-side entity is failed will keep looping.

Context worth having

There have been several Static Web Apps custom-domain and certificate provisioning reports in the 11-14 August 2026 window with this same shape - correct DNS, TXT visible publicly, CAA permitting DigiCert, domain still landing in Failed. Some were cleared by a backend mitigation applied by Microsoft; others in the public threads never reached a documented resolution, so I don't want to promise you that outcome. Knowing roughly when kcvue.mmoser.com first started failing would help confirm or rule out that correlation quickly.

References: az staticwebapp hostname - https://learn.microsoft.com/en-us/cli/azure/staticwebapp/hostname?view=azure-cli-lates - see the hostname show example for fetching the validation token

Enterprise-grade edge - https://learn.microsoft.com/en-us/azure/static-web-apps/enterprise-edge - Prerequisites and Considerations

Set up a custom domain with external providers - https://learn.microsoft.com/azure/static-web-apps/custom-domain-external

Post back with the validationToken result from the first command, the ExtendedCode from the --debug run, and the correlation ID.

Thanks