How to Verify Domain Ownership

Many services ask you to prove you control a domain before they let you use it, and the usual way is to add a DNS record only the domain owner could add. This guide explains why DNS is used for verification, walks through the TXT and CNAME methods step by step, and covers the issues that most often trip people up.

Why services verify via DNS

Only the person who controls a domain's DNS can publish records for it, so adding a record a service has specified is solid proof of ownership. That is why email providers, hosting platforms, certificate authorities, and analytics tools all ask you to add a DNS record before they trust you with the domain. The most common form is a TXT record, with CNAME used as an alternative.

The TXT record method

This is the most common approach. The service gives you a unique value to publish as a TXT record, often something like google-site-verification=abc123. You add it at the host the service specifies, which is frequently the apex domain but sometimes a dedicated subdomain.

You can confirm the record is in place by querying it:

dig +short example.com TXT

When the verification value appears in the output, the service should be able to see it too.

The CNAME method

Some services verify with a CNAME instead. They give you a unique host to create, such as abc123.example.com, that points to a target on their domain. Because only you can create a record under your domain, a successful lookup proves control just as a TXT record does. Confirm it with a CNAME query:

dig +short abc123.example.com CNAME

Step by step

Whichever method the service uses, the process is the same:

  1. Copy the exact host and value the service gives you, taking care not to add or trim characters.
  2. Open the DNS management area at your DNS provider and add a new record of the requested type.
  3. Paste the host and value exactly, then save the record.
  4. Wait a short while for it to propagate, then click verify in the service.

Troubleshooting

If verification fails, it is almost always one of a handful of issues:

  • Propagation delay — you checked before the record went live. Wait out the old TTL and retry. See what is DNS propagation.
  • Wrong host — the record landed on the apex when a subdomain was required, or vice versa. Re-read the instructions and confirm the exact host.
  • Multiple records — an old or conflicting record is interfering. Make sure the value matches exactly and remove stale duplicates if the service expects only one.

To confirm the record is visible from outside your own network before you retry, follow our guide on how to check DNS propagation.

Never miss a DNS change again.
Start monitoring in minutes.