Static Web Apps: custom domain stuck on "Validation failed" – "An unknown error has occurred while adding your custom domain" despite correct CNAME, confirmed via REST API / CLI

Question

Static Web Apps: custom domain stuck on "Validation failed" – "An unknown error has occurred while adding your custom domain" despite correct CNAME, confirmed via REST API / CLI

Philipp Losbichler 20

I am posting here because the Azure portal does not offer a technical support ticket option for Static Web Apps and explicitly redirects to Microsoft Q&A, so this is the only channel available to me for this issue.

Environment

Resource type: [Microsoft.Web/staticSites] (Azure Static Web Apps), API version 2025-05-01
Region: Germany West Central
Two custom domains on the same Static Web App, both subdomains of the same zone (e.g. app.example.com and dam.example.com)
Auto-generated hostname (<generated>.azurestaticapps.net): status Validated, site is served correctly over that hostname
Hostname record type: CNAME

Problem Both custom domains are permanently in the state "Validation failed". Every attempt to add them or re-trigger validation ends with the same generic message:

An unknown error has occurred while adding your custom domain. Please try again later.

DNS is confirmed correct and fully propagated Verified via [dnschecker.org] (CNAME lookup) across many public resolvers worldwide (Google, OpenDNS, Quad9, Akamai and others). Every resolver returns the correct target, i.e. the auto-generated <generated>.azurestaticapps.net hostname, with a green check. Records have been in place far beyond the documented 48-hour propagation window.

Reproduced directly against the REST API / az cli (bypassing the portal) To rule out a portal-only bug, I re-triggered validation via az staticwebapp hostname set --validation-method cname-delegation --debug. This confirms the error is server-side, not a portal rendering issue:

POST /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/staticSites/{app}/customDomains/dam.example.com/validate?api-version=2025-05-01
→ 200 OK

PUT /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/staticSites/{app}/customDomains/dam.example.com?api-version=2025-05-01
→ 200 OK
{
  "createdOn": "2026-08-12T18:45:03.126808+00:00",
  "domainName": "dam.example.com",
  "errorMessage": "An unknown error has occurred while adding your custom domain. Please try again later.",
  "status": "Failed",
  "validationToken": null
}

Two things stand out that I'd like an engineer to check server-side:

Total round trip was ~2.2 seconds. That is far too fast for a genuine external CNAME resolution against a live DNS record, which suggests no fresh validation attempt actually ran and the endpoint is just returning a previously stored Failed state.
createdOn is ~35 minutes older than the request timestamp, reinforcing that this looks like a stale/cached error object being re-served rather than a new validation cycle.

The call returned HTTP 200 (not a 4xx/5xx), so this is not an auth or malformed-request issue – the error is stored inside the domain resource itself.

What I have tried

Re-triggering validation repeatedly over several hours, both via portal and via az cli / REST directly
Deleting the custom domain entry and adding it again from scratch (even the delete got stuck)
Confirming global CNAME propagation via [dnschecker.org] (all resolvers correct)
Confirming the auto-generated hostname itself is validated and serving the app

Questions

Given the request IDs above, can someone check the backend logs for why this domain object is stuck with a stored Failed/generic error state instead of running a fresh validation?
Is there a known cause for this generic "unknown error" when DNS is verifiably correct and the round-trip timing suggests no real validation attempt occurred?
Can a stale or orphaned custom-domain binding on the backend (e.g. left over from a previously deleted Static Web App or App Service, possibly in a different subscription) cause the hostname to be silently rejected, and if so, can it be cleared from the backend?
Would a CAA record in the zone that does not permit the issuing CA cause this same generic error rather than a certificate-specific one at this stage?
Given that no technical support ticket can be opened for Static Web Apps from the portal, what is the intended escalation path when both the portal and the REST API return no diagnostic detail beyond this generic message?

Happy to provide the full resource ID, additional --debug output, or DNS records privately to a Microsoft engineer if that helps. This is currently blocking a production go-live on the intended hostnames.I am posting here because the Azure portal does not offer a technical support ticket option for Static Web Apps and explicitly redirects to Microsoft Q&A, so this is the only channel available to me for this issue.

