Azure Static Web Apps apex custom domain stuck in Validating despite authoritative TXT record

Hello @Jerald Felix

Its still stuck despite the changes made in the DNS record. Unfortunately this seems to be a widespread problem which Azure is not fixing.

kind regards,

Prashant Shah

Hello @Jerald Felix

Its still stuck despite the changes made in the DNS record. Unfortunately this seems to be a widespread problem which Azure is not fixing.

kind regards,

Prashant Shah

Hello Prashant Shah ,

Greetings! Thanks for raising this question in the Q&A forum.

The good news is that your DNS setup is not the problem. Placing the TXT record at _dnsauth.www.<yourdomain> for an apex domain is actually the documented and correct format, so your record placement, the token itself, and your authoritative resolution all check out. What you are hitting instead is a known category of backend validator issue where Static Web Apps gets wedged in Validating for an apex hostname even though the TXT record is fully correct and publicly resolvable, while a sibling www binding on the same app validates normally within minutes. Several other reports show this exact signature, apex stuck with errorMessage: null for hours or days despite a verified TXT record, and in every case the resolution required Azure Support to inspect and manually reset the validation state on the backend rather than anything changeable from the customer side.

Before opening a ticket, it is worth ruling out the two most common secondary causes so the support engineer can close the ticket faster.

Check for a duplicate or stale TXT record at the same host. If an older validation token was ever added at _dnsauth.www.flowgrid.one and not fully removed before the new token was published, you can end up with two TXT records at that name. Some validators only read the first record returned and can silently ignore the correct one. Run dig @ns01.hostnet.nl TXT _dnsauth.www.flowgrid.one and confirm only one TXT value is returned, matching your current token exactly.

Rule out an orphaned or cross-subscription domain binding. If flowgrid.one was ever added to a different Static Web App, App Service, storage account static website, or a subscription that was later deleted, Azure can leave a lingering domain ownership record that blocks new validation from completing cleanly, even when the new binding otherwise looks correct. Check any other subscriptions you have access to, and consider whether this domain was ever configured elsewhere in the past.

Confirm there are no CAA records restricting certificate issuance at the apex. This will not cause the Validating state itself but can cause a secondary stall once DNS validation completes, so it is worth eliminating now. Run dig CAA flowgrid.one and confirm either no CAA records exist or they explicitly allow the certificate authority Static Web Apps uses.

If both of the above are clean, open an Azure Support ticket rather than continuing to recreate the binding. You have already done the full reset cycle correctly, deleting and recreating the binding, generating a fresh token, and confirming authoritative resolution, so further deletes and recreates are unlikely to change the outcome. This needs a backend engineer to inspect and clear the validator state for the hostname resource.

Include the following in the support request to speed up triage: subscription ID, resource group rg-flowgrid-prod, static web app name flowgrid-web-prod, the domain flowgrid.one, the current validation token fjmnlnu51l21ppb6h40uyh2w0xh5vy7, the dig output showing authoritative resolution, and the timestamps of your delete and recreate attempts. This is the same information that resolved the identical stuck-apex scenario in other recent threads.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.