Static Web Apps custom domain stays in `Validating` forever (dns-txt-token) AND fails with empty `Unspecified` error (cname-delegation) for the same subdomain

[rafaelturon]

Describe the bug

A single Static Web App custom domain cannot be bound using either documented validation method. Both fail in different ways for the same SWA + DNS configuration. We tested both methods exhaustively over 2 weeks.

Failure A — Free SKU + dns-txt-token:

• After az staticwebapp hostname set --validation-method dns-txt-token, resource stays provisioningState: Validating indefinitely (>15 min observed across many attempts).
• An orphaned binding from our last test has been Validating for >3 hours with perfect DNS state (TXT TTL=30, value byte-equal to validationToken).

Failure B — Standard SKU + cname-delegation:

• In-place SKU upgrade to Standard (no other change).
• Bicep-declared Microsoft.Web/staticSites/customDomains with validationMethod: 'cname-delegation' reaches terminal provisioningState: Failed.
• Error: code: "Unspecified", message: "" (empty string).
• Hostname API surface reports: "An unknown error has occurred while adding your custom domain. Please try again later."

Has this been validated against the latest version?

Yes (Azure CLI 2.x current, latest support extension, latest SWA API version via Bicep).

Steps to reproduce

1. Deploy a SWA (Free or Standard SKU) in westeurope.
2. Configure DNS in any Azure DNS zone:
   • <host> CNAME → SWA defaultHostname (TTL 300)
   • asuid.<host> TXT → SWA validationToken (TTL 30)
3. Wait until dig +short @8.8.8.8 asuid.<host> TXT returns the exact token.
4. Free SKU: az staticwebapp hostname set --validation-method dns-txt-token --hostname <host> -n <swa> -g <rg> → poll az staticwebapp hostname show → status stays Validating forever.
5. OR Standard SKU: deploy Bicep Microsoft.Web/staticSites/customDomains with validationMethod: 'cname-delegation' → ARM returns Failed with empty message.

Expected behavior

provisioningState transitions Validating → Ready (Free path) or Succeeded immediately (Standard cname-delegation path), since DNS preconditions are met.

Actual behavior

Both validation methods fail as described above. Hostname is never bound.

Live evidence (orphaned binding still active for repro)

• Region: westeurope
• SKU: Standard (failure reproduced under both Free and Standard)
• Hostname status: Validating for >3 hours at time of filing
• DNS preconditions: verified globally via 8.8.8.8 and 1.1.1.1
  • <host> CNAME → SWA defaultHostname (TTL 300)
  • asuid.<host> TXT → exact validationToken value (TTL 30)

Subscription ID, tenant ID, resource group, SWA name, hostname, validation token, and ARM correlation IDs are available on request — happy to share privately with whoever picks this up (comment here and I'll DM via the contact channel of your choice, or open a paid support ticket if that's the preferred route).

What we have ruled out

• DNS propagation: TXT TTL=30, propagated >24h, verified via Google + Cloudflare resolvers
• TXT value mismatch: byte-equal to validationToken
• CNAME punctuation / target: CNAME points to the SWA's own defaultHostname
• Other Azure resource holding the hostname: tenant-wide Resource Graph search returned zero conflicts
• A/AAAA record conflicts: none exist
• Region routing: SWA is in westeurope as expected
• SKU: confirmed via az staticwebapp show --query sku.name after the flip (Standard)

Workaround

Custom-domain binding disabled in both Bicep and the deploy workflow. Staging serves on the *.azurestaticapps.net default hostname. We did not delete the orphaned Validating binding so an Azure engineer can inspect it directly — but it will not survive indefinitely, so timely triage helps.

Your Environment

• Azure region: westeurope (SWA + DNS zone)
• Support plan: Developer (cannot file API ticket, hence GitHub issue)
• Deployment tooling: Bicep + GitHub Actions + Azure CLI

Additional context

This blocked a 2-week sprint and required multiple PRs of workflow/Bicep iteration before we accepted the workaround. Full ARM correlation IDs, run logs, and a live resource for direct inspection are available on request.