Front Door custom domain stuck in Pending validation despite DNS TXT record confirmed correct by Azure's own diagnostics

Question

Environment:

• Azure Front Door Standard/Premium (engine3-frontdoor, resource group rg-engine-3-prod)
• 4 custom domains: join.drillandbill.com, join.frontdeskdog.com, join.rocketcitybrief.com, join.thecleaningfee.com
• Duration: 48+ hours in Pending validation state (unchanged)

Issue: All 4 custom domains are stuck in domainValidationState: Pending despite Azure's own diagnostics confirming the DNS TXT records are correct.

Azure's own Apollo Diagnostics results (from the New Support Request flow): For each of the 4 domains, the automated diagnostic explicitly states: "The public DNS TXT record for _dnsauth.join.<domain> correctly matches the expected value... However, the validation state is Pending."

Independent verification (CLI + public DNS):

• az afd custom-domain show confirms domainValidationState: Pending on all 4, unchanged for 48+ hours
• TXT records for _dnsauth.join.<domain> verified correct via nslookup/DoH against multiple public resolvers (Google 8.8.8.8, Cloudflare)
• Route/origin/endpoint provisioningState: Succeeded throughout
• No CAA records exist on any of the 4 apex domains (ruling out CAA restriction as a cause)
• A no-op PATCH on the custom domain resource had no effect
• Have not regenerated the TXT validation token yet, to avoid invalidating a token Azure's own diagnostics already confirms is correct

Request: Could the backend validation state for these 4 custom domains be manually re-checked or reset? This matches the pattern in other threads (e.g. questions 5955865 and 5774060) where a moderator offered backend revalidation. Happy to share subscription/resource IDs privately.

Answer 1

Hello Andrew Dikih,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Front Door custom domain stuck in Pending validation despite DNS TXT record confirmed correct by Azure's own diagnostics.

It's certain that the TXT record validates domain ownership, while the CNAME only controls traffic routing to the Front Door endpoint. - https://learn.microsoft.com/en-us/azure/frontdoor/domain, https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/how-to-add-custom-domain

The best practice to resolve it is to:

• Confirm the TXT value currently stored on the Azure Front Door custom domain resource.
• Confirm the public _dnsauth.<subdomain> TXT record exactly matches that value.
• If the domain remains Pending, regenerate the validation token from Azure Front Door.
• Update DNS with the new TXT token.
• Wait for DNS TTL and refresh the domain validation state.
• If it remains stuck after the regenerated token is publicly visible, delete and recreate the custom domain or open Azure Support for backend validation reset.

You have to do the above, if not the domain remains Pending after the TXT record is updated, you should Regenerate the TXT validation value and add the updated TXT record again. If regeneration does not work, the documented recovery is to delete and recreate the domain, or escalate if the state still does not reflect correctly. - https://learn.microsoft.com/en-us/azure/frontdoor/domain

Use the below resource links for more reading and steps:

• Azure Front Door custom domain configuration: https://learn.microsoft.com/azure/frontdoor/standard-premium/how-to-add-custom-domain
• Azure Front Door domain validation states and TXT record requirements: https://learn.microsoft.com/azure/frontdoor/domain
• Azure CLI command for Front Door custom domains: https://learn.microsoft.com/cli/azure/afd/custom-domain
• REST API to refresh validation token: https://learn.microsoft.com/rest/api/frontdoor/azurefrontdoorstandardpremium/afd-custom-domains/refresh-validation-token

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

---

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.