DNS verification failures have a particular talent for wasting an afternoon: the control panel shows the record, the service says it is missing, and “wait 72 hours” becomes the only advice. Before waiting, ask a more useful question: which resolver was queried, for which exact name, and what did it return?

TXT and CNAME answer different questions

  • TXT stores one or more text strings at an exact DNS name. Ownership tokens, SPF policies, and DKIM public-key material commonly use it.

  • CNAME makes one name an alias of another canonical name. Query the precise verification host, not merely the zone apex.

  • A displayed provider field such as @ usually means the zone apex; it is interface shorthand, not a character that necessarily appears in the DNS name.

  • Per RFC 2181, a CNAME owner name cannot also hold ordinary data such as TXT, A, or MX records. Provider-specific flattening at an apex is not the same wire-level record behavior.

Query the exact record with dig

Terminalbash
dig +short TXT example.com
dig +short CNAME verify.example.com

Reading the short answers

  • dig sends a DNS query through the resolver configured for the machine unless a server is named explicitly.

  • +short removes the response header and shows the answer data; an empty result means that resolver returned no answer of the requested type.

  • TXT output is quoted because DNS TXT data is encoded as character strings. Long values may appear as adjacent quoted chunks in one record.

  • A CNAME answer ends in a domain name, often with a trailing dot that marks a fully qualified name.

Keep the full response when TTL and status matter

Terminalbash
dig TXT example.com
dig CNAME verify.example.com

Signals worth noticing

  • status: NOERROR can accompany an empty answer when the name exists but not with the requested type; NXDOMAIN means the queried name does not exist.

  • The ANSWER section contains owner name, TTL, class, record type, and record data.

  • The SERVER line identifies the resolver whose cached or recursive view you inspected.

  • A TTL is remaining cache lifetime in that response, not a guaranteed global propagation countdown.

Compare public recursive resolvers

Terminalbash
dig @1.1.1.1 TXT example.com
dig @8.8.8.8 TXT example.com
dig @1.1.1.1 CNAME verify.example.com
dig @8.8.8.8 CNAME verify.example.com

What this comparison proves

  • The @server argument selects a resolver instead of silently using the machine default.

  • Matching answers increase confidence that public recursive caches see the same data.

  • Different answers can be caused by cached positive or negative responses, split-horizon DNS, or a partial authoritative deployment.

  • A public-resolver result does not prove every verifier has refreshed its own cache.

Ask the authoritative server when caches disagree

Terminalbash
dig +short NS example.com
dig @ns1.example-dns.net TXT example.com
dig @ns1.example-dns.net CNAME verify.example.com

Why authoritative lookup changes the diagnosis

  • The NS query reveals the servers delegated for the zone from the recursive resolver’s perspective.

  • Querying one of those servers directly checks published zone data without a recursive cache in the middle.

  • If authoritative data is wrong, fix the DNS provider or the delegation; more cache flushing will not repair it.

  • Query every authoritative server when results are inconsistent, because one stale secondary can create intermittent verification failures.

Why the record can exist in the dashboard but not in DNS

  • Wrong owner name: the provider automatically appended the zone, producing something like verify.example.com.example.com.

  • Wrong zone: the record was added at the registrar although another provider’s name servers are authoritative.

  • Wrong type: a token intended for TXT was entered as a CNAME, or the name and target were reversed.

  • CNAME collision: the alias owner already has another record type, which conflicts with normal CNAME rules.

  • Quoted value error: quotation marks from documentation were saved as literal characters, or a TXT value was copied incompletely.

  • Negative caching: a resolver cached the earlier absence; the zone can be correct while that cached answer remains valid.

Use a browser-based lookup when dig is unavailable

The Google Admin Toolbox Dig is a browser-based equivalent for inspecting public DNS. Enter only the hostname—without https://, a path, or a verification token—and choose TXT or CNAME. Treat the result as the view of that service, then compare it with the authoritative answer when troubleshooting.

A verification checklist that avoids blind waiting

  1. Copy the exact record name, type, and value from the service requesting verification.

  2. Confirm which name servers are authoritative for the domain.

  3. Query the exact owner name and type with full dig output.

  4. Ask each authoritative server directly and resolve any inconsistent answers.

  5. Compare one or two public recursive resolvers and account for the returned TTLs.

  6. Retry verification only after the expected public answer is visible.