What TXT Verify Records are

A TXT Verify Record is a DNS entry that proves to an external service that you control a domain. The mechanism relies on simple logic: only someone with administrative access to a domain's DNS can create entries there.

A service provides you with a unique token value. You add this value as a TXT record in your DNS. The service queries your DNS and checks whether the token is present. If it is, the domain is considered verified.

What TXT Verify Records are used for

The most common use cases:

Webmaster tools and analytics: Google Search Console, Bing Webmaster Tools, and similar services use TXT records to ensure that only the actual domain owner can access traffic data and indexing settings.

Email services: Mailchimp, SendGrid, or Amazon SES require domain verification before you can send emails on behalf of your domain. This prevents arbitrary third parties from using your domain as a sender.

Cloud platforms: AWS, Azure, and Google Cloud use TXT records to authorize custom domains for services like CloudFront, App Service, or Cloud Run.

Certificate issuance: Certificate Authorities (CAs) like Let's Encrypt offer DNS-based validation as an alternative to HTTP challenges. A TXT record at _acme-challenge.example.com proves domain control and authorizes certificate issuance.

SaaS integrations: Services like Slack, Atlassian, or GitHub use TXT records to associate organizations with a domain and configure Single Sign-On.

What a TXT Verify Record looks like technically

Depending on the service, there are two variants:

Variant 1: TXT record on the root domain

example.com. IN TXT "google-site-verification=abc123def456"

The token is set directly on the domain as a TXT record. The service name is recognizable in the token value.

Variant 2: TXT record on a subdomain

_github-challenge.example.com. IN TXT "token123"

The service specifies a dedicated subdomain where the token is placed. This has the advantage that it's immediately visible which service requested this entry.

Security-relevant differences

The two variants differ in one important aspect: attributability.

A token like TXT "a8f3b2c9e1d4" on the root domain is anonymous. Anyone looking at the DNS six months later cannot tell which service requested this token, whether it's still needed, or whether it can be safely removed.

A token under _driftguard.example.com or with the prefix google-site-verification= is self-documenting. Origin and purpose are immediately apparent.

This matters because DNS entries accumulate. Over the years, tokens from various services pile up. When a token can no longer be attributed to any service, it typically stays in place – even if the associated account was cancelled long ago.

Risks of uncontrolled Verify Tokens

TXT Verify Records are an authorization mechanism. Whoever can place a specific token in a domain's DNS receives permissions. The flip side: a wrongly placed token can grant unintended permissions.

Certificate abuse: If an attacker manages to inject a CA validation token into your DNS, they can have a valid TLS certificate issued for your domain. All it takes is someone on your team copying a token from a convincing phishing email into the DNS.

Domain takeover on cloud services: Many cloud platforms bind custom domains via TXT verification. A leftover or manipulated token can give a foreign account control over your domain.

Orphaned tokens: Old tokens that remain in DNS after switching services can become a problem if the associated service gets compromised or someone takes over the old account.

Best practices for handling Verify Tokens

Verify the source: Before adding a token to your DNS, confirm that the request actually comes from the expected service. Open the service's dashboard directly – don't follow links from emails.

Prefer named tokens: Services that use a specific subdomain prefix (like _github-challenge or _driftguard) make the purpose of each entry transparent. This simplifies future audits.

Document your tokens: Keep a record of which TXT record was added when, by whom, and for which service. Without this information, cleanup becomes impossible.

Clean up regularly: Check quarterly whether all TXT Verify Records are still associated with an active service. Remove everything that's no longer needed.

How Driftguard helps with TXT Records

In Driftguard, you can specify exactly which TXT records should be monitored. You name the records that are relevant to you – and Driftguard regularly checks whether they're still present, whether their content has changed, or whether they disappear unexpectedly.

Driftguard's own verification token uses a named record (_driftguard.example.com), so it's always clear in your DNS that this entry belongs to Driftguard.

This gives you targeted control over the records that are critical to your infrastructure – without noise from irrelevant entries.

TXT Verify Records: How to prove domain ownership to third-party services