Why DNS-01 Returns NXDOMAIN Even When the TXT Record Exists

This error is maddening because it looks like a contradiction.

You can see the TXT record. Your DNS dashboard shows it. Maybe one dig command shows it too. And yet Let’s Encrypt still replies with:

NXDOMAIN looking up TXT for _acme-challenge...

When that happens, the record usually exists somewhere, but not where the public validation path is actually looking.

What NXDOMAIN means here

For DNS-01, Let’s Encrypt queries _acme-challenge.<domain> and expects to find a TXT answer there, either directly or through valid delegation.

If it gets NXDOMAIN, the public lookup path still says "that name does not exist" at the moment validation runs.

That can still happen even when:

• your provider UI shows a TXT record
• one resolver already sees the answer
• the delegated target looks correct on its own

Why your local check can be misleading

DNS is not one view.

You may be looking at:

• cached data from a resolver that already picked up the change
• the wrong DNS provider dashboard
• the delegated target instead of the public _acme-challenge name
• one authoritative path that updated faster than another

That is why "but I can see the TXT" is a clue, not proof.

The most common causes

1. You edited the wrong DNS provider

This is the classic one.

The TXT exists, but only in the dashboard of a provider that is no longer authoritative for the domain.

2. The record is at the wrong hostname

DNS-01 needs the TXT at _acme-challenge.<domain>.

Apex records, duplicated suffixes, or provider UI quirks can leave you with a perfectly real TXT record at the wrong place.

3. Delegation is only half-finished

If you use CNAME or NS delegation, the public _acme-challenge name still has to reach the delegated zone cleanly.

It is very possible for the target zone to look fine while the public name still returns NXDOMAIN because the parent side is wrong.

4. Propagation is not done

This is where DNS gets annoying. One resolver may see the new value while another still sees nothing at all.

5. Validation started too early

Some providers need much longer than people expect. If the automation writes the TXT and immediately asks production to validate, NXDOMAIN is a predictable result.

What to check, in order

1. Check the authoritative nameservers

If you changed the wrong provider, stop there and fix that first.

2. Check the exact _acme-challenge name

Do not assume the provider UI interpreted the record name the way you intended.

3. Check delegation end to end

If there is a CNAME or NS handoff, follow the whole path from the public name, not just the target.

4. Wait long enough for the answer to settle

If propagation visibility is poor, patience is part of the fix.

5. Clean up stale TXT clutter if needed

Multiple TXT values can be valid in some cases, but a pile of old challenge records is still a good way to confuse yourself.

What not to do

Do not immediately switch ACME clients.

Do not change challenge methods just because one DNS lookup looked weird.

Do not hammer production with retries while the record is still moving through DNS.

Common misunderstandings

"My dashboard shows the TXT, so Let’s Encrypt must be wrong"

No. The dashboard may be showing the wrong zone or a record that the public validation path still cannot reach.

"One resolver sees it, so validation should pass"

No. DNS propagation can be uneven.

"NXDOMAIN means the TXT definitely does not exist anywhere"

No. It often means the public path to that TXT is still broken.

FAQ

Why does DNS-01 say NXDOMAIN when I can see the TXT record?

Because the TXT may exist in the wrong zone, at the wrong hostname, through a broken delegation path, or before propagation has finished.

What should I check first?

Check the authoritative nameservers and the exact _acme-challenge hostname.

Can CNAME or NS delegation cause this?

Yes. The target may be fine while the public _acme-challenge name still fails to reach it.

Does waiting really help?

Sometimes yes. DNS propagation is still one of the most ordinary reasons this error shows up.