Verifying a GSC Property with DNS TXT Records

Problem Statement

You are migrating to a new domain and need a Search Console domain property that covers every subdomain and both protocols in one view — which means verifying by DNS TXT record, the only method a domain property accepts. This guide, part of Property Verification Methods, walks the exact record creation and the dig confirmation that prevents a premature, failing click on Verify.

DNS TXT verification flow Four steps: copy the token from Search Console, add it as a TXT record, confirm propagation with dig, then click Verify. DNS TXT Verification Flow 1. Copy token 2. Add TXT 3. Confirm 4. Verify From GSC At zone apex dig +short TXT Click in GSC Never click Verify before dig returns the exact token
Copy the token, publish it at the apex, confirm with dig, then verify — in that order.

When to Use This Approach

DNS verification is the default for a migration regardless of which of these applies, because it is the only method whose token survives the replacement of the document root and the templates.

  • You are creating a domain property that must span every subdomain and both http/https
  • The new domain’s DNS is under your control via a registrar console or the Cloudflare API
  • You want verification that survives origin and host changes during cutover
  • A previous URL-prefix property is missing traffic from subdomains or the bare host
  • You need a method that does not depend on deploying files to the new origin

Step-by-Step Instructions

The whole procedure takes a few minutes; almost all reported difficulty comes from the placement conventions in step 2 rather than from anything conceptually hard.

1. Copy the Verification Token from Search Console

In Search Console, add a property, choose “Domain”, enter the bare domain (no protocol, no www), and copy the google-site-verification= TXT value it generates. This token is unique per property — do not reuse one from another site.

# Example token Search Console issues for the new domain property
google-site-verification=AbCdEf123GhIjKl456MnOpQr789

Copy the token exactly, in one operation, straight from the property it belongs to. It is a long opaque string with no checksum and no human-readable structure, so a single transposed character produces a verification that fails with no indication that the token is the problem — and because the string looks equally plausible either way, people tend to re-check the propagation, the record name, and the provider before suspecting the value itself. Paste rather than retype, and paste directly into the DNS interface rather than via an intermediate document that might introduce a line break or a smart quote.

Note which property issued it. Search Console mints a distinct token per property, so the legacy domain and the new domain each get their own, and the two are visually indistinguishable. Adding the new domain’s token to the legacy zone is a common and thoroughly confusing mistake, because everything about the operation appears to have worked.

2. Add the TXT Record at the Zone Apex

Create a TXT record on the domain’s root (@ / apex) with the token as its value and a short TTL so it propagates quickly. Via the Cloudflare API:

# name "@" targets the apex; ttl 300 keeps propagation under five minutes
curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"TXT","name":"@","content":"google-site-verification=AbCdEf123GhIjKl456MnOpQr789","ttl":300}'

3. Confirm Propagation with dig

Before clicking Verify, query the TXT record at a public resolver and confirm the exact token is returned. Clicking too early causes a verification failure and an unnecessary retry delay.

# Query an authoritative public resolver; the token must appear verbatim
dig +short TXT newdomain.example @1.1.1.1

Check the apex specifically, not the domain generally. Many DNS interfaces present a name field that already implies the zone, so entering example.com produces a record at example.com.example.com — which resolves for nothing and is invisible unless you query for it. The convention for the apex varies between providers: some expect @, some expect an empty field, some expect the bare domain. Add the record, then immediately query the apex with dig and confirm the token comes back; that single check catches this and most other placement errors.

Confirm your other apex records survived the save. This is the one step in DNS verification capable of breaking something unrelated, and it happens on providers whose interface treats all TXT values at a name as a single editable block rather than as separate records. If your SPF record is missing after saving, restore it before doing anything else — mail failures caused this way take hours to surface and are rarely connected back to a Search Console task.

4. Click Verify and Leave the Record in Place

Once dig returns the token, return to Search Console and click Verify. Leave the TXT record permanently — Google re-checks it periodically and downgrades the property to unverified if the record disappears. For wider propagation behaviour, see DNS Propagation Tracking.

Three details account for most failed DNS verifications, and all three are things the provider interface does rather than things you do.

Common causes of a failed DNS TXT verification Four failure causes — record placed on a subdomain, the provider appending the domain to the name field, an interface replacing rather than appending TXT values, and clicking verify before propagation — each with how to detect it. Nearly every failure is the interface, not the token Cause How you spot it Record placed on a subdomain dig on the apex returns nothing; dig on www returns it Provider appended the domain again the record lands on example.com.example.com Interface replaced other TXT values your SPF record has vanished — check immediately Verified before propagation dig shows the token but the click already failed The third row is the only one that breaks something other than verification — which is why the SPF check belongs immediately after adding the record.
Query the apex with `dig` before clicking Verify and three of these four become visible in a single command.

Worked Example

The sequence below is a first-time verification of a new domain property during a migration window. Migrating from legacy-shop.com to newshop.example. In Search Console you add a Domain property for newshop.example and receive the token google-site-verification=AbCdEf123GhIjKl456MnOpQr789. You publish it at the apex via the Cloudflare API with TTL 300. Two minutes later:

$ dig +short TXT newshop.example @1.1.1.1
"google-site-verification=AbCdEf123GhIjKl456MnOpQr789"
"v=spf1 include:_spf.example.com ~all"

Both TXT records coexist at the apex — the SPF record is untouched and the verification token is present. You click Verify in Search Console and the domain property reports “Ownership verified”, now covering newshop.example, www.newshop.example, and every other subdomain in a single view.

Verification

Confirm all three of the following, in this order — the token resolves at the apex, the property reports as verified, and your pre-existing apex records are intact. The third is the one nobody thinks to check and the only one that can break something outside Search Console.

  • dig +short TXT newdomain.example @1.1.1.1 returns the exact google-site-verification= token
  • Search Console shows the domain property as “Ownership verified” with no warning banner
  • Pre-existing TXT records (SPF, DKIM) remain intact at the apex after adding the token

Leave the record in place once verification succeeds. It is checked again periodically, and removing it as part of a later tidy-up un-verifies the property weeks afterwards with no warning and no obvious link to the change that caused it — a failure mode made worse by the fact that whoever removed it has long since moved on to something else.

A verification token coexisting with other apex TXT records The zone apex holding an SPF record, a DKIM policy record and the Google verification token side by side, illustrating that TXT records accumulate without interfering with each other. TXT records coexist — adding one replaces nothing example.com. IN TXT "v=spf1 include:_spf.provider.com ~all" "v=DMARC1; p=quarantine; rua=..." "google-site-verification=xxxxxxxxxxxxxxxxxxxx" The hazard is not the protocol but interfaces that present all three as one editable field and save your edit over the lot. Re-query the apex after saving and confirm all the records you expected are still there.
Verification is additive by design; the only realistic way to break mail while adding a token is a control panel that edits the set rather than the record.

FAQ

Why must I use DNS TXT for a domain property? A domain property spans every subdomain and protocol, so Google requires proof of control over DNS itself — file and meta-tag methods only prove control of a single origin and are restricted to URL-prefix properties.

Will adding the TXT record break my existing SPF or DKIM records? No. A domain can hold multiple TXT records at the apex. The verification token sits alongside SPF and DKIM without conflict, as the worked example shows.

How long should I wait between adding the record and clicking Verify? Wait until dig returns the token — usually one to five minutes with a TTL of 300. Do not rely on a fixed timer; confirm with dig first to avoid a failed verification.

Does the TTL on the verification record matter? Only for how quickly you can verify. A short TTL — 300 seconds is ample — means the record becomes visible to the checker within minutes rather than hours, which is the difference between verifying in one sitting and coming back tomorrow. Once verification succeeds the TTL is irrelevant to anything, so there is no need to raise it afterwards, and leaving it low costs nothing measurable on a record queried this rarely.

Can I use the same token for the legacy and new domains? No — Search Console issues a distinct token per property, so each domain gets its own record in its own zone. This is worth knowing because the two look similar enough to be confused, and pasting the new domain’s token into the legacy zone produces a verification that fails for reasons the interface describes unhelpfully. Copy each one directly from the property it belongs to, immediately before adding it.

What if the domain uses a DNS provider that does not support apex TXT records? That is rare but real, usually on providers that implement apex handling through a proprietary flattening mechanism. Where it occurs, a domain property is not available and you fall back to URL-prefix properties with a file or tag method — verifying all four scheme-and-host combinations rather than just the canonical one. It is also worth treating as a prompt to move DNS somewhere less constrained, since the same limitation will complicate the cutover itself.

Related

← Back to Property Verification Methods