Azure Static Web Apps custom domain stuck in Validating despite correct DNS TXT validation

Question

Azure Static Web Apps custom domain stuck in Validating despite correct DNS TXT validation

Onion Support 20

I have an Azure Static Web App with the custom apex domain onionsupport.com stuck indefinitely in the Validating state.

The Static Web App itself is healthy. Its default *.azurestaticapps.net hostname returns HTTP 200 and TLS validation succeeds.

I deleted the previous custom-domain binding, confirmed it was fully removed, and then recreated it using DNS TXT token validation. Azure generated a new validation token and a new custom-domain resource.

The current custom-domain resource was created on:

2026-08-22T09:39:17Z

Current state:

status: Validating errorMessage: null

The required TXT record is configured at:

_dnsauth.www.onionsupport.com

DNS has been verified successfully from:

Cloudflare 1.1.1.1
Google 8.8.8.8
All four authoritative googledomains.com nameservers

All of them return the current Azure validation token. The previous DNS TTL was 14400 seconds (4 hours), and more than that period has already elapsed since the record was changed.

The domain also has no CAA records restricting certificate issuance.

I checked the Azure Activity Log for the current custom-domain creation operation. The operation:

Microsoft.Web/staticSites/customDomains/write

started at:

2026-08-22T09:39:16.7572954Z

and returned:

HTTP 202 Accepted

at:

2026-08-22T09:39:17.9917105Z

There has been no subsequent Succeeded or Failed event for this operation. The custom-domain resource continues to report Validating with no error message several hours later.

Correlation ID:

b3e91618-38f1-4567-8217-9e601f2ddde9

I also queried the custom-domain resource directly through the Azure Resource Manager REST API and it still reports status: Validating.

At this point DNS propagation, authoritative DNS configuration, CAA restrictions, and the health of the Static Web App itself appear to have been ruled out.

Could someone from the Azure Static Web Apps team please advise whether this provisioning operation is stuck on the service side, or whether there is another backend validation/certificate-provisioning step that can be checked?

I would prefer not to delete and recreate the custom-domain binding again, since that would generate another validation token and restart the process.

0 comments

Answer accepted by question author

TP 163K Volunteer Moderator

Hi,

I did quick check and right now you have conflicting TXT records. For @ you have _oycjt9otvay7f37sb3fxhjhxykiysxu and for _dnsauth.www you have _f1akgkxuy2o56zss2z9sdpzc9201m6m

What I recommend, in sequence:

delete both TXT records
add CAA record 0 issue "digitcert.com", to apex, TTL 3600
delete custom domain from your Static Web App. Yes, I want you to do this, despite your objection, because the validation polling interval slows dramatically over time, so we want to restart that.
wait 1 hour (for TTL to expire on the TXT records)
add custom domain back to your SWA, generate new code for TXT record, be ready to immediately create TXT record(s)
Quickly add TXT record with new code, with low TTL (e.g. 300 seconds)
refresh in portal every 5 minutes to see if validation is complete. If it doesn't complete within 15 minutes there is an issue, add comment below

Please reply back here with your results, whether positive or negative.

Above is 100% written by me, an actual human.

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP

Onion Support 20 Reputation points

2026-08-22T15:45:04.8166667+00:00

I checked the DNS records more closely. At the apex I have three legitimate TXT records (Microsoft 365 SPF, Google site verification and MS=...) plus _oycjt9otvay7f37sb3fxhjhxykiysxu, which appears to be an old Azure validation token. The current Static Web Apps token is at _dnsauth.www.onionsupport.com.

When you say “delete both TXT records”, do you mean only the Azure-looking _oycjt... TXT at the apex and the current _dnsauth.www TXT, leaving the SPF / Google / MS verification records untouched?

Also, _dnsauth.www currently has TTL 14400 (4 hours). Should I wait the full 4 hours after deleting it before creating a new binding/token, rather than the 1 hour suggested?

Finally, there are currently no CAA records at all. Since an absent CAA RRset does not restrict certificate issuance, do you still specifically recommend adding CAA 0 issue "digicert.com" as an Azure Static Web Apps workaround in this case?
TP 163K Reputation points Volunteer Moderator

2026-08-22T16:04:08+00:00
Yes, leave the other unrelated TXT records (SPF, Entra verification, Google verification). Only delete the _oycjt9otvay7f37sb3fxhjhxykiysxu and _f1akgkxuy2o56zss2z9sdpzc9201m6m TXT record

In regards to _dnsauth.www, sorry I didn't notice that was longer TTL. You can go ahead and try it without waiting for TTL to expire, just know that if it fails you might need to repeat the process. You could try waiting 1+ hour and see if you get lucky in terms of the other TTL.

When I write answers I normally ask people to wait for TTL to expire (even though in many cases it isn't necessary) because I'm trying to avoid the process failing and them thinking things are broken. Often people don't return to their thread to ask why. In your case since it is a bit longer TTL you are more likely to see an issue [if you don't wait], but still it isn't a certainty.

I've seen cases where it succeeds without CAA record being present, however, there have been people in the past where certificate wasn't issuing, I had them add CAA, repeat, and process worked fine. So strictly speaking you are correct, having no CAA shouldn't cause any problems.

In general I add CAA record. Use dig to verify it is correct with command similar to below:

dig onionsupport.com caa

Output similar to below:

;; ANSWER SECTION: onionsupport.com. 3600 IN CAA 0 issue "digicert.com"
Onion Support 20 Reputation points

2026-08-22T16:20:09.1+00:00

Thanks for the clarification.

I have now completed the cleanup as discussed:

Deleted only the old Azure-looking TXT at the apex (_oycjt...).

Deleted the current _dnsauth.www validation TXT.

Left the legitimate SPF, Microsoft (MS=...) and Google verification TXT records untouched.

Added CAA 0 issue "digicert.com".

I also added CAA 0 issue "letsencrypt.org" because the current certificate for the apex domain is issued by Let's Encrypt, while www.onionsupport.com is currently using a DigiCert certificate.

Both CAA records are already resolving correctly through 1.1.1.1 and 8.8.8.8.

Deleted the onionsupport.com custom-domain binding from the Static Web App.

Confirmed that the apex binding now returns NotFound.

Confirmed that www.onionsupport.com remains Ready and has not been touched.

Since the previous _dnsauth.www TXT had a TTL of 14400 seconds, I am going to wait the full 4 hours before recreating the apex binding and generating a fresh validation token. This should eliminate any possibility of the previous token remaining in resolver caches.

Unless you see an issue with this approach, I will recreate the binding after the full TTL has expired and report the result here.
TP 163K Reputation points Volunteer Moderator

2026-08-22T18:23:56.81+00:00
I did some tests to make sure there isn't another outage like on 11th-13th of this month, that affected add/delete custom domains. Results:

Apex domain, @ TXT record (portal instructions), validation completed in little over 10 minutes

Apex domain, _dnsauth TXT record, validation completed in little over 10 minutes

Apex domain, _dnsauth.www TXT record, validation did not complete after 20+ minutes waiting

For all above tests I did not have ALIAS record in place yet.

Despite what zero downtime migration documentation says, I recommend using @ TXT record or _dnsauth TXT record for apex. If unsure just go with putting token TXT record at @

Of course check that you only have one token TXT record, or if you have both @ and _dnsauth, make sure they both have same correct value
Onion Support 20 Reputation points

2026-08-22T21:46:32.33+00:00

Thanks — this solved it.

I followed your recommendation and the key difference was publishing the current validation token at the apex (@).

What happened:

With the token only at _dnsauth.www, the apex domain remained stuck in Validating.

The Azure portal itself showed Host: @ for the TXT validation record.

I published the same current token at @.

All four authoritative nameservers returned the correct token.

Shortly afterwards, the custom domain changed to Ready.

I then replaced the previous Squarespace apex forwarding/A records with an ALIAS @ pointing to the Static Web Apps default hostname.

onionsupport.com now resolves to Azure and returns HTTP 200 with a valid DigiCert certificate.

www.onionsupport.com remains Ready as well.

Final status:

onionsupport.com → Ready HTTPS → 200 TLS verification → successful Certificate issuer → DigiCert

So in this case, _dnsauth.www did not work for the apex validation, while placing the token at @ did.

Thanks again for taking the time to run those tests — that was exactly the clue we needed.
TP 163K Reputation points Volunteer Moderator

2026-08-22T22:05:00.61+00:00

You are welcome. Please click Accept Answer and upvote to close up this thread.

Thank you.

1 additional answer

Your answer

Onion Support 20 Reputation points

2026-08-22T15:45:04.8166667+00:00

I checked the DNS records more closely. At the apex I have three legitimate TXT records (Microsoft 365 SPF, Google site verification and MS=...) plus _oycjt9otvay7f37sb3fxhjhxykiysxu, which appears to be an old Azure validation token. The current Static Web Apps token is at _dnsauth.www.onionsupport.com.

When you say “delete both TXT records”, do you mean only the Azure-looking _oycjt... TXT at the apex and the current _dnsauth.www TXT, leaving the SPF / Google / MS verification records untouched?

Also, _dnsauth.www currently has TTL 14400 (4 hours). Should I wait the full 4 hours after deleting it before creating a new binding/token, rather than the 1 hour suggested?

Finally, there are currently no CAA records at all. Since an absent CAA RRset does not restrict certificate issuance, do you still specifically recommend adding CAA 0 issue "digicert.com" as an Azure Static Web Apps workaround in this case?
TP 163K Reputation points Volunteer Moderator

2026-08-22T16:04:08+00:00

Yes, leave the other unrelated TXT records (SPF, Entra verification, Google verification). Only delete the _oycjt9otvay7f37sb3fxhjhxykiysxu and _f1akgkxuy2o56zss2z9sdpzc9201m6m TXT record

In regards to _dnsauth.www, sorry I didn't notice that was longer TTL. You can go ahead and try it without waiting for TTL to expire, just know that if it fails you might need to repeat the process. You could try waiting 1+ hour and see if you get lucky in terms of the other TTL.

When I write answers I normally ask people to wait for TTL to expire (even though in many cases it isn't necessary) because I'm trying to avoid the process failing and them thinking things are broken. Often people don't return to their thread to ask why. In your case since it is a bit longer TTL you are more likely to see an issue [if you don't wait], but still it isn't a certainty.

I've seen cases where it succeeds without CAA record being present, however, there have been people in the past where certificate wasn't issuing, I had them add CAA, repeat, and process worked fine. So strictly speaking you are correct, having no CAA shouldn't cause any problems.

In general I add CAA record. Use dig to verify it is correct with command similar to below:

dig onionsupport.com caa

Output similar to below:

;; ANSWER SECTION: onionsupport.com. 3600 IN CAA 0 issue "digicert.com"
Onion Support 20 Reputation points

2026-08-22T16:20:09.1+00:00

Thanks for the clarification.

I have now completed the cleanup as discussed:

Deleted only the old Azure-looking TXT at the apex (_oycjt...).

Deleted the current _dnsauth.www validation TXT.

Left the legitimate SPF, Microsoft (MS=...) and Google verification TXT records untouched.

Added CAA 0 issue "digicert.com".

I also added CAA 0 issue "letsencrypt.org" because the current certificate for the apex domain is issued by Let's Encrypt, while www.onionsupport.com is currently using a DigiCert certificate.

Both CAA records are already resolving correctly through 1.1.1.1 and 8.8.8.8.

Deleted the onionsupport.com custom-domain binding from the Static Web App.

Confirmed that the apex binding now returns NotFound.

Confirmed that www.onionsupport.com remains Ready and has not been touched.

Since the previous _dnsauth.www TXT had a TTL of 14400 seconds, I am going to wait the full 4 hours before recreating the apex binding and generating a fresh validation token. This should eliminate any possibility of the previous token remaining in resolver caches.

Unless you see an issue with this approach, I will recreate the binding after the full TTL has expired and report the result here.
TP 163K Reputation points Volunteer Moderator

2026-08-22T18:23:56.81+00:00

I did some tests to make sure there isn't another outage like on 11th-13th of this month, that affected add/delete custom domains. Results:

Apex domain, @ TXT record (portal instructions), validation completed in little over 10 minutes

Apex domain, _dnsauth TXT record, validation completed in little over 10 minutes

Apex domain, _dnsauth.www TXT record, validation did not complete after 20+ minutes waiting

For all above tests I did not have ALIAS record in place yet.

Despite what zero downtime migration documentation says, I recommend using @ TXT record or _dnsauth TXT record for apex. If unsure just go with putting token TXT record at @

Of course check that you only have one token TXT record, or if you have both @ and _dnsauth, make sure they both have same correct value
Onion Support 20 Reputation points

2026-08-22T21:46:32.33+00:00

Thanks — this solved it.

I followed your recommendation and the key difference was publishing the current validation token at the apex (@).

What happened:

With the token only at _dnsauth.www, the apex domain remained stuck in Validating.

The Azure portal itself showed Host: @ for the TXT validation record.

I published the same current token at @.

All four authoritative nameservers returned the correct token.

Shortly afterwards, the custom domain changed to Ready.

I then replaced the previous Squarespace apex forwarding/A records with an ALIAS @ pointing to the Static Web Apps default hostname.

onionsupport.com now resolves to Azure and returns HTTP 200 with a valid DigiCert certificate.

www.onionsupport.com remains Ready as well.

Final status:

onionsupport.com → Ready HTTPS → 200 TLS verification → successful Certificate issuer → DigiCert

So in this case, _dnsauth.www did not work for the apex validation, while placing the token at @ did.

Thanks again for taking the time to run those tests — that was exactly the clue we needed.
TP 163K Reputation points Volunteer Moderator

2026-08-22T22:05:00.61+00:00

You are welcome. Please click Accept Answer and upvote to close up this thread.

Thank you.

Answer 1

I did a quick check and you currently have two conflicting TXT records: one at @ (_oycjt9otvay7f37sb3fxhjhxykiysxu) and one at _dnsauth.www (_f1akgkxuy2o56zss2z9sdpzc9201m6m).

For an apex domain, Static Web Apps only reads the token at _dnsauth.www.onionsupport.com — the @ record is a leftover from the earlier binding. That stale record, plus the fact that Azure's validation polling backs off progressively the longer a binding sits in Validating, is why this one will not clear on its own. That is also why I am asking you to delete and recreate the binding despite your objection: it resets the polling interval.

Please do this in sequence:

Delete BOTH TXT records (the one at @ and the one at _dnsauth.www).
Add a CAA record at the apex, TTL 3600: 0 issue "digicert.com"
Delete the custom domain from your Static Web App. az staticwebapp hostname delete --name --resource-group --hostname onionsupport.com
Wait 1 hour so the old TXT records age out of resolver caches. Verify nothing is cached before continuing: dig +short TXT onionsupport.com @8.8.8.8 dig +short TXT _dnsauth.www.onionsupport.com @8.8.8.8 Both should return nothing.
Add the custom domain back, generate the new code, and have your DNS provider console already open so you can create the record immediately. az staticwebapp hostname set --name --resource-group --hostname onionsupport.com --validation-method dns-txt-token --no-wait az staticwebapp hostname show --name --resource-group --hostname onionsupport.com --query validationToken -o tsv
Immediately create ONE TXT record with the new code, TTL 300: Host: _dnsauth.www Type: TXT Value: TTL: 300 Confirm it is live: dig +short TXT _dnsauth.www.onionsupport.com @1.1.1.1
Refresh the portal every 5 minutes. Check status with: az staticwebapp hostname show --name --resource-group --hostname onionsupport.com --query "{status:status,error:errorMessage}" If it has not reached Ready within 15 minutes, comment back here with the status output, the new token, and the time you created the TXT record.

Please reply here with your results.

Thanks