Environment

Resource type: [Microsoft.Web/staticSites] (Azure Static Web Apps), API version 2025-05-01
Region: Germany West Central
Two custom domains on the same Static Web App, both subdomains of the same zone (e.g. app.example.com and dam.example.com)
Auto-generated hostname (<generated>.azurestaticapps.net): status Validated, site is served correctly over that hostname
Hostname record type: CNAME

Problem
Both custom domains are permanently in the state "Validation failed". Every attempt to add them or re-trigger validation ends with the same generic message:

An unknown error has occurred while adding your custom domain. Please try again later.

DNS is confirmed correct and fully propagated
Verified via [dnschecker.org] (CNAME lookup) across many public resolvers worldwide (Google, OpenDNS, Quad9, Akamai and others). Every resolver returns the correct target, i.e. the auto-generated <generated>.azurestaticapps.net hostname, with a green check. Records have been in place far beyond the documented 48-hour propagation window.

Reproduced directly against the REST API / az cli (bypassing the portal)
To rule out a portal-only bug, I re-triggered validation via az staticwebapp hostname set --validation-method cname-delegation --debug. This confirms the error is server-side, not a portal rendering issue:

POST /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/staticSites/{app}/customDomains/dam.example.com/validate?api-version=2025-05-01
→ 200 OK

PUT /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/staticSites/{app}/customDomains/dam.example.com?api-version=2025-05-01
→ 200 OK
{
  "createdOn": "2026-08-12T18:45:03.126808+00:00",
  "domainName": "dam.example.com",
  "errorMessage": "An unknown error has occurred while adding your custom domain. Please try again later.",
  "status": "Failed",
  "validationToken": null
}

Two things stand out that I'd like an engineer to check server-side:

Total round trip was ~2.2 seconds. That is far too fast for a genuine external CNAME resolution against a live DNS record, which suggests no fresh validation attempt actually ran and the endpoint is just returning a previously stored Failed state.
createdOn is ~35 minutes older than the request timestamp, reinforcing that this looks like a stale/cached error object being re-served rather than a new validation cycle.

The call returned HTTP 200 (not a 4xx/5xx), so this is not an auth or malformed-request issue – the error is stored inside the domain resource itself.

What I have tried

Re-triggering validation repeatedly over several hours, both via portal and via az cli / REST directly
Deleting the custom domain entry and adding it again from scratch (even the delete got stuck)
Confirming global CNAME propagation via [dnschecker.org] (all resolvers correct)
Confirming the auto-generated hostname itself is validated and serving the app

Questions

Given the request IDs above, can someone check the backend logs for why this domain object is stuck with a stored Failed/generic error state instead of running a fresh validation?
Is there a known cause for this generic "unknown error" when DNS is verifiably correct and the round-trip timing suggests no real validation attempt occurred?
Can a stale or orphaned custom-domain binding on the backend (e.g. left over from a previously deleted Static Web App or App Service, possibly in a different subscription) cause the hostname to be silently rejected, and if so, can it be cleared from the backend?
Would a CAA record in the zone that does not permit the issuing CA cause this same generic error rather than a certificate-specific one at this stage?
Given that no technical support ticket can be opened for Static Web Apps from the portal, what is the intended escalation path when both the portal and the REST API return no diagnostic detail beyond this generic message?

Happy to provide the full resource ID, additional --debug output, or DNS records privately to a Microsoft engineer if that helps. This is currently blocking a production go-live on the intended hostnames.

Praneeth Maddali 12,670 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-08-12T19:33:56.7233333+00:00

Hallo @Philipp Losbichler

Vielen Dank, dass Sie Ihre Frage auf Microsoft Q&A gestellt haben. Bitte beachten Sie, dass die Antworten aus dem Englischen übersetzt wurden und grammatikalische Fehler enthalten können.

