Custom domain stuck in "Validating" status for 24+ hours despite correctly configured and propagated TXT record

Question

I'm trying to add a custom domain (mockee.io) to my Azure Static Web App, using TXT record validation. The domain has been stuck in "Validating" status for over 24 hours, even after I deleted the domain registration and re-added it fresh (which generated a new validation code).

What I've verified:

1. TXT record is correctly set at the DNS provider — Host: @, Type: TXT, Value matches exactly what Azure generated in the Custom Domain details panel.
2. Confirmed via direct query to the authoritative nameserver (jola.ns.jdm.pl), bypassing all local/ISP caching:

nslookup -type=TXT mockee.io jola.ns.jdm.pl
This returns the correct, current TXT code — confirming it's live at the source of truth, not just cached somewhere.

1. No CAA record exists on the domain, so there's no CA restriction blocking cert issuance:
   nslookup -type=CAA mockee.io → No answer (no CAA record present) DNS TTL is 7200 seconds, and I've waited well beyond that for propagation.
2. I deleted the custom domain entry entirely, waited, and re-added it — Azure generated a new validation code, I updated the TXT record to match, confirmed it resolved correctly at the authoritative nameserver — and it's still stuck in "Validating."

Additional context: The domain apex (mockee.io) currently still has an A record pointing to an existing WordPress site, since I haven't switched over the routing record yet — I understand from the docs that TXT validation should be independent of what the A/CNAME record points to, and only matters for actual traffic routing/cert renewal after validation.

Given DNS is confirmed correctly propagated and resolvable at the authoritative server level, is this a known backend delay/issue with the Static Web Apps validation service, or is there something else that could cause validation to stall this long? Is there a way to force Azure to re-check immediately rather than waiting on its polling cycle?

Answer 1

Hello Kacper Fertacz ,

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

Your DNS setup is actually correct as-is. For apex/root domains on Static Web Apps, the official validation record is a TXT record with Host: @ containing the generated code, exactly what you've configured. There has been some conflicting community advice floating around suggesting a _dnsauth.www.<domain> record instead, but that pattern doesn't match Microsoft's current documented apex domain validation flow and isn't something you should switch to based on what you've already confirmed at the authoritative nameserver.

Given everything you've already ruled out, first let's close out a couple of the remaining possibilities before treating this as backend-only:

Confirm no split-brain DNS Since the domain is delegated to jola.ns.jdm.pl, confirm that's genuinely the authoritative server the parent .io registry actually delegates to (not a leftover secondary or an old NS record still cached at the registry level). Run:

nslookup -type=NS mockee.io

against a public resolver like 8.8.8.8, and compare the returned NS set to what you queried directly.

Double check there is only one TXT record at the apex If a previous validation attempt left an old TXT record behind (from an earlier delete/re-add cycle) alongside the new one, some validators can get confused reading multiple TXT values at the same name. Query directly against the authoritative server and confirm only one TXT record exists at @:

nslookup -type=TXT mockee.io jola.ns.jdm.pl

Try one more clean delete and recreate, with a short TTL Delete the custom domain binding, wait a full 10 minutes this time (not just until the portal allows re-adding), set the TXT record TTL to 300 seconds, then re-add. This won't fix a backend wedge but rules out any lingering cached validation state tied to the previous token.

If all of the above still leaves it stuck, this matches a known pattern reported by other Static Web Apps users where the apex-domain validator specifically gets wedged server-side with no error surfaced to the customer API, while a sibling www binding on the same resource validates normally within minutes. In that pattern, DNS, CAA, and TTL are all confirmed correct exactly as you've done, and the fix requires Microsoft to manually re-trigger or inspect the validator on the backend, since there is no customer-facing lever to force an immediate re-check.

Please open a support case under Web > Static Web Apps > Custom domain / SSL and include:

• Static Web App resource ID and subscription ID
• The exact domain name (mockee.io)
• Timestamps of each delete/re-add cycle and the corresponding validation tokens used
• The nslookup output confirming the TXT record at the authoritative server
• A note that the www subdomain (if registered) validated normally, if applicable, since that helps the engineer isolate the wedge to the apex-specific code path

You can also file an issue on the Azure/static-web-apps GitHub repository, since the Static Web Apps engineering team actively monitors and has resolved this exact "stuck apex validator" symptom for other users there.

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

Best Regards,

Jerald Felix.