Why Domain Verification Fails Even When Your DNS Records Look Correct

When a website service, certificate provider, or other platform asks you to verify a domain, it checks DNS, the system that directs domain-name lookups and stores information such as verification tokens. A record shown in your DNS provider’s dashboard only confirms that you entered it there. The verification service must be able to find the exact record it expects through public DNS, meaning DNS servers available on the internet.

Verification most often fails because the record is saved in the wrong provider’s zone, its name or value does not match what the service expects, or the verifier’s servers and resolvers have not received the update. The exact checks depend on the service: Google Search Console looks for a site-ownership record, while Let’s Encrypt’s DNS-01 certificate challenge looks for a temporary TXT record under _acme-challenge. Start by identifying the verification method, then check what public DNS returns for the exact name and record type it specifies.

Check the name and type the verifier requested

A DNS record has a name that tells DNS where to look and a value that gives the information the verifier expects. A record can look correct in a control panel and still fail if either field is wrong. Provider interfaces use different labels, such as “host,” “name,” “target,” or “value,” so follow the verifier’s instructions rather than assuming what each field means.

Use the exact record name and value supplied by the verification service. Google Search Console’s TXT method requires its verification string at the domain being verified. Its instructions say to leave the host field blank or enter @ when the provider requires a value for the root domain. Those directions apply to that Search Console method; another service may ask for a different name or type. Verifying www.example.com also does not automatically verify example.com. Search Console’s ownership instructions show how its DNS method specifies the record.

For a certificate challenge, check the challenge name itself. Let’s Encrypt’s DNS-01 method looks for a TXT value at _acme-challenge for the domain. A token at the root domain or under www will not answer that query. The Let’s Encrypt challenge instructions describe the expected location and value.

Confirm which provider serves the public DNS zone

The registrar, web host, and DNS provider can be separate companies. The registrar manages the domain registration, while the DNS provider hosts the zone containing records such as TXT and CNAME entries. The domain’s authoritative nameservers are the servers that public DNS designates as the source of its DNS answers.

Check the domain’s public nameserver records (NS records) before editing. A record added to Provider B’s dashboard will not appear in public DNS when those nameservers point to Provider A. The domain’s delegation is the link between the domain and the nameservers responsible for answering questions about it. A dashboard can show a saved record even when the domain delegates DNS to a different provider.

Compare the nameservers in the registrar’s settings with the nameservers returned by a public DNS lookup. If they do not match, fix that discrepancy before changing the verification record. Google’s domain troubleshooting guidance recommends checking delegation and querying authoritative nameservers when DNS answers do not match expectations.

Compare authoritative answers and public resolvers

DNS changes do not become visible to every observer at the same moment. A recursive resolver is a server that looks up DNS answers on behalf of a user or service and may keep a recent answer in its cache. Your computer, workplace network, and verification service may use different resolvers. A lookup that succeeds on your network therefore does not prove that the verifier receives the same answer.

A domain also has multiple authoritative nameservers. If one serves the updated record while another serves older data, those servers return different results to queries. Query the expected record directly from each authoritative nameserver, then compare those answers with public resolvers. Google’s DNS troubleshooting guidance specifically recommends checking each authoritative server when answers disagree.

The DNS provider needs time to publish the update, and resolvers need time to replace cached answers. Wait for those delays before retrying. There is no single waiting period that applies to every provider and verification service. Google Search Console advises that its TXT record can take from minutes to days to become visible, while Let’s Encrypt notes that DNS-01 validation may require a longer wait when a provider cannot confirm propagation. Treat those as service-specific guidance, not a promise of a universal deadline.

Read DNS errors as clues

The answer to a DNS query helps identify where the lookup failed. NXDOMAIN means the queried name does not exist in the answer the resolver received. A missing TXT or CNAME answer points toward the wrong name, the wrong zone, or an update that is not visible yet. A timeout means the query did not receive an answer in time.

SERVFAIL means the resolver could not complete the lookup. One possible cause is DNSSEC, a method that uses digital signatures to let resolvers check that DNS answers have not been altered. If the domain’s DNS provider changes while its DNSSEC settings remain inconsistent, validating resolvers can reject answers. Authoritative-server problems and timeouts can also produce SERVFAIL, so check the reported error and DNSSEC state rather than treating that response as proof of one cause. Google’s DNS guidance covers DNSSEC and other resolution failures.

Also compare answers from more than one public resolver. A successful result through one resolver and a failure through another points to inconsistent visibility or resolution. Some certificate validation services check from multiple locations; Google Trust Services’ DNS debugging guidance describes how location-dependent answers can affect its validation.

Separate ownership checks from certificate checks

When a certificate authority issues a certificate, it can check DNS records beyond the challenge record. CAA, or Certificate Authority Authorization, records tell certificate authorities which providers are allowed to issue certificates for a domain. If a CAA record blocks the certificate provider, certificate issuance can fail even when the DNS-01 challenge record is correct. CAA is relevant to certificate issuance; it is not a general explanation for a failed site-ownership check.

Multiple TXT values at one name also do not automatically invalidate verification. Let’s Encrypt allows multiple simultaneous DNS-01 challenge values, but warns that leftover values can create an oversized DNS response that the service rejects. Inspect the answers before removing records, and delete stale challenge values only when they are no longer needed. Provider interfaces format TXT records differently. Follow your DNS provider’s instructions rather than assuming displayed quotation marks or string limits apply everywhere.

Trace the failure from public DNS

Follow the verification service’s exact instructions and note the requested record type, name, and value. Check that the domain’s public nameservers match the DNS provider where you entered the record. Query the exact name and type on each authoritative nameserver and through public resolvers. Compare the answers: does the query return the expected value, no record, NXDOMAIN, SERVFAIL, or a timeout?

If the answers differ, investigate delegation, server consistency, caching, or DNSSEC before editing unrelated records. If all public checks return the expected answer consistently, retry verification and keep the error message and query results. At that point, check the verifier’s specific requirements or validation behavior.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com