Wildcard certificates from Let's Encrypt require DNS-01 validation, which means more moving parts and more places for things to break. The error messages are often vague, and propagation delays make debugging feel like guesswork. I've walked hundreds of customers through these failures, and the same seven issues account for nearly all of them.
Error 1: DNS validation failed — TXT record not found
Symptoms
Certbot or your ACME client reports DNS problem: query timed out looking up TXT for _acme-challenge.example.com or No TXT record found. The certificate issuance stops immediately.
Root cause
The ACME server queries your authoritative nameservers for the _acme-challenge TXT record and gets nothing back. Either the record was never created, it was created in the wrong zone, or your DNS provider hasn't published it yet.
Fix
First, confirm the record exists where you think it does. Log into your DNS control panel and look for _acme-challenge.yourdomain.com with type TXT. If you're using a subdomain wildcard like *.app.example.com, the challenge record must be _acme-challenge.app.example.com, not at the root.
Query the record yourself before retrying:
dig +short TXT _acme-challenge.example.com
If dig returns nothing, the record isn't live. Wait two minutes and check again—most managed DNS panels apply changes within 60 to 120 seconds. If it's still missing after five minutes, double-check the hostname and zone. A common mistake is creating _acme-challenge in a subdomain zone when your wildcard is at the root, or vice versa.
If you're using Cloudflare, turn off the proxy (gray cloud) for the _acme-challenge record. Let's Encrypt needs to see your authoritative nameservers directly.
Error 2: Rate limit exceeded
Symptoms
The client returns too many certificates already issued for exact set of domains or too many failed authorizations recently. You can't request a new certificate even though the DNS record is correct.
Root cause
Let's Encrypt enforces rate limits to prevent abuse: 50 certificates per registered domain per week, and five failed validation attempts per account per hostname per hour. Retrying a broken setup repeatedly will lock you out.
Fix
Check your current rate limit status by reviewing recent issuance at crt.sh—search for your domain and count certificates issued in the last seven days. If you've hit 50, you're done until the oldest one ages out.
For failed validation limits, wait one hour before retrying. Use the staging environment to test fixes without burning production quota:
certbot certonly --manual --preferred-challenges dns \
--server https://acme-staging-v02.api.letsencrypt.org/directory \
-d '*.example.com' -d example.com
Staging certificates won't be trusted by browsers, but they'll tell you if your DNS automation works. Once staging succeeds, switch back to the production endpoint.
If you've legitimately exhausted the 50-certificate limit because you're reissuing for multiple subdomains, consolidate them into fewer certificates. A single wildcard plus the apex (*.example.com and example.com) covers everything.
Error 3: TXT record found but validation still fails
Symptoms
You can see the _acme-challenge TXT record with dig, but Let's Encrypt reports Incorrect TXT record or Challenge validation failed.
Root cause
The record exists but the content doesn't match what the ACME server expects. This happens when you copy the token incorrectly, update the wrong record, or leave an old token in place from a previous attempt.
Fix
Compare the TXT record value in your DNS panel to the token your ACME client printed. They must match exactly—no extra quotes, no whitespace, no truncation. Some DNS panels automatically wrap TXT values in quotes; others require you to add them. Let's Encrypt expects the raw token string.
If you ran the challenge multiple times, you might have multiple TXT records for the same hostname. Delete all of them and create a fresh one with the current token. Use dig to confirm only one record comes back:
dig +short TXT _acme-challenge.example.com
If you see two or more lines, your DNS zone has duplicates. Most ACME servers will pick one at random, and if they pick the stale token, validation fails.
Another edge case: if your DNS provider lowercases or normalizes TXT records, the token might be altered. The token is case-sensitive. Switch to a provider that preserves the exact string.
Error 4: CAA records blocking issuance
Symptoms
Validation succeeds, but the final certificate request returns CAA record for example.com prevents issuance or CAA check failed.
Root cause
Certification Authority Authorization (CAA) records in your DNS zone explicitly list which CAs are allowed to issue certificates for your domain. If the list doesn't include letsencrypt.org, Let's Encrypt will refuse to issue.
Fix
Query your CAA records:
dig +short CAA example.com
If you see 0 issue "somethingelse.com" and no mention of letsencrypt.org, add a new CAA record:
example.com. CAA 0 issue "letsencrypt.org"
If you want to allow both Let's Encrypt and another CA, add multiple CAA records—one per CA. If you want to allow wildcard issuance specifically, also add:
example.com. CAA 0 issuewild "letsencrypt.org"
Some zones inherit CAA records from a parent domain. If dig CAA subdomain.example.com returns nothing but dig CAA example.com returns a restrictive policy, the parent policy applies. You'll need to add the record at the parent level or override it at the subdomain.
If you don't need CAA records at all, delete them. No CAA records means any CA can issue, which is the default behavior.
Error 5: DNS propagation delay
Symptoms
The ACME client creates the TXT record, waits a few seconds, and immediately tries validation. Let's Encrypt's servers don't see the record yet and the challenge fails.
Root cause
DNS changes take time to propagate. Even if your local resolver sees the new record, Let's Encrypt queries your authoritative nameservers from multiple geographic locations. If those servers haven't synchronized yet, validation fails.
Fix
Increase the wait time between record creation and validation. For certbot --manual, you control this by pausing before pressing Enter. For automated plugins like certbot-dns-cloudflare, the plugin usually waits 10 to 60 seconds by default.
If you're writing your own automation, query the authoritative nameservers directly instead of relying on your local resolver:
dig @ns1.yourprovider.com +short TXT _acme-challenge.example.com
Replace ns1.yourprovider.com with one of your domain's nameservers from dig NS example.com. Poll every 10 seconds until the record appears, then wait an additional 30 seconds for secondary nameservers to sync.
Some DNS providers offer an API that returns a "status" field for record changes. Use that if available. Otherwise, a two-minute wait covers most scenarios.
Error 6: Multiple authoritative nameservers out of sync
Symptoms
Validation succeeds sometimes and fails other times with NXDOMAIN or TXT record not found, even though the record is clearly live. Retrying a few times eventually works.
Root cause
Your domain has multiple authoritative nameservers, and Let's Encrypt queries them in round-robin or random order. If one nameserver has the updated TXT record and another doesn't, validation becomes a coin flip.
Fix
Check all your nameservers individually:
dig NS example.com +short
dig @ns1.example.com TXT _acme-challenge.example.com +short
dig @ns2.example.com TXT _acme-challenge.example.com +short
If the responses differ, your DNS provider's replication is broken. Contact them or switch providers. For emergency mitigation, remove the out-of-sync nameserver from your domain's NS records temporarily, wait for TTL to expire, then request the certificate. Add the nameserver back afterward.
If you manage your own authoritative DNS (BIND, PowerDNS, etc.), verify that zone transfers are working and that the serial number increments with each change. A static serial will prevent secondaries from pulling updates.
Error 7: Wildcard and apex in the same certificate
Symptoms
You request a certificate for both *.example.com and example.com, and the ACME client requires two separate DNS challenges. You create one _acme-challenge record, but validation fails for one of the names.
Root cause
Let's Encrypt treats *.example.com and example.com as distinct identifiers. Each needs its own DNS-01 challenge, which means two TXT records at _acme-challenge.example.com—one for the wildcard, one for the apex. If your DNS panel doesn't support multiple TXT records with the same name, the second overwrites the first.
Fix
Create two TXT records for _acme-challenge.example.com, each with a different token. Most modern DNS panels allow this—you just click "Add another record" with the same hostname.
If your DNS provider silently replaces the first record with the second, you have three options:
- Issue two separate certificates: one for
*.example.comand one forexample.com. Deploy both. - Use a DNS provider that supports multiple TXT records (Cloudflare, Route 53, DigitalOcean, etc.).
- Use a different validation method (HTTP-01) for the apex and DNS-01 for the wildcard. This requires your ACME client to support mixed challenges, which
certbotdoes with--preferred-challenges dns,http.
Verify both tokens are live before starting validation:
dig +short TXT _acme-challenge.example.com
You should see two lines of output. If you only see one, your DNS panel ate the first record.
What to check first
Before opening a support ticket or posting in forums, run this checklist. It catches 90% of wildcard certificate failures in under five minutes.
Confirm the _acme-challenge TXT record exists:
dig +short TXT _acme-challenge.example.com
If nothing comes back, the record isn't published. Wait 2-5 minutes for DNS propagation.
Query all authoritative nameservers individually. If they disagree, replication is broken.
Check for CAA records:
dig +short CAA example.com
If present and letsencrypt.org isn't listed, add it.
Verify you haven't hit rate limits by searching your domain at crt.sh. If you see 50+ certificates issued in the last week, wait for the oldest to age out.
Test your workflow in the Let's Encrypt staging environment first. Staging has higher rate limits and won't lock you out of production.
How long does DNS propagation take?
Most managed DNS providers apply changes within 60 to 120 seconds. After that, the record is live on all authoritative nameservers. Public resolvers like Google (8.8.8.8) cache records based on TTL, which is often 5 to 60 minutes, but Let's Encrypt queries authoritative servers directly, so resolver cache doesn't matter.
Can I automate wildcard certificates without API access?
Manual DNS-01 challenges require you to paste TXT records by hand, which doesn't scale. If your DNS provider doesn't have an API, switch to one that does—Cloudflare, Route 53, DigitalOcean, and most hosting control panels (cPanel/WHM, Plesk) offer API-driven DNS plugins for Certbot and other ACME clients.
Why does HTTP-01 validation not work for wildcards?
HTTP-01 proves you control a specific hostname by serving a file at http://example.com/.well-known/acme-challenge/token. A wildcard like *.example.com represents infinite possible subdomains, so there's no single URL to check. DNS-01 is the only validation method that works for wildcards.
What happens if I delete the TXT record too soon?
Let's Encrypt caches successful validation results for a short period (under an hour), so deleting the record immediately after issuance is fine. If you delete it before the ACME server completes all its checks, validation will fail and you'll have to start over. Wait for the client to confirm success before cleaning up.
Check authoritative servers, not resolvers
Most DNS debugging failures come from querying the wrong server. Your local resolver, Google's 8.8.8.8, and Cloudflare's 1.1.1.1 all cache records and might show stale data. Let's Encrypt queries your authoritative nameservers directly, so that's what you should test.
Find your nameservers with dig NS example.com, then query them explicitly with dig @ns1.yourprovider.com. If the authoritative answer is correct, validation will work. If it's wrong or missing, no amount of retrying will help until you fix the record at the source.