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

  • 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

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

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

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.

Worked Example

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

  • 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

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.

Related

← Back to Property Verification Methods