Azure App Service custom domain verification fails even though DNS is correctly configured and publicly resolvable

Ashley Thomas 20 Reputation points
2026-09-28T18:14:03.77+00:00

Azure App Service custom domain verification fails even though DNS is correctly configured and publicly resolvable

I am trying to add workspace.peaco.tech as a custom domain to an Azure App Service.

App Service:

  • App name: peaco-frontend

Resource group: peaco-dev

Platform: Linux Web App

Existing custom domain:

portal.peaco.tech is already working correctly on the same App Service.

DNS configuration for the new hostname:

workspace.peaco.tech CNAME → peaco-frontend-ecdkepg4dvdse2fj.centralus-01.azurewebsites.net

asuid.workspace.peaco.tech TXT → current Azure App Service Custom Domain Verification ID

I verified the records from Azure Cloud Shell:

dig +short workspace.peaco.tech CNAME returns the expected Azure App Service hostname.

dig +short asuid.workspace.peaco.tech TXT returns the correct verification ID.

I also queried both authoritative Bluehost nameservers directly:

ns1.bluehost.com

  `ns2.bluehost.com`

Both authoritative nameservers return the correct CNAME and TXT values.

Despite this, domain verification fails in all of the following:

Azure Portal custom-domain wizard

az webapp config hostname add

direct ARM/REST hostname binding

App Service “All Certificates & Domains Checks” diagnostic

The error is consistently:

A TXT record pointing from asuid.workspace.peaco.tech to <verification-id> was not found.

However, the TXT record is publicly resolvable and matches the current Custom Domain Verification ID.

The App Service diagnostic also reports ownership verification failure, and its “Current DNS Configuration” field displays an internal .NET AsyncTask object rather than actual DNS data.

Is there a known App Service custom-domain verification caching or backend issue that could cause Azure to fail validation even when the authoritative DNS records are correct?

I would appreciate any guidance on how to force Azure to re-check or refresh domain ownership verification.Azure App Service custom domain verification fails even though DNS is correctly configured and publicly resolvable

I am trying to add workspace.peaco.tech as a custom domain to an Azure App Service.

App Service:

App name: peaco-frontend

Resource group: peaco-dev

Platform: Linux Web App

Existing custom domain:

portal.peaco.tech is already working correctly on the same App Service.

DNS configuration for the new hostname:

workspace.peaco.tech
CNAME → peaco-frontend-ecdkepg4dvdse2fj.centralus-01.azurewebsites.net

asuid.workspace.peaco.tech
TXT → current Azure App Service Custom Domain Verification ID

I verified the records from Azure Cloud Shell:

dig +short workspace.peaco.tech CNAME returns the expected Azure App Service hostname.

dig +short asuid.workspace.peaco.tech TXT returns the correct verification ID.

I also queried both authoritative Bluehost nameservers directly:

ns1.bluehost.com

  `ns2.bluehost.com`

Both authoritative nameservers return the correct CNAME and TXT values.

Despite this, domain verification fails in all of the following:

Azure Portal custom-domain wizard

az webapp config hostname add

direct ARM/REST hostname binding

App Service “All Certificates & Domains Checks” diagnostic

The error is consistently:

A TXT record pointing from asuid.workspace.peaco.tech to <verification-id> was not found.

However, the TXT record is publicly resolvable and matches the current Custom Domain Verification ID.

The App Service diagnostic also reports ownership verification failure, and its “Current DNS Configuration” field displays an internal .NET AsyncTask object rather than actual DNS data.

Is there a known App Service custom-domain verification caching or backend issue that could cause Azure to fail validation even when the authoritative DNS records are correct?

I would appreciate any guidance on how to force Azure to re-check or refresh domain ownership verification.

Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

0 comments
Answer accepted by question author
TP 163.9K Reputation points Volunteer Moderator
2026-09-28T20:37:11.9466667+00:00

Hi Ashley,

There is a typo in your TXT record for asuid.workspace.peaco.tech. Please delete the existing asuid.workspace.peaco.tech TXT record and then create a new one with the correct Custom Domain Verification ID, and set the TTL low (e.g. 300 or 600 seconds).

User's image

Since your current TTL is 4 hours, you may have to wait several hours before it will work. You can try it after you re-create the asuid TXT record, just keep in mind if it fails it is likely due to the old TXT record being cached.

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

Thanks.

-TP

Was this answer helpful?

2 people found this answer helpful.

1 additional answer

Sort by: Newest
Most helpful Newest Oldest

  1. AI answer

    2026-09-28T18:14:23.51+00:00

    Yes. Azure validation can lag behind publicly visible DNS, and the documented guidance is to retry validation after waiting for propagation and cache clearing.

    For this App Service scenario, the supported troubleshooting path is:

    1. In Azure portal go to App Service > Custom domains > Add custom domain.
    2. Enter workspace.peaco.tech and select Validate.
    3. If Azure still reports A TXT record pointing from asuid.workspace.peaco.tech ... was not found, recheck these exact items:
      • workspace.peaco.tech is a CNAME to the App Service hostname.
      • asuid.workspace.peaco.tech is a TXT record with the current App Service verification token.
      • No typo exists in the hostname, TXT name, or TXT value.
      • No conflicting DNS records exist for the same name.
    4. Wait and retry validation. DNS propagation can take up to 48 hours worldwide depending on TTL and provider behavior.
    5. Flush local DNS cache on Windows with ipconfig /flushdns, or test from a different network to avoid cached results.
    6. Select Validate again a few times after each wait period. The guidance explicitly notes that Azure portal can take time to reflect new DNS changes.
    7. Run Diagnose and Solve Problems > SSL and Domains > Run All Certificates & Domains Checks to detect common misconfigurations.

    Important supported interpretation of the symptom:

    • When the TXT and CNAME are publicly resolvable but Azure still says the TXT record was not found, one documented cause is propagation or caching delay.
    • In rare cases, the Azure validation service itself can lag; the documented action is to retry after a few minutes.
    • There is no documented self-service method to force an immediate backend refresh beyond revalidating after propagation and cache clearing.

    Also verify these prerequisites because they can block hostname addition even when DNS is correct:

    • The app is on Basic (B1) or higher.
    • The account has Owner or Contributor access on the web app subscription or resource.
    • The hostname is not already linked to another Azure resource.
    • No ReadOnly resource lock exists on the App Service or related domain resource.

    If the hostname is reported as Already in use or linked elsewhere, the documented resolution is to remove it from the other resource first. If that older resource is inaccessible, Azure support must release the domain binding.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.