New custom domains cannot be added to Azure Static Web Apps.

Oleg 0 Reputation points
2026-08-21T12:41:02.9466667+00:00
  • Static Web App: hype-ad-pilot-psychology
  • Resource group: hype-ad
  • Custom domain: psychology.hype.ad
  • Default hostname: black-sky-01947bb03.7.azurestaticapps.net
  • Subscription: dad47871-ad69-4718-bc0d-798f978d03aa

The Static Web App exists and works through its default Azure hostname. The DNS CNAME also exists and correctly points:

psychology.hype.ad → black-sky-01947bb03.7.azurestaticapps.net

However, the custom domain is not created:

az staticwebapp hostname list returns [].

Both CNAME and TXT validation fail with:

Operation returned an invalid status 'Not Found'

The Activity Log reports:

  • Operation: Microsoft.Web/staticSites/customdomains/write
  • Status: Failed
  • HTTP status: 404 Not Found
  • Error code: BadRequest
  • Message: The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
  • Correlation ID: ad7a50f6-0426-40a3-b78e-14cf17c1d3d3
  • Operation ID: db3952fa-9493-45de-a100-8772be6af0f9

The same issue affects multiple new domains, including onelazylinguist.hype.ad and real-estate.hype.ad, across West Europe and Central US. An existing domain, stage.hype.ad, continues to work.

Please investigate which internal resource or dependency returns NotFound during the custom-domain creation operation.

Azure Static Web Apps
Azure Static Web Apps

An Azure service that provides streamlined full-stack web app development.

2 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Allan Solomon Mejia 7,915 Reputation points
    2026-08-21T16:01:28.69+00:00

    Hello @Oleg

    Based on the details you've provided, I don't think this is a normal DNS propagation or CNAME configuration issue.

    Your CNAME already resolves to the correct *.azurestaticapps.net hostname, while the actual ARM operation:

    Microsoft.Web/staticSites/customDomains/write is returning HTTP 404 / BadRequest. More importantly, the same failure occurs with multiple new domains and Static Web Apps across West Europe and Central US, while an existing custom domain continues working. That pattern points more toward a failure in the Static Web Apps custom-domain provisioning/validation backend than the individual DNS record.

    One important validation detail is worth checking. Microsoft currently documents that custom-domain verification requires publicly resolvable DNS, and the Azure CLI supports TXT-token validation.

    I would test one affected domain explicitly with TXT validation:

    az staticwebapp hostname set \
  --name hype-ad-pilot-psychology \
  --resource-group hype-ad \
  --hostname psychology.hype.ad \
  --validation-method dns-txt-token \
  --no-wait

    Then check whether Azure has created the custom-domain resource/token:

    az staticwebapp hostname show \
  --name hype-ad-pilot-psychology \
  --resource-group hype-ad \
  --hostname psychology.hype.ad

    Microsoft documents hostname show as the command that can retrieve the validation token generated for TXT validation.

    If this still immediately returns the same 404 before a validation token/custom-domain resource is created, then DNS itself is unlikely to be the root cause. Azure isn't getting far enough into the operation to perform normal DNS validation.

    You can also run the operation with --debug and retain the response/request information:

    az staticwebapp hostname set \
  -n hype-ad-pilot-psychology \
  -g hype-ad \
  --hostname psychology.hype.ad \
  --validation-method dns-txt-token \
  --debug

    I would not delete or modify the existing working stage.hype.ad binding while troubleshooting this.

    Given the combination of multiple new domains affected, multiple regions affected, existing bindings still working, and ARM customDomains/write returning 404, I think this warrants escalation to Microsoft if TXT validation produces the same result.

    When opening the support request, provide the Correlation ID and Operation ID you've already captured, together with the UTC timestamp, subscription ID, Static Web App resource ID, affected domains, and the fact that both CNAME and TXT creation paths fail.

    The key point for Microsoft to investigate is why the backend handling Microsoft.Web/staticSites/customDomains/write is returning NotFound even though the parent Static Web App resource exists and is operational.

    Microsoft's documented behavior for a standard CNAME validation failure is that Azure validates whether the CNAME is available in public DNS; that doesn't match well with an immediate ARM-level 404 Not Found affecting several otherwise valid resources.

    Sharing these references with you:

    Microsoft - Custom domains with Azure Static Web Apps

    Microsoft - Azure CLI: az staticwebapp hostname

    Microsoft - Configure a Static Web Apps custom domain with an external DNS provider

    At this point, I'd treat it as a likely service-side provisioning issue rather than repeatedly changing the DNS records, especially since you've reproduced it across multiple domains and regions.

    Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

    Was this answer helpful?

  2. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.