How to Fix Azure Front Door Wildcard Domain Revalidation Failure: Step-by-Step Guide

All wildcard-mapped sites are down. Nothing changed in the configuration. The Azure DNS zone looks correct. Yet the domain state shows Pending Revalidation or Rejected. Here is exactly what is happening, why it is happening, and the step-by-step procedure to bring everything back up.

Aug 2025

DigiCert deprecated CNAME-based DCV — the root cause of this entire class of failures

45 days

Before cert expiry — when AFD enters Pending Revalidation and the auto-rotation begins trying

7 days

TXT record token validity window — after this it expires and the exact value must be regenerated

~30min

Time to resolve once the correct TXT token is in DNS and the Revalidate button is triggered

⚠ Root Cause — Industry Change, Not Your Configuration

This is not a misconfiguration on your part. On 15 August 2025, DigiCert deprecated the legacy CNAME-based Domain Control Validation (DCV) workflow as part of an industry-wide migration to Multi-Perspective Issuance Corroboration (MPIC) requirements. Azure Front Door managed certificates for wildcard domains historically used CNAME-based validation. After August 2025, wildcard certificate renewals can only proceed via DNS TXT record validation. Your existing TXT record may still look correct in Azure DNS — but the underlying validation token has expired internally on Microsoft's side, making the old value no longer accepted by DigiCert's new validation platform.

The fix is not to check your DNS configuration more carefully. The fix is to regenerate the validation token in the Azure portal, get the new value, update the DNS TXT record with that new value, and trigger revalidation.

Figure 1 — What changed and why your wildcard domains are failing now even though your DNS looks correct

The old TXT record value in your DNS is no longer accepted by DigiCert's new validation platform — you need the new token from the Azure portal, not a check of the old DNS record

Understand the Domain States

Domain Validation States — What Each One Means

Before starting the fix, confirm which state your wildcard domain is showing in the Azure Front Door portal. The state determines which recovery path to take.

State	What It Means	What To Do
Approved	Domain ownership verified. Certificate active. All is well.	Nothing — this is the target state you are working toward.
Pending	Domain was just added; AFD is waiting for the initial TXT record to appear in DNS.	Add the _dnsauth TXT record with the value shown in the portal.
Pending Revalidation	Certificate approaching expiry (within 45 days). Auto-rotation attempted and failed. Existing TXT token expired or not accepted. This is the state most people in this incident are seeing.	Click Regenerate to get a new token. Update DNS TXT record with the new value. Click Revalidate. Wait ~30 minutes.
Rejected	DigiCert has rejected the certificate reissuance request. Validation failed after the retry window. Certificate may have already expired.	Regenerate token. Update DNS. Click Revalidate. If still rejected after 30 minutes, delete and re-add the domain in AFD, then follow the full validation flow from scratch.
Internal Error	A platform-side issue on Microsoft's infrastructure prevented validation from completing.	Click Revalidate. If no improvement in 1 hour, open a P1 support ticket with Microsoft — this requires backend investigation.

Figure 2 — How Azure Front Door wildcard domain validation works end-to-end

DigiCert makes a real-time DNS query for the _dnsauth TXT record and compares it against the expected token. If the token was issued weeks or months ago, it is no longer valid even if the record is still in DNS.

The Immediate Fix

Immediate Resolution — Do This Now

The Fix: Regenerate Token → Update DNS → Revalidate

This is the fastest path to getting your wildcard sites back up. Work through these steps in order. The entire procedure takes under 30 minutes once the new TXT record is in DNS.

1

Azure Portal → Front Door & CDN Profiles → [Your Profile] → Domains

Open your Front Door profile and locate the wildcard domain

Sign in to the Azure portal. Navigate to Front Door and CDN Profiles. Open your Front Door Standard or Premium profile. In the left navigation, select Domains. Locate your wildcard domain (e.g. *.example.com). The Validation state column will show Pending revalidation or Rejected. Click on the domain row to open the domain details pane.

2

Domain details pane → Validation state → Click "Pending revalidation" link → Regenerate

Regenerate the validation token — this is the critical step

