AFD custom domain validation stuck in Pending despite correct TXT record on all authoritative nameservers

Anonymous
2026-07-24T05:55:54.01+00:00

Custom domain on Front Door Premium profile is stuck in domainValidationState=Pending and never validates, despite the DNS TXT record being provably correct.

Evidence (verified repeatedly since 2026-07-18):

  • All three authoritative nameservers for the custom domain (ns1/ns2/ns3.meganameservers.com) return exactly the expected token when queried directly.
  • Google (8.8.8.8) and Cloudflare (1.1.1.1) both return the exact token; Google DoH reports fetching it directly from the authoritative servers (69.49.97.150, 209.235.143.97).
  • Only one TXT record exists at that name; no CAA records on the zone; the CNAME is in place and resolving.

The previous token (valid until 2026-07-21) was also correctly published from 2026-07-16, yet validation stayed Pending and then moved to Rejected after a resubmit on 2026-07-17 - despite all three authoritative servers serving the correct value then too. After regeneration on 2026-07-17 the new value was published within a day, and validation has again sat in Pending for ~6 days.

We want to avoid another token regeneration as the DNS zone is managed by a third-party municipal customer.

Azure Front Door
Azure Front Door

An Azure service that provides a cloud content delivery network with threat protection.

2 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Vinodh247-1375 44,556 Reputation points Volunteer Moderator
    2026-07-24T11:38:04.8633333+00:00

    Hi ,

    Thanks for reaching out to Microsoft Q&A.

    This is almost certainly not a DNS propagation issue on your side but a validation pipeline problem within front door premium. You have already proven authoritative correctness (all NS, public resolvers, and DoH agree), which rules out the usual causes (TTL/caching/multiple TXT/CAA conflicts). What typically causes this exact behaviour is front door’s domain validation service caching a failed lookup or querying stale resolver paths that do not refresh correctly after token regeneration; once it gets into that state, it can remain stuck in Pending or flip to Rejected even though DNS is correct. Given that both the old and new tokens were verifiably present before expiry and still failed, you should not regenerate again. The practical path is to raise a support ticket and ask for backend revalidation/reset of the custom domain (they can force a re-check against authoritative NS or clear the cached validation state). As a workaround while waiting, ensure the TXT is at the exact expected label (no root vs subdomain mismatch) and temporarily lower TTL if possible, but based on your evidence the resolution will require Microsoft intervention rather than further DNS changes.

    Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

    Was this answer helpful?

  2. Sina Salam 31,456 Reputation points Volunteer Moderator
    2026-07-24T13:00:35.1933333+00:00

    Hello Dogan Erisen,

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

    I understand that your AFD custom domain validation stuck in Pending despite correct TXT record on all authoritative nameservers.

    This is most likely an Azure Front Door validation or managed-certificate issuance workflow that did not complete correctly.

    The way to resolve is to:

    • Confirm that the current Azure Front Door validationProperties.validationToken still matches the live _dnsauth TXT value.
    • Use Refresh on the custom domain validation state, not Regenerate, because regeneration creates a new TXT token and requires another DNS update. - https://stackoverflow.com/questions/76031886/azure-front-door-custom-domain-not-using-correct-cert
    • If the domain remains Pending, Internal team will attend to you as you've open an Azure Support with PCS.
    • NB: If it's taken longer, regenerate the validation token and update DNS, or use a customer-managed certificate through BYOC as the production workaround. Azure Front Door supports BYOC when the certificate CN or SAN matches the custom domain.

    This avoids repeating DNS troubleshooting that has already been completed, protects the customer from unnecessary token rotation, and gives the only reliable path to both service recovery and root-cause confirmation.

    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.

    Was this answer helpful?

    0 comments

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.