Danke, dass Sie den Microsoft-Support wegen des Problems kontaktiert haben, bei dem die benutzerdefinierte Domain im Zustand „Löschen“ festhängt. Wir haben begonnen, das Problem zu untersuchen, und prüfen derzeit die Konfiguration und den Backend-Status. Wir halten Sie über unsere Erkenntnisse auf dem Laufenden und teilen alle Empfehlungen oder nächsten Schritte so schnell wie möglich mit Ihnen. Wenn Sie weitere Details haben, die bei der Untersuchung helfen könnten, lassen Sie uns diese gern wissen. Wir danken Ihnen für Ihre Geduld und Ihr Verständnis, während wir daran arbeiten, das Problem zu lösen. ...
Philipp Losbichler 20 Zuverlässigkeitspunkte

2026-08-12T21:18:42.8433333+00:00
Hi @Praneeth Maddali ,

Thank you for the update. To clarify and add important history that’s likely relevant to your investigation:

My custom domains on the current resource (<prefix>swa2) are not stuck in "Delete" – they are stuck in "Validation failed" (status: "Failed"), as shown in the REST API output in my original post.

However, there is a stuck-deletion history that may well be the root cause:

I originally had this same custom domain configured on a different, earlier Static Web App resource in the same resource group (name: <prefix>swa).

On that first SWA, I ran into the same custom domain validation problem.

I then tried to delete the custom domain from that first SWA to reset it – this deletion got stuck and did not complete successfully.

I then tried to delete the entire first SWA resource – this also did not fully succeed / behaved inconsistently.

I created a new Static Web App (<prefix>swa2) and re-added the same custom domain and an additional one there – and I'm now hitting the identical "Validation failed" / generic unknown error on the new resource on both domains.

Given this, one theory (also outlined in my original post) is that there is a stale/orphaned custom-domain binding left over from the first SWA that never fully deleted, which is now blocking validation of that hostname on the new SWA. However, this doesn't fully explain why the second custom domain — which was never configured on the first SWA — fails with the exact same generic error. This makes me suspect there may be a broader issue affecting custom domain validation on this Static Web App (or in this subscription/region) rather than something scoped only to the leftover binding from the first SWA.

Could someone check server-side whether:

the first SWA resource (<prefix>swa) or its custom domain bindings for the two hostnames in question still exist in a "stuck deleting" state on the backend, and

whether that stuck state is what's blocking validation on the new SWA?

I'd prefer not to post the resource group / subscription details or exact hostnames again in this public thread – happy to share them with a Microsoft engineer privately (e.g. via a support ticket number or a private message channel) if that helps move the investigation forward.

Thanks again for looking into this.

Best regards, Philipp

Antwort, die vom Frageautor angenommen wurde

Praneeth Maddali 12,670 Externe Microsoft-Mitarbeiter Moderator

hallo @Philipp Losbichler

ja, es hängt mit DZXC-65Z zusammen

Danke für Ihre Geduld, während wir das überprüft haben.

Wir haben die Bestätigung erhalten, dass Maßnahmen ergriffen wurden, und Ihr Problem mit der benutzerdefinierten Domain sollte nun behoben sein. Könnten Sie bitte die Aktion erneut versuchen und prüfen, ob alles wie erwartet funktioniert?

Wenn Sie weiterhin Probleme haben, antworten Sie bitte mit einem Update und allen relevanten Details. Wir helfen Ihnen gerne weiter und untersuchen das Problem bei Bedarf weiter.

Wir freuen uns darauf, von Ihnen zu hören.

Wenn die Antwort hilfreich ist, klicken Sie bitte auf "Antwort akzeptieren". Ja, dies kann für andere Community-Mitglieder nützlich sein.

Wenn Sie noch andere Fragen haben, lassen Sie es mich in den "Kommentaren" wissen, und ich helfe Ihnen gerne.

Philipp Losbichler 20 Zuverlässigkeitspunkte

2026-08-14T09:27:28.6866667+00:00
Hi Praneeth,

Thanks for confirming. I can confirm the issue is resolved on my end:

I was able to successfully delete the previously stuck custom domain

I was able to delete the entire Static Web App that had been stuck

