Custom domain creation fails with ResourceOperationFailure across multiple SWAs after cross-subscription move

[imfine-sd]

Describe the bug

All custom domain additions to Azure Static Web Apps fail with
"An unknown error has occurred while adding your custom domain. Please try again later."

The Activity Log shows:

{"status":"Failed","error":{"code":"ResourceOperationFailure","message":"The resource operation completed with terminal provisioning state 'Failed'."}}

subStatus is empty, so no actionable error surfaces to the control plane.
The domain entry then becomes stuck — even DELETE operations do not complete.

Context

Two Static Web Apps were moved to a newly created subscription within the same
tenant shortly before this started. I suspect this may be related to the known
cross-subscription move issues affecting SWA backend state.

What I have verified

• CNAME resolves correctly and publicly (verified via 8.8.8.8) to the exact
  default hostname of the target Static Web App
• No CAA records exist on the apex or the subdomain (verified via Google DNS-over-HTTPS,
  empty Answer, Status 0)
• DNS is hosted on Cloudflare, proxy disabled (DNS-only / grey cloud)
• No Azure DNS zone exists for these domains
• Free plan custom domain limit is not reached on the affected apps
• The domains are not bound to any other Azure resource

Reproduced across every variable

Variable	Values tried	Result
Domain	two unrelated domains, different registrars	fail
Static Web App	newly created and pre-existing apps	fail
Subscription	newly created subscription	fail
Service type	App Service (.NET 8) in the same subscription/tenant	succeeds

Custom domain binding works normally on App Service using the same DNS setup.
Only Static Web Apps fail, which points to the SWA control plane rather than DNS
or tenant permissions.

Failure identifiers

• correlationId: 8903ba11-a15e-4448-aa23-f5863f00dc00
• operationId: ad40e7d7-f101-488a-8a02-5627b74adb63
• eventTimestamp: 2026-08-12T08:16:21.9298045Z
• operationName: Microsoft.Web/staticSites/customdomains/write
• Region:Korea Central
• Plan: Free

I can provide subscription ID, resource names and affected hostnames privately
if a maintainer requests them.

Expected behavior

Custom domain validation completes, or the operation returns a specific,
actionable error code instead of a terminal generic failure.

Additional context

The stuck domain entries cannot be deleted, which suggests the customDomains
child resources are left in an unrecoverable provisioning state.
Please advise whether backend state can be cleared for the affected apps.

[ebibibi]

We are hitting exactly this right now (2026-08-13 JST, East Asia, Standard plan). Our trigger is different from yours — no cross-subscription move was involved — so the backend state corruption does not seem to be specific to subscription migration.

What happened

1. Created a CNAME in Azure DNS pointing at the SWA default hostname, then bound the custom domain about a minute later. It went to Failed with An unknown error has occurred while adding your custom domain. Please try again later.
2. A PUT on the Failed custom domain resource returns the existing Failed resource. It does not re-run validation, and an ARM template deployment over it reports success while the domain stays broken.
3. Deleting it leaves it in Deleting indefinitely. az staticwebapp hostname delete blocks for ~10 minutes and then fails with Operation returned an invalid status 'OK', while the resource stays in Deleting.
4. Deleting the parent Static Web App does not complete either.
5. Creating a brand new Static Web App in the same resource group and binding the same name there fails the same way.

What we ruled out, with controlled tests

• DNS content: the CNAME resolves correctly through public resolvers to the SWA default hostname.
• CAA: there are no CAA records on the apex zone or the delegated child zone, so any CA may issue.
• Name reuse / name-specific wedging: we bound a host name that had never been used anywhere. Same Failed.
• DNS negative caching: our zone SOA minimum is 300s, so we suspected the bind was racing a cached NXDOMAIN. We created another unused name, confirmed it resolvable through 8.8.8.8, and bound it 12 minutes later. It sat in RetrievingValidationToken for about five minutes and then went to Failed. So the timing hypothesis is wrong, at least for this failure mode.
• Not the whole service: a custom domain on a different SWA in the same resource group and region, bound before today, is still Ready and serving normally. Only operations performed today fail.

Current state on our side: three names stuck in Deleting (one for more than 26 hours), and two Failed. Every retry only adds another stuck record, so we have stopped retrying.

For anyone finding this thread: the Deleting state has cleared by itself after roughly 8–24 hours in several Microsoft Q&A reports (5940923, 5940566), with no root cause given. Also, several answers around this symptom recommend adding a CAA record allowing DigiCert. That advice looks wrong: absence of a CAA record already permits every CA, so adding one can only restrict issuance.

Two things that would help a lot, independent of the backend fix:

1. Surface the real error. An unknown error has occurred is returned for DNS problems, for platform problems, and for wedged state alike, which makes self-diagnosis impossible.
2. Make Failed recoverable without deleting. Today a Failed custom domain cannot be re-validated by a PUT, and deleting it is what leads to the unrecoverable Deleting state.

We have an open Azure support case for this (case ID available on request if a maintainer wants to correlate).