Using TXT Records for Domain Verification

What TXT Records Are Used For

Text (TXT) records are the most versatile DNS record type. Originally created for attaching arbitrary human-readable notes to domain names, they have evolved into the primary mechanism for domain ownership verification, email authentication, and framework policy publication. Unlike A or CNAME records, TXT records do not affect how traffic routes to your server. They are purely informational, which makes them ideal for verification purposes.

Common TXT record use cases include:

• Domain ownership verification — Proving to a third-party service that you control a domain
• SPF records — Authorizing email senders for your domain
• DKIM records — Publishing public keys for email signing verification
• DMARC records — Setting email authentication policies
• Google Site Verification — Proving ownership to Google Search Console
• Microsoft 365 verification — Proving ownership for Exchange Online setup
• Custom framework policies — Such as Apple App Site Association or Google Firebase Domain Association

Domain Verification: Common Scenarios

Virtually every major SaaS platform uses DNS TXT records for domain verification. The pattern is always the same: the platform generates a unique string, you publish it as a TXT record on your domain, and the platform queries DNS to confirm the record exists. Here are the most common scenarios:

Google Search Console

Verifying your domain in Google Search Console allows you to monitor search performance, submit sitemaps, and identify indexing issues. Google offers multiple verification methods, but the DNS TXT method is the most reliable because it works regardless of your hosting provider and does not require uploading files to your server.

Google provides a verification string like google-site-verification=6lN8x2y3Z4aBcDeFgHiJkLmNoPqRsTuVwXyZ012345. You create a TXT record with this exact value, and Google checks for it.

AWS SES (Simple Email Service)

To send email through Amazon SES from your domain, you must verify domain ownership. AWS provides a TXT record value that you publish at your domain. Once verified, you can also publish DKIM records (TXT records) provided by AWS to authenticate your emails.

GitHub Pages Custom Domain Verification

When adding a custom domain to a GitHub Pages site, GitHub may ask you to verify ownership by adding a TXT record with a value like github-verification-code=abc123def456. This prevents other GitHub users from using your domain on their Pages sites.

Spotify, Discord, Stripe, and Others

These platforms use domain verification for various purposes:

• Spotify: Verify a custom domain for artist/profile pages.
• Discord: Verify domain ownership for server authentication and branded links.
• Stripe: Verify domain for Connect platforms and branded payment links.
• Microsoft 365: Verify domain ownership before setting up Exchange, Teams, and other services.
• Cloudflare: Verify domain ownership when onboarding a new domain to their dashboard.

How Domain Verification Works

The verification process is a cryptographic proof of control:

1. Platform generates a token: The SaaS platform creates a unique, non-guessable string. This token is typically a long alphanumeric string or a formatted code like google-site-verification=6lN8x2y... or github-verification-code=abc123....
2. You publish the token as a TXT record: In your DNS management dashboard (like is-cool-me's DNS editor), you create a new TXT record. For domain-level verification, you leave the hostname field empty or set it to @. For subdomain verification, you set it to the subdomain name.
3. Platform queries DNS: The platform's verification service performs a DNS lookup for TXT records at your domain or at a specific challenge subdomain. It checks whether the returned TXT values match the expected token.
4. Verification confirmed: If the token matches, the platform considers the domain verified. You gain access to the platform's features for that domain.

Step-by-Step: Verify a Domain in Google Search Console

This walkthrough uses Google Search Console, but the steps are similar for any platform.

1. Get the Verification Token

Go to Google Search Console. Add your property and select "DNS TXT record" as the verification method. Google displays a verification string like:

google-site-verification=6lN8x2y3Z4aBcDeFgHiJkLmNoPqRsTuVwXyZ012345

Copy the entire string exactly. Do not add quotes, spaces, or extra characters.

2. Add the TXT Record in Your DNS Dashboard

In the is-cool-me dashboard (or your DNS provider's dashboard):

• Type: TXT
• Name/Host: Leave blank (or @) to verify the root domain. Use a subdomain name if verifying a subdomain.
• Value: Paste the exact verification string from Google.
• TTL: 300-3600 seconds is fine. Verification records do not need long TTLs.

3. Verify the Record Is Published

Before clicking "Verify" in Google Search Console, confirm the record is publicly visible:

dig yourname.is-pro.dev TXT +short

You should see the verification string in the output. If it does not appear, wait a few minutes and try again. DNS propagation for new records is usually fast because no resolver has cached a previous value.

4. Click Verify in Google Search Console

Once dig confirms the record is live, click the "Verify" button in Google Search Console. Google queries your DNS and confirms the token matches. The verification is instantaneous once the DNS record is visible.

5. Keep or Remove the Record

Google periodically re-checks verification. If you remove the TXT record, Google will eventually mark your property as unverified (though it may take weeks or months). For Search Console specifically, you can safely remove the TXT record after verification and use an alternative verification method (like the HTML file or Google Analytics code) for ongoing ownership proof.

Why Verification Records Are Safe

A common concern is whether adding a TXT record for verification creates a security risk. The answer is no, and here is why:

• TXT records do not affect routing: Unlike A, CNAME, or MX records, TXT records have no impact on how traffic reaches your server. They are purely informational.
• Verification tokens are single-purpose: The token only proves domain ownership to the specific platform. It cannot be reused for authentication, authorization, or access to your systems.
• No performance impact: DNS resolvers handle TXT records like any other record. A small TXT record adds negligible overhead to DNS responses.
• Easy to revoke: If you are concerned about a verification record, simply delete it from DNS. The platform will eventually lose verification (or you can re-verify with a new token).

How to Clean Up Verification Records

Over time, you may accumulate dozens of verification TXT records from various platforms. While they are harmless, they clutter your DNS configuration and make it harder to audit. Here is how to clean them up:

1. Identify the record: Look at the TXT record value. Verification tokens usually contain the platform name (google-site-verification, github-verification-code, ms-domain-verification, stripe-verification).
2. Check if still needed: Log into each platform and check whether the domain is still verified. If you no longer use the platform, the record can be removed.
3. Remove from DNS: Delete the TXT record from your DNS dashboard.
4. Verify the platform still works: After removal, check that the platform still functions. Most platforms cache verification status and do not re-check immediately.

Troubleshooting Verification Failures

Verification failures are frustrating but almost always have a simple cause:

"TXT Record Not Found"

• Wrong hostname: Some platforms require the record at a specific subdomain like _googleconsole.yourname.is-pro.dev or _github-challenge-yourname.is-pro.dev. Double-check the exact hostname the platform expects.
• Propagation delay: New records propagate quickly, but some resolvers may take a few minutes. Use dig @8.8.8.8 yourname.is-pro.dev TXT to query a resolver that you know should have the latest data.
• Incorrect TTL: If you set TTL too low, the resolver may have checked between propagation and verification. Set TTL to at least 300 seconds.

"Verification Value Mismatch"

• Copy-paste errors: Some platforms include quotes or special characters in the verification string. Copy the value exactly, including hyphens, underscores, and equals signs. Do not add your own quotes unless the platform explicitly says to.
• Multiple TXT records: If you already have TXT records at the same hostname (e.g., an SPF record), the platform may find multiple values. Ensure the verification token is present among them. Some platforms only check for an exact match of the entire record.
• Split values: Some DNS providers split long TXT values across multiple quoted strings. If your provider does this for very long verification tokens, the platform may not be able to reconstruct the original value. Check with dig to see exactly what the provider is publishing.

"Domain Already Verified by Another User"

This occurs when someone else previously verified the same domain (or subdomain) on the same platform. This is common with shared hosting or subdomain services like is-cool-me. Contact the platform's support to request verification reset, or verify a unique subdomain that only you control.

"Verification Passed but Feature Not Working"

The TXT record verified successfully, but the platform's feature (email sending, API keys, etc.) does not work. The verification step only proves domain ownership. You may still need to configure additional DNS records (MX, SPF, DKIM, CNAME) depending on the feature. Check the platform's documentation for the specific feature you are enabling.

Maintaining a Clean TXT Record Inventory

As your domain accumulates TXT records over time, keeping them organized prevents future issues:

• Use descriptive record names when possible. Instead of a generic "TXT record," label it in your DNS provider's notes field as "Google Search Console verification" or "Mailgun SPF."
• Periodically (every 6-12 months), audit your TXT records. Remove entries for platforms you no longer use.
• Document which records are critical (SPF, DKIM, DMARC) and which are optional (verification tokens). This helps during troubleshooting.
• Monitor your DNS for unexpected TXT records. A sudden new TXT record could indicate unauthorized access to your DNS provider.