On the other subscription/SWA I mentioned earlier, I was able to successfully validate the custom domain through the Azure Portal (haven't re-tested via CLI yet, but the portal path now works cleanly)

Everything is behaving as expected now. Thank you and the team for the investigation and for confirming the link to DZXC-65Z – marking this as accepted.

Best regards,

Philipp

1 zusätzliche Antwort

Ihre Antwort

Praneeth Maddali 12,670 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-08-12T19:33:56.7233333+00:00

Hallo @Philipp Losbichler

Vielen Dank, dass Sie Ihre Frage auf Microsoft Q&A gestellt haben. Bitte beachten Sie, dass die Antworten aus dem Englischen übersetzt wurden und grammatikalische Fehler enthalten können.

Danke, dass Sie den Microsoft-Support wegen des Problems kontaktiert haben, bei dem die benutzerdefinierte Domain im Zustand „Löschen“ festhängt. Wir haben begonnen, das Problem zu untersuchen, und prüfen derzeit die Konfiguration und den Backend-Status. Wir halten Sie über unsere Erkenntnisse auf dem Laufenden und teilen alle Empfehlungen oder nächsten Schritte so schnell wie möglich mit Ihnen. Wenn Sie weitere Details haben, die bei der Untersuchung helfen könnten, lassen Sie uns diese gern wissen. Wir danken Ihnen für Ihre Geduld und Ihr Verständnis, während wir daran arbeiten, das Problem zu lösen. ...
Philipp Losbichler 20 Zuverlässigkeitspunkte

2026-08-14T09:27:28.6866667+00:00

Hi Praneeth,

Thanks for confirming. I can confirm the issue is resolved on my end:

I was able to successfully delete the previously stuck custom domain

I was able to delete the entire Static Web App that had been stuck

On the other subscription/SWA I mentioned earlier, I was able to successfully validate the custom domain through the Azure Portal (haven't re-tested via CLI yet, but the portal path now works cleanly)

Everything is behaving as expected now. Thank you and the team for the investigation and for confirming the link to DZXC-65Z – marking this as accepted.

Best regards,

Philipp

Answer 1

Hi @Praneeth Maddali ,

I think I found the missing piece: I just received a Service Health advisory in the Azure Portal that appears directly related.

Tracking ID: DZXC-65Z – "Active - Azure Static Web Apps custom domain operations issue in multiple regions"

Status: Active, Warning
Start time: 2026-08-12T13:04:13Z (customer-facing impact noted from 14:30 UTC on 11 Aug 2026)
Region(s): Global
Impact statement: "you have been identified as an affected customer using Azure Static Web Apps in multiple regions who may experience failures or delays when deleting custom domains for resources hosted in the region"
Root cause (per the advisory): an increased backlog in the certificate synchronization processing queues, currently being drained via mitigation

This lines up closely with what I've been observing:

The unusually fast (~2–3 second) round-trip on my az cli --debug calls, with the domain object immediately coming back with a stored "status": "Failed" – consistent with a request landing in an already-backlogged queue rather than a fresh validation actually running
The fact that this reproduces identically across three different subscriptions, resource groups, and hostnames – consistent with a global backend queue issue rather than anything specific to my account/tenant, DNS, or resource configuration

My question: the advisory explicitly mentions delays/failures when deleting custom domains. Could the same certificate synchronization backlog also be causing failures when adding/validating new custom domains? All of my affected domains are stuck in "Validation failed" with the generic "An unknown error has occurred while adding your custom domain" message – not deletion. If the certificate sync queue is shared across create/update/delete operations, a backlog there could plausibly produce this exact symptom on the add/validate path too, even if the advisory's impact statement doesn't call that out explicitly.

Could you confirm whether DZXC-65Z is expected to also affect custom domain validation/creation, or whether my issue is a separate (if superficially similar) problem that needs its own investigation? If it's the same root cause, I'm happy to just wait for the backlog to clear – but I'd like to know whether to expect these domains to self-heal once the queue is drained, or whether they'll need to be manually reprocessed on your side.

Thanks, Philipp