In the domain details pane, click the Validation state link (it will say "Pending revalidation" or show a warning icon). A panel opens titled Validate custom domain ownership. You will see the current expected TXT record information. Look for the Regenerate button and click it. This generates a brand-new validation token on Microsoft's side and syncs it with DigiCert's validation platform. The old token — even if it is still in your DNS — is now invalidated. You must update your DNS with this new value.

If you do not see a Regenerate button, look for a Revalidate button instead. In some portal versions the Revalidate button both regenerates and triggers validation simultaneously. If neither button is visible, proceed to the CLI/PowerShell method in the alternative steps below.

3

Copy the new TXT record name and value — exactly as shown

After regenerating, the portal displays the TXT record details. Copy both values precisely:

Record name: _dnsauth (for a wildcard domain *.example.com, the full record name is _dnsauth.example.com)

Record value: A long alphanumeric string — for example 0000000000000000000000000000000000000000000000000000000000000000. This is unique and time-sensitive. Do not use the old value from your DNS. Do not approximate or retype — copy it exactly from the portal.

The token expires after 7 days. If you do not update DNS and complete revalidation within 7 days of clicking Regenerate, you will need to regenerate again.

4

Azure Portal → DNS Zones → [yourdomain.com] → TXT Recordsets → _dnsauth

Update the _dnsauth TXT record in your Azure DNS Zone with the new value

Navigate to DNS Zones in the Azure portal. Open your domain's DNS zone (e.g. example.com). Find the existing TXT record named _dnsauth. Click it to open the record. Delete the old value entirely and replace it with the new token value you copied in Step 3. Click Save.

If you are using a non-Azure DNS provider, log into your DNS provider's management interface and update the _dnsauth.yourdomain.com TXT record value there instead. The record type is TXT, the TTL should be 3600 (1 hour) or less, and the value is the new token string.

5

Verify the new TXT record is publicly resolving before triggering revalidation

Before clicking Revalidate, confirm the updated TXT record is resolving from public DNS — not just from your local network. Use one of these methods:

Verify DNS propagation — run from Command Prompt, PowerShell, or Azure Cloud Shell# Windows — nslookup nslookup -type=TXT _dnsauth.example.com 8.8.8.8
# Replace example.com with your actual domain. 8.8.8.8 = Google DNS (public resolver)

# macOS / Linux — dig dig +short TXT _dnsauth.example.com @8.8.8.8

# Azure Cloud Shell — resolve-dnsname Resolve-DnsName -Name _dnsauth.example.com -Type TXT -Server 8.8.8.8

# Expected output: the new token value from the Azure portal # If the old value appears, DNS has not yet propagated — wait 5-10 minutes and retry # If empty, the record update has not saved correctly — go back and check Step 4

6

Back in Domain pane → Validation state → Revalidate

Trigger revalidation in the portal once DNS is confirmed propagated

Return to your Front Door profile → Domains → click the wildcard domain. In the domain details pane, click Revalidate (or click the Validation state link and then Revalidate). This tells Azure Front Door to immediately attempt domain ownership validation using the new TXT record. Azure passes the check to DigiCert, which queries _dnsauth.example.com from multiple geographic vantage points (MPIC), finds the new token value, and approves the validation.

The validation state should change from Pending revalidation to Approved within 10–30 minutes. After approval, Azure Front Door initiates certificate issuance. Certificate propagation to all edge locations takes a further 5–30 minutes. Your wildcard sites will come back online as the certificate propagates.

7

Verify domain is Approved and certificate is active

Navigate back to Domains in your Front Door profile. Confirm the wildcard domain shows Approved in the Validation state column and Provisioned in the Certificate state column. Test one of your affected wildcard sites by opening it in a browser and checking the padlock icon — the certificate should show as valid and issued to *.example.com. If you see "Certificate error" or "Not secure", wait a further 10–15 minutes for edge propagation and test again from a different browser or device (to avoid local certificate cache).

Alternative — CLI and PowerShell

Alternative Method — Azure CLI and PowerShell

Triggering Revalidation via CLI or PowerShell

If the Revalidate button is not visible in the portal, or you need to automate this across multiple domains, use the Azure CLI or PowerShell to trigger domain validation via an empty PATCH request to the domain API.

Azure CLI — Trigger domain revalidation via empty PATCH request# Replace variables with your actual values SUBSCRIPTION="your-subscription-id"
RESOURCE_GROUP="your-resource-group"
PROFILE_NAME="your-frontdoor-profile-name"
DOMAIN_NAME="example.com" # For wildcard *.example.com use: example.com

# Trigger revalidation — empty PATCH request to the custom domain resource az rest \
  --method PATCH \
  --url "https://management.azure.com/subscriptions/${SUBSCRIPTION}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Cdn/profiles/${PROFILE_NAME}/customDomains/${DOMAIN_NAME}?api-version=2023-05-01" \
  --body "{}" \
  --headers "Content-Type=application/json"

# Check domain validation state after triggering az afd custom-domain show \
  --resource-group $RESOURCE_GROUP \
  --profile-name $PROFILE_NAME \
  --custom-domain-name $DOMAIN_NAME \
  --query "{ValidationState:domainValidationState, CertState:tlsSettings.certificateType}" \
  --output table

PowerShell — Update _dnsauth TXT record in Azure DNS Zone with new token# Run in Azure Cloud Shell or local PowerShell with Az module installed $resourceGroup = "your-dns-resource-group"
$zoneName = "example.com"
$newTokenValue = "paste-the-new-token-from-azure-portal-here"

# Remove the old TXT record set Remove-AzDnsRecordSet -RecordType TXT -Name "_dnsauth" -ZoneName $zoneName -ResourceGroupName $resourceGroup

# Create a new TXT record set with the new token value $records = @()
$records += New-AzDnsRecordConfig -Value $newTokenValue
New-AzDnsRecordSet -RecordType TXT -Name "_dnsauth" -ZoneName $zoneName `
  -ResourceGroupName $resourceGroup -Ttl 3600 -DnsRecords $records

# Verify the record was set correctly Resolve-DnsName -Name "_dnsauth.$zoneName" -Type TXT -Server 8.8.8.8

If Still Failing After Revalidation

Escalation Steps — If Revalidation Does Not Clear Within 1 Hour

In most cases, Regenerate → Update DNS → Revalidate resolves the issue within 30 minutes. If the domain is still in Pending Revalidation or Rejected state after 1 hour, and you have confirmed the DNS TXT record is resolving with the correct new value, escalate through these steps in order.

Option A: Delete and Re-Add the Wildcard Domain

This is a disruptive but effective reset. Removing and re-adding the domain generates a completely fresh validation state and a new token. The domain will be unassociated from its routes temporarily during the process — if your sites are already down, the downtime impact is the same.

1

Note all current route associations before deleting

Before removing the domain, go to Front Door Manager → Endpoints and record which routes are associated with *.example.com. You will need to re-associate them after re-adding the domain. Take a screenshot or note down: endpoint name, route name, origin group, and path patterns.

2

Domains → *.example.com → Disassociate from routes → Then Delete

Disassociate the domain from all routes, then delete it

In the Domains list, click the wildcard domain. If it shows any associated routes, click Disassociate for each one. Once all routes are disassociated, click Delete to remove the domain from the Front Door profile. Confirm the deletion when prompted.

3

Domains → Add domain → Enter *.example.com again

Re-add the wildcard domain and get the fresh token

Click Add in the Domains pane. Enter your wildcard domain (e.g. *.example.com). Select Azure managed certificate. After saving, a new validation token is generated. Copy this fresh token, update your DNS TXT record (_dnsauth.example.com) with this new value, and wait for DNS propagation. Once the TXT record is resolving with the new value, the domain validation should automatically proceed to Approved within a few minutes.

4

Re-associate routes and verify HTTPS

Once the domain shows Approved, re-associate it with the routes you noted in Step 1. Select the domain → click Associate endpoint and routes → select the appropriate endpoint and route(s). After association, allow 5–15 minutes for the certificate to propagate and test your wildcard sites.

⚠ Interim Fix — Switch to BYOC While Resolving

If the regeneration approach is taking too long and you have an existing wildcard certificate from another CA (Let's Encrypt, ZeroSSL, your own PKI), you can switch the affected domain to Bring Your Own Certificate (BYOC) as a temporary measure to restore HTTPS while the managed certificate revalidation is resolved.

In the domain's TLS settings in the Azure portal, switch from AFD Managed to Bring Your Own Certificate, select or upload your certificate from Azure Key Vault, and associate it. Sites should recover immediately after the certificate propagates. You can switch back to AFD managed certificate once the revalidation issue is fully resolved.

Figure 3 — Troubleshooting decision tree: which action to take based on your current domain state

Always verify DNS is resolving the new token value before clicking Revalidate — triggering revalidation before DNS propagates will fail and reset the retry window

Prevent It Happening Again

Prevention

How to Prevent This Recurring — and the Permanent Fix for Wildcard Domains

Once you have resolved the immediate outage, you need to address the underlying situation. Azure Front Door managed certificates are not available for wildcard domains — this is by design, and the auto-revalidation issue is a consequence of using managed certificate renewal patterns that were designed for non-wildcard domains. Wildcard domains require either TXT-record-based validation (which you have just done) or switching to BYOC.

Option 1 — Keep AFD Managed Certificate with Alerts (Minimum Action)

The managed certificate will need TXT record revalidation again in the future — approximately every 45–90 days as certificates are renewed. Set up an Azure Monitor alert on your Front Door profile to notify you the moment any domain enters Pending Revalidation state, giving you days to act before certificates expire. Use the Azure Activity Log alert for the specific operation that changes domain validation state.

Azure CLI — Create an alert when any domain enters Pending Revalidation state# Alert on Front Door domain validation state changes # Sends an email when domain validation state changes to PendingRevalidation or Rejected az monitor activity-log alert create \
  --name "AFD-Domain-Revalidation-Alert" \
  --resource-group "your-resource-group" \
  --scope "/subscriptions/your-subscription-id/resourceGroups/your-rg/providers/Microsoft.Cdn/profiles/your-afd-profile" \
  --condition "category=Administrative and operationName=Microsoft.Cdn/profiles/customDomains/write" \
  --action-group "/subscriptions/your-subscription-id/resourceGroups/your-rg/providers/microsoft.insights/actionGroups/your-action-group" \
  --description "Alert when AFD custom domain validation state changes — check portal for Pending Revalidation"

Option 2 — Switch to BYOC (Recommended for Wildcard Domains)

The cleanest long-term solution for wildcard domains on Azure Front Door is Bring Your Own Certificate (BYOC). You manage the certificate lifecycle through your own CA or Let's Encrypt, upload it to Azure Key Vault, and Azure Front Door uses it directly. You control the renewal cadence, the CA, and the validation method. Certificate rotation in BYOC does not require domain revalidation through DigiCert's platform at all.

For wildcard certificates using Let's Encrypt (free), the certificate can be issued via DNS-01 challenge (adding a TXT record to your DNS zone) using any ACME client. The certificate has a 90-day lifetime with automated renewal. Upload the renewed certificate to Azure Key Vault and Azure Front Door will automatically detect and use the new version without any portal intervention.

Option 3 — Add a CAA Record to Speed Up Future Renewals

Azure Front Door certificates are issued by DigiCert. Some domain owners have strict CAA (Certification Authority Authorization) policies that do not explicitly allow DigiCert. If your DNS zone has a CAA record that does not list DigiCert, the certificate issuance will be blocked regardless of TXT record validation. Add the following CAA record to your DNS zone to pre-authorise DigiCert:

Azure CLI — Add DigiCert CAA record to your DNS zone# Add CAA record authorising DigiCert to issue certificates for *.example.com az network dns record-set caa add-record \
  --resource-group "your-dns-resource-group" \
  --zone-name "example.com" \
  --record-set-name "@" \
  --flags 0 \
  --tag "issue" \
  --value "digicert.com"

# Verify the CAA record was created az network dns record-set caa list --resource-group "your-dns-resource-group" --zone-name "example.com"

Key Takeaways

✓This is not a misconfiguration — DigiCert deprecated CNAME-based Domain Control Validation on 15 August 2025. Wildcard certificate renewals now require TXT-record-based validation. Your existing DNS may look correct but the token value is stale.

✓The immediate fix is: click Regenerate in the Validate custom domain ownership pane, copy the new token, update the _dnsauth.yourdomain.com TXT record with the new value, verify DNS propagation, then click Revalidate.

✓Do not use the old TXT record value. It is internally expired even if it looks correct in your DNS zone. Always get a fresh token by clicking Regenerate first.

✓The new token expires after 7 days. If you do not complete DNS update and revalidation within 7 days of clicking Regenerate, you must regenerate again.

✓Always verify DNS propagation (nslookup or dig against 8.8.8.8) before clicking Revalidate. Triggering revalidation before the new TXT record is publicly visible will fail.

✓If Revalidate fails or the domain shows Internal Error, delete and re-add the wildcard domain in the Front Door profile. This generates a completely fresh validation state.

✓For a permanent fix: switch wildcard domains to BYOC (Bring Your Own Certificate) stored in Azure Key Vault. This removes the dependency on DigiCert's validation platform entirely.

✓Add a DigiCert CAA record (0 issue digicert.com) to your DNS zone to ensure future certificate issuance is not blocked by a restrictive CAA policy.

Frequently Asked Questions

Why did this happen now if I have not changed anything in my configuration?

The Azure Front Door certificate for your wildcard domain reached its renewal window (45 days before expiry), and AFD attempted auto-rotation as it normally does. However, the underlying validation mechanism changed — DigiCert deprecated CNAME-based DCV on 15 August 2025 and migrated to a new platform requiring TXT-based validation with MPIC (Multi-Perspective Issuance Corroboration). The existing TXT record token in your DNS was issued before this platform migration and is no longer accepted by DigiCert's new system. Your configuration has not changed, but the validation platform it depends on has.

My Azure DNS zone shows the _dnsauth TXT record is there — why is validation still failing?

The record is there but the value is stale. Azure Front Door generates a new token each time it initiates a renewal cycle. If the token in your DNS is from the previous validation round (weeks or months ago), DigiCert's validation system will not accept it — the token is time-bound and single-use. The fix is not to verify the record exists; it is to regenerate the token in the portal and replace the record value with the new token. The Regenerate button in the "Validate custom domain ownership" pane is what generates the token that DigiCert's system will currently accept.

Does Azure Front Door actually support managed certificates for wildcard domains?

As of 2026, Azure Front Door Standard/Premium does not provide managed certificates for wildcard domains in the same fully automated way it does for non-wildcard custom domains. For wildcard domains, you either manage the TXT validation record manually during each renewal cycle, or you use BYOC (Bring Your Own Certificate). This is a key architectural consideration: if you have many wildcard domains and want fully automated renewal without manual intervention, BYOC with an automated certificate management system (ACME/Let's Encrypt) is the correct long-term solution.

How long will my sites be down during the fix?

If the existing certificate has not yet expired (only in Pending Revalidation state), your sites remain up on the existing certificate while you work through the fix — the downtime is zero. If the certificate has already expired (domain shows Rejected and cert has passed its expiry date), sites will be down from the moment of expiry until the new certificate is issued and propagated. Once you complete the Regenerate → DNS update → Revalidate steps and the domain reaches Approved state, certificate propagation to all AFD edge locations takes 5–30 minutes. Having an BYOC certificate ready to deploy as an interim fix can restore service immediately while the managed certificate revalidation is resolved.

Will this keep happening every certificate renewal cycle?

Yes, if you continue using AFD managed certificates for wildcard domains. Each certificate renewal (typically every 90 days, triggered ~45 days before expiry) will require a fresh TXT record validation. Azure Front Door does send notifications when domains enter Pending Revalidation state — ensure you have email alerts configured for your subscription and Azure Monitor alerts on your Front Door profile. The permanent solution that eliminates this manual step is to switch to BYOC with an automated renewal system. Let's Encrypt with an ACME client and Key Vault integration provides free, automated wildcard certificate management that eliminates the AFD managed certificate renewal dependency.

Can I use a single _dnsauth TXT record for all wildcard subdomains on the same domain?

For a wildcard domain *.example.com, one _dnsauth.example.com TXT record covers the entire wildcard. You do not need separate TXT records for each subdomain under the wildcard. However, if you have added specific subdomains (like app.example.com or api.example.com) as separate custom domain entries in Front Door alongside the wildcard, each explicit subdomain entry may need its own validation. In practice, subdomains covered by a validated wildcard in AFD typically inherit the wildcard's validation — but if a specific subdomain shows Pending on its own, add a _dnsauth.app.example.com TXT record for that specific subdomain as well.

FAVORITE Azure Engineering, AI & Real-World Fixes

Search This Blog