Is it true that Google demands DNS registration as the only verification method for domain properties?

What distinguishes a domain property from a URL prefix?

A domain property in Search Console aggregates all variations of the same domain: http, https, www, subdomains. You declare example.com, and Google consolidates data from www.example.com, blog.example.com, https://example.com into a single dashboard.

The URL prefix, on the other hand, targets an exact URL. You verify https://www.example.com only — not http://example.com or https://example.com. It's more granular, but it multiplies properties if your site responds under multiple protocols or subdomains.

Why does Google enforce this method for domain properties?

Because DNS registration proves that you control the entire domain at the registrar level. A meta tag or HTML file on https://www.example.com doesn't prove anything for blog.example.com or http://example.com.

Google wants to prevent a third party from accessing the Search Console data of all your variations without actually controlling the root domain. DNS verification closes this loophole — if you can modify the DNS records, you are indeed the legitimate owner.

What exactly is a TXT DNS registration?

It's a line of text added in the DNS zone of your domain, with your registrar (OVH, Gandi, Cloudflare…). Google generates a unique code, you paste it into a TXT record, and Google queries the DNS servers to check for its presence.

No need to touch the site's code, nor the web server. Everything happens upstream, at the name resolution level. Once the record is propagated (anywhere from a few minutes to 48 hours depending on the case), Search Console validates automatically.

• Domain property: mandatory DNS registration, consolidates all variations of the domain.
• URL prefix: optional DNS, meta tag or HTML file accepted, covers only an exact URL.
• DNS propagation: can take up to 48 hours, although it's often instantaneous with modern DNS.
• Enhanced security: only the domain holder at the registrar can add the TXT record.
• No server-side modifications: the CMS, hosting, or source code are not affected.

Is this requirement aligned with industry practices?

Absolutely. For years, domain properties posed a problem of illegitimate access: a third-party provider could verify example.com via a meta tag on www.example.com and then see the stats of all subdomains without the owner's consent.

The DNS registration locks this down. However, it complicates life for teams that do not have access to the registrar — typical in large organizations where marketing drives SEO but does not control the DNS, which is blocked by IT or legal.

What limitations or pitfalls should be anticipated with this method?

The first pitfall is DNS propagation. If your TTL (Time To Live) is high, the registration may take hours to propagate. Google checks immediately — if the DNS hasn't replicated yet, the validation fails. Waiting and retrying solves the issue, but it can be frustrating.

The second point: some registrars (especially low-end resellers) have chaotic DNS interfaces. I've seen cases where the TXT record simply fails to register or gets truncated. [To verify]: Google does not precisely document the maximum length accepted for a TXT, but DNS specs impose 255 characters per string — Google codes remain well below that, fortunately.

In what scenarios does this method truly pose problems?

When the domain is managed by an external entity: an agency that registered the domain in its name, a host that retains control of the DNS, or a corporate structure where the IT service refuses to provide access. In these cases, negotiation is required — or switching to URL prefixes, which fragments the data.

Another edge case: domains with DNSSEC enabled. If the DNSSEC signature is misconfigured after adding the TXT, the domain may become temporarily inaccessible. This is rare, but it happens — always test in a staging environment if possible.

What exactly should you do to verify a domain via DNS?

Log into Search Console, add a domain property (example.com without http or www). Google generates a unique TXT record, something like google-site-verification=ABC123XYZ. Copy this code.

Go to the DNS interface of your registrar — OVH, Gandi, Cloudflare, GoDaddy, etc. Create a new TXT type record, hostname @ or blank (depending on the interface), value = the code provided by Google. Save, wait a few minutes, go back to Search Console and click on "Verify".

What mistakes should be avoided during the DNS manipulation?

Do not confuse TXT record and CNAME. Google requires a TXT, not a CNAME pointing to a validation domain. Some registrars offer both — read the label carefully.

The second common mistake: adding quotes or unnecessary spaces in the value of the TXT. Copy and paste the exact code without modifying anything. An extra space, and Google will not recognize the signature.

How can you verify that the DNS propagation worked?

Use a tool like dig in command line (dig example.com TXT) or a web service like MXToolbox, DNSChecker. You should see the google-site-verification record appear in the response. If it doesn't show up after 30 minutes, check that you saved the DNS zone with your registrar.

Some registrars require an additional action (a button "Apply Changes" separate from just "Save"). If the verification fails in Search Console, it’s often because the record is not yet publicly visible.

• Retrieve the TXT code generated by Search Console for the domain property.
• Log into the DNS interface of the registrar (OVH, Gandi, Cloudflare…).
• Add a TXT record, hostname @ or blank, value = Google code.
• Save and apply DNS changes (some registrars have two distinct buttons).
• Wait 5 to 30 minutes, check propagation with dig or MXToolbox.
• Return to Search Console, click on "Verify" — if it fails, wait longer and retry.