Using TXT Records for Domain Verification: Complete Guide

Learn how TXT records are used for domain verification across services like Google, GitHub, Let's Encrypt, and Cloudflare — with practical examples for is-pro.dev subdomains.

Written by Mayank Baswal

Founder of is-cool-me · DNS & Platform Infrastructure

Mayank Baswal maintains the is-cool-me platform and writes technical guides focused on DNS configuration, subdomain infrastructure, SSL troubleshooting, deployment workflows, and platform reliability.

Reviewed by is-cool-me Technical Review

What Are TXT Records?

TXT records are a DNS record type that stores arbitrary text strings associated with a domain. Defined in RFC 1035 and extended by later specifications, TXT records were originally designed for descriptive text. Today they serve as the backbone of domain ownership verification, email authentication, and several other internet protocols.

Unlike A records (which map to IP addresses) or CNAME records (which alias to other hostnames), TXT records carry no routing or resolution information. They exist purely as data that services query and validate. A single domain can have multiple TXT records, and DNS resolvers return all matching records for a given name. The querying application processes only the ones it recognizes by matching the exact string content.

Why Services Use TXT Records for Verification

When a service asks you to add a TXT record to verify domain ownership, it is asking you to prove administrative access to the DNS zone. The service generates a unique token, you publish it as a TXT record at a specific hostname, and the service queries DNS to confirm the token exists. If it matches, ownership is proven.

TXT records are ideal because they do not affect website traffic, email delivery, or SSL certificates. Adding a TXT record is non-invasive — it cannot break your site or redirect your mail. Once verified, you can often delete the record without losing ownership, though some services require ongoing presence for periodic re-validation. This makes TXT-based verification the safest and most universal approach across the industry.

Google Search Console Verification

Google Search Console uses TXT records to verify domain ownership before granting access to search data and indexing controls. When you add a property, Google provides a verification string:

google-site-verification=aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567

Publish this as a TXT record on your subdomain. For an is-pro.dev subdomain:

myproject.is-pro.dev.  TXT  "google-site-verification=aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567"

After propagation, click "Verify" in Search Console. Google queries the hostname, finds the token, and grants ownership.

GitHub Pages Domain Verification

GitHub uses DNS-based TXT records for domain verification at the account and organization level. The record uses a challenge prefix:

_github-challenge-myorg.is-pro.dev.  TXT  "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Once added, GitHub queries that hostname and marks the domain as verified, enabling organization-level domain association and preventing other GitHub users from claiming the same domain. This verification is required before you can enable certain security features like SAML SSO for enterprise organizations.

Let's Encrypt DNS-01 Challenge

The ACME protocol's DNS-01 challenge is the only method that supports wildcard certificates. Your ACME client creates a TXT record at a challenge hostname:

_acme-challenge.myproject.is-pro.dev.  TXT  "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Let's Encrypt queries DNS for this record. If the token matches, the certificate is issued. For automated renewal, your client must update this record through your DNS provider's API. The is-pro.dev dashboard supports API-based record management for this use case.

Tip: DNS-01 is required for wildcard certificates like *.yourproject.is-pro.dev. HTTP-01 validation uses a file served over port 80 instead.

Cloudflare SSL/TLS Verification

Cloudflare may request a TXT record when you enable SSL/TLS for a domain proxied through their network. When adding a new domain, the platform provides several DNS records to configure, including a TXT verification record for certain features. The verification ensures Cloudflare can issue and renew SSL certificates without interruption. The record is typically one-time, but should remain until the certificate is active and confirmed in the Cloudflare dashboard.

SPF, DKIM, and DMARC as TXT Records

Beyond ownership verification, TXT records power email authentication. SPF publishes authorized sending IPs:

mail.myproject.is-pro.dev.  TXT  "v=spf1 include:sendgrid.net ~all"

DKIM publishes a public key at a selector subdomain for cryptographic email signing. DMARC publishes a policy at _dmarc telling receivers how to handle authentication failures. For a full walkthrough, see our MX, SPF, and DKIM Basics guide.

Adding TXT Records via is-pro.dev Dashboard

Adding a TXT record through the is-pro.dev dashboard:

  1. Log in at dash.is-pro.dev.
  2. Navigate to DNS management for your subdomain.
  3. Click "Add Record" and select type TXT.
  4. Enter the hostname (e.g., @ for the subdomain root, or _acme-challenge for Let's Encrypt).
  5. Paste the TXT value and save. Changes propagate within seconds on the is-cool-me DNS infrastructure.

Verifying TXT Record Propagation with dig

After adding a TXT record, confirm it is visible:

dig myproject.is-pro.dev TXT +short

This returns all TXT records for the hostname. You should see the verification token you just added. If multiple TXT records exist, dig returns all of them. To query a specific nameserver:

dig @ns1.is-pro.dev myproject.is-pro.dev TXT +short

If dig returns the expected value but verification still fails, the service may be querying a different nameserver with cached results. Wait a few minutes and retry.

Common Issues and Troubleshooting

Verification Fails After Adding the Record

Even on platforms with fast propagation, verification services may cache previous results. Wait five minutes and retry. Most services allow multiple attempts without penalty.

Wrong Hostname or Missing Prefix

The most common mistake is adding the TXT record at the wrong hostname. If Google asks for myproject.is-pro.dev and you add it at the root, verification fails. Always copy the exact hostname from the verification instructions.

Extra Quotes or Whitespace

Do not add extra spaces, newlines, or additional quotes beyond what the DNS provider requires. Most dashboards handle quoting automatically — paste the raw value.

TTL Causing Stale Cache

If you recently changed a TXT record, resolvers may still serve the old value until the TTL expires. Use dig +trace to identify stale data, or wait for the TTL to elapse.

Frequently Asked Questions

Can I verify without a TXT record?

Some services support HTML file uploads or meta tags, but TXT record verification is the most universal method. It does not require changes to your website's content and is the only option for bare domains without a web server.

Should I keep the TXT record after verification?

It varies. Google Search Console allows deletion but requires re-verification if you lose access. Let's Encrypt challenge records are temporary. Cloudflare may require the record for ongoing SSL management.

How fast do TXT records propagate on is-pro.dev?

TXT records added through the is-pro.dev dashboard propagate almost instantly. External resolvers pick up changes within one to five minutes.

Can I verify a subdomain I do not own?

No. Domain verification requires administrative access to the DNS zone. You must have an active is-pro.dev subdomain allocated to your account.

Need help? See Guides for step-by-step tutorials or join the Discord community for real-time support.