Azure App Service Managed Certificate creation fails after DNS zone migration even though custom domains are verified and public DNS is correct

I’m looking for help with what appears to be an Azure App Service Managed Certificate validation problem after a DNS zone migration.

Environment

• Azure App Service (Linux)
• Custom domains:
• teXX.flopXXX.neX
• api.teXX.flopXXX.neX
• App Service hostname bindings are present and show Verified
• We recently moved authoritative DNS for flopstr.net to a new Azure DNS zone and updated registrar delegation

Problem

Azure Managed Certificate creation still fails for both custom domains even though public DNS appears correct and the hostname bindings are verified.

The managed certificate creation fails with:

• BadRequest 54524
• Message indicating the current CNAME/A record is empty

For api.test.flopstr.net, App Service also reported this cause text:

[CheckARecordForHttpValidatedWebspaceASMCRequests]: Not found A record directly pointing to ip address 20.42.128.96 ... Current A record of the hostname api.test.flopstr.net has no A record set.

What we have already verified

• Registrar delegation has been updated to the new Azure DNS zone
• Public DNS resolves correctly from public resolvers
• test.flopstr.net and api.test.flopstr.net point to the App Service hostname as expected
• Required asuid TXT records are present:
• asuid.teXX
• asuid.api.teXX
• App Service custom hostname bindings are Verified
• We deleted and recreated hostname bindings/certificate attempts after the DNS cutover
• No managed certificate resources are being created successfully
• HTTPS on the custom domains still presents the wrong-principal/default certificate because the managed cert never issues

Why this seems Azure-side

What is confusing is that Azure shows the hostname bindings as Verified, public DNS is correct, but managed certificate creation still behaves as if the DNS record is missing.

Also, for api.test.flopstr.net, Azure appears to be asking for an A record to the webspace IP, even though this hostname is configured as a CNAME to App Service, which is the normal pattern for an App

Service subdomain.

Question

Has anyone seen Azure Managed Certificates get stuck in a stale or incorrect DNS validation state after DNS zone migration / delegation changes?

Is there a known way to force the managed certificate validator to refresh, or does this require Microsoft to reset/clear something server-side?

At this point I’m trying to determine whether this is:

1. a known propagation/cache delay inside Azure,
2. a managed certificate validator bug/stale state issue,
3. or a real requirement to temporarily change the DNS pattern for the subdomain.

I only have the Dev support plan or else I'd open a direct ticket on this issue.