Front Door Standard custom domain stuck at "Pending" validation — correct _dnsauth TXT record, survives token regeneration

Question

I have two Azure Front Door Standard custom domains, in two separate profiles (staging and production), configured identically. Production validated. Staging will not, and I need to fix it without issuing a new validation token.

What worked on production

Sending an empty PATCH to the domain API triggered validation immediately:

az rest --method patch --uri ".../customDomains/<name>?api-version=2024-02-01" --body '{}'

Production went Pending → Approved in seconds, deploymentStatus became Succeeded, and the managed certificate issued.

The same command on staging has done nothing, run three times over 24 hours.

The two are configured identically

Same subscription and region, same Front Door Standard SKU, ManagedCertificate, minimum TLS 1.2, each associated with a route with linkToDefaultDomain enabled. Both subdomains on the same Cloudflare zone, DNS-only, not proxied. Both created with the same CLI commands, differing only in resource names and hostname. Both CNAMEs still point at their App Service origins — deliberately, since ownership validation by TXT does not require the CNAME to be repointed first.

	Production	Staging
domainValidationState	Approved	Pending
--------	--------	--------
domainValidationState	Approved	Pending
deploymentStatus	Succeeded	NotStarted
provisioningState	Succeeded	Succeeded
Managed certificate	issued, secret bound	none
TXT matches current token	yes	yes
Single TXT record	yes	yes

Staging's DNS is verified correct

• TXT at _dnsauth.<subdomain> compared byte-for-byte against validationProperties.validationToken: 32 characters, exact match
• Same value from 1.1.1.1, 8.8.8.8, 9.9.9.9 and both authoritative nameservers
• One TXT record at the name, TTL 300. No stale or duplicate values. The previous value was replaced, not added alongside, over 24 hours ago
• No CAA records on the zone. Zone is not DNSSEC-signed
• No wildcard TXT, no CNAME at the validation name

Already tried on staging

1. Waited over 48 hours since a correct TXT record first existed
2. az afd custom-domain update --minimum-tls-version TLS12 (no-op PATCH with a body)
3. Empty PATCH to the domain API — three times. This is what worked instantly on production
4. Refresh on the portal's validation panel
5. Associating the domain with a route. This advanced DNS state from "Deploy to endpoint pending" to "Certificate needed" but did not trigger validation
6. az afd custom-domain regenerate-validation-token, then had the new TXT value put in place. Verified exact. Still Pending

My constraint

The documented next step is to delete and recreate the domain, but that issues a new token — and I do not control my organisation's DNS. Every token change is a change request to a third party, and I have already spent two.

Questions

1. Does deleting and recreating a custom domain always mint a new validationToken, or is the token derived from the hostname such that a recreated domain could reuse the existing TXT record? If it can be reused, the fix costs nothing.
2. Is there any other way to trigger validation for an existing domain without a new token?
3. Given production validated instantly with the same command and configuration, is there a known per-resource state that leaves one domain unable to validate — and is any of it visible from my side?