What Are TXT Records and How Are They Used for Domain Verification?

A TXT (text) record is a type of DNS resource record that lets domain administrators insert arbitrary text into the Domain Name System. Unlike traditional DNS records like A or CNAME that route traffic to IP addresses or other domains, TXT records are primarily used to carry machine-readable data for external services, email authentication, and domain ownership verification.

When a third-party service like Google Workspace, Microsoft 365, or a certificate authority needs to prove you own a domain, they instruct you to add a specific TXT record to your DNS zone. Once published, their automated systems query your nameservers, read the string, and confirm validity.

To check your existing text records or troubleshoot propagation delays instantly, you can use the DNS Lookup tool on XiaTools, which queries global root servers and returns all active DNS entries for your domain in real time.

Anatomy and Syntax of DNS TXT Records

A standard TXT record consists of a host (or name), a Time to Live (TTL), a record type (TXT), and the value itself (the text string). Depending on your DNS host provider's control panel, the exact interface labels might differ slightly, but the underlying structure remains consistent across the internet.

Here is how a typical TXT record looks in zone file format:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

• Host/Name: Usually @ (representing the root domain example.com) or a subdomain like mail._domainkey. Some providers automatically append your root domain if you leave the field blank.
• TTL (Time to Live): The duration (in seconds) that resolvers should cache the record. A value of 3600 (1 hour) or 300 (5 minutes) is common during setup.
• Type: TXT
• Value: The quoted string of data required by the validating service.

Character Limits and Formatting Rules

Historically, DNS TXT records had a strict 255-character limit per string segment. While modern DNS servers and clients support longer strings by automatically chunking multiple strings together, it is still best practice to keep your payloads concise. Always wrap your text strings in double quotes inside standard zone files, though most web-based DNS managers handle the quotation marks automatically in the background.

Primary Use Cases for TXT Records

Text records serve as the Swiss Army knife of domain administration. While they can theoretically store any text, they are officially standardized for specific security and verification frameworks.

1. Domain Ownership Verification

Before issuing an SSL/TLS certificate or granting administrative access to a platform, providers need absolute proof that you control the domain's DNS zone. They will give you a unique token—such as google-site-verification=rX9...—to paste into your DNS settings. Because only the legitimate domain owner can modify the DNS records at the registrar or authoritative nameserver, the presence of this string proves ownership.

2. Email Authentication (SPF, DKIM, and DMARC)

Email spoofing is a major vector for spam and phishing. TXT records power the three pillars of email security:

• SPF (Sender Policy Framework): Specifies which mail servers are authorized to send email on behalf of your domain.
• DKIM (DomainKeys Identified Mail): Adds a cryptographic digital signature to outgoing emails, validated using a public key published in a TXT record.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Tells receiving mail servers what to do if SPF or DKIM checks fail (e.g., monitor, quarantine, or reject).

3. Human-Readable Notes and Policies

Administrators sometimes use TXT records to leave administrative contact information, security policies, or site notices directly in the DNS infrastructure, though this is less common today.

Step-by-Step: Adding and Verifying a TXT Record

To demonstrate how this works in practice, let us walk through adding a domain verification TXT record for example.com using placeholder documentation values (192.0.2.0/24 network context).

Step 1: Log in to Your DNS Provider

Navigate to your domain registrar or DNS hosting provider (such as Cloudflare, Route 53, GoDaddy, or cPanel). Locate the DNS management section, often labeled as DNS Zone Editor, Manage DNS, or Advanced DNS.

Step 2: Create a New Record

Select Add Record and configure the fields with the following details provided by your verification service:

• Type: TXT
• Name / Host: _globalsign-domain-verification (or @ for root verification)
• TTL: 300 (or automatic)
• Value / Text: gs-ver=abcdef1234567890

Save the record. Note that provider names and navigation paths may differ slightly depending on your specific host.

Step 3: Query Your Record via Command Line

Once saved, you can verify that your local or public resolvers can see the new record. Open your terminal or PowerShell and run a dig or nslookup command.

Using dig on Linux or macOS:

dig TXT example.com +short

Sample output:

"v=spf1 include:_spf.example.com ~all"
"gs-ver=abcdef1234567890"

Using PowerShell on Windows:

Resolve-DnsName -Name example.com -Type TXT

Sample output:

Name             Type TTL   Section    Strings
----             ---- ---   -------    -----
example.com      300  Answer     {"v=spf1 include:_spf.example.com ~all"}
example.com      300  Answer     {"gs-ver=abcdef1234567890"}

TXT Record Comparison Table

Record Type	Primary Purpose	Example Target / Value	Typical Host Field	Caching Impact
TXT	Verification & Security Policies	v=spf1 include:mail.example.com ~all	@ or subdomain	Low to Medium (300s - 3600s)
A	Point domain to IPv4 address	192.0.2.1	@ or www	High
CNAME	Alias one domain to another	ghs.googlehosted.com	blog	High
MX	Route mail to mail server	10 mail.example.com	@	High

Common Mistakes and How to Fix Them

Even experienced engineers occasionally stumble over syntax quirks when managing text records. Here are the most frequent pitfalls:

• Conflicting SPF Records: A domain can only have one active SPF TXT record. If you publish multiple v=spf1 strings, receiving mail servers will encounter a permanent error (permerror) and fail authentication. Combine all authorized include mechanisms into a single TXT record.
• Incorrect Host Formatting: Entering example.com into the host field instead of leaving it blank or using @ can result in your DNS manager creating a redundant record named example.com.example.com. Always check how your specific provider handles root domain nomenclature.
• Quotation Mark Mismatch: While some DNS control panels automatically wrap values in quotation marks, others break if you manually include them. Follow your provider's specific inline instructions.
• Propagation Delays: Expect a brief delay before global DNS servers reflect your changes, dictated by your previous TTL settings.

Quick Checklist for TXT Record Deployment

• Confirmed exact string syntax provided by the third-party service.
• Selected TXT as the DNS record type in your host dashboard.
• Configured the correct host name (root @ or exact subdomain string).
• Ensured no duplicate or conflicting SPF records exist.
• Verified propagation using command-line tools or online lookup utilities.