DNS Records & Concepts
What is a TXT record?
A TXT record, Text record, is a DNS record that stores arbitrary text data associated with a domain name. Unlike A records that map domains to IP addresses or CNAME records that create domain aliases, TXT records have no specific routing function in DNS. They exist as a flexible mechanism for storing text-based information that other systems, email servers, certificate authorities, domain verification services, security scanners, can retrieve and act upon.
The original purpose of TXT records, defined in the DNS specification in 1987, was to allow domain administrators to associate human-readable descriptive text with a domain. In practice this use case never became significant. What TXT records became instead, through years of creative reuse, is the internet’s general-purpose domain information layer. Every major service that needs to verify domain ownership, authenticate email, prove control of a domain, or publish policy information does so through TXT records.
When a service instructs a domain owner to “add a TXT record to your DNS to verify your domain”, whether that is Google Search Console, an SSL certificate authority, an email authentication system, or a redirect management platform, the TXT record is the mechanism. It is the DNS equivalent of putting a specific file on a web server to prove you control it, except it works at the DNS level, before any web server is involved.
How a TXT record works
A TXT record is stored on the authoritative nameserver for a domain alongside its other DNS records. The record has a name, the domain or subdomain it is associated with, and a value, the text string it contains. The TTL controls how long resolvers cache the record.
When a service needs to verify something about a domain it performs a DNS lookup for TXT records at the specified name. The service receives the TXT record values and checks them against what it expects to find. If the expected value is present the verification succeeds.
A TXT record lookup for example.com might return multiple values, one for email authentication, one for domain verification with a specific service, one for another service’s configuration. Multiple TXT records can coexist for the same name because TXT records do not conflict with each other the way some other record types do. Each service checks for its specific value and ignores the others.
The text value stored in a TXT record can be any string of characters up to 255 characters per string. Multiple strings can be combined into a single TXT record for longer values, DNS implementations join them seamlessly when the record is retrieved. In practice TXT record values range from short verification tokens, google-site-verification=abc123xyz: to longer structured strings for email authentication, an SPF record can be a hundred characters or more.
Common uses of TXT records
TXT records are used for a wide range of purposes, more than any other DNS record type. Understanding the most common uses explains why TXT records are encountered so frequently when setting up services for a domain.
Domain ownership verification: the most common reason a domain owner adds a TXT record. Services that need to confirm a user controls a domain before granting access provide a specific TXT record value to add. After the domain owner adds the record the service performs a DNS lookup, finds the value, and confirms ownership.
Examples include Google Search Console requiring a TXT record to verify a property, SSL certificate authorities using TXT records for DNS-based domain validation, and redirect management platforms requiring TXT record verification before activating redirect rules for a domain.
SPF, Sender Policy Framework: an email authentication mechanism that specifies which mail servers are authorised to send email on behalf of a domain. The SPF record is stored as a TXT record at the root domain. When a receiving mail server gets an email claiming to be from @example.com it looks up the SPF TXT record for example.com and checks whether the sending server is listed as authorised.
A typical SPF TXT record looks like:
This says the domain uses the mail provider’s servers for sending and should soft-fail, mark as suspicious rather than reject, any email from servers not listed. Without an SPF record email from the domain is more likely to be treated as spam or rejected by receiving servers.
DKIM, DomainKeys Identified Mail: an email authentication mechanism that uses cryptographic signatures to verify that an email was sent from and not modified in transit by the domain it claims to be from. DKIM public keys are published as TXT records at specific subdomains, typically selector._domainkey.example.com: where selector is a string defined by the email service.
When an email is sent the mail server signs it with a private key. The receiving mail server retrieves the corresponding public key from the TXT record and verifies the signature. A valid signature proves the email was sent by an authorised mail server and was not tampered with in transit.
DMARC, Domain-based Message Authentication, Reporting and Conformance: a policy framework that builds on SPF and DKIM to specify what receiving mail servers should do with email that fails authentication checks. The DMARC policy is published as a TXT record at _dmarc.example.com.
A DMARC record specifies whether to reject, quarantine, or allow failed emails, and optionally where to send reports about authentication results:
SSL certificate DNS validation: when a certificate authority issues an SSL certificate using DNS validation it provides a TXT record value to add at a specific subdomain. The authority checks for the record’s presence to confirm the requester controls the domain before issuing the certificate.
Let’s Encrypt uses this approach for its DNS-01 challenge. The ACME client requests a certificate, receives a challenge token, creates a TXT record at _acme-challenge.example.com with the token value, and the Let’s Encrypt servers verify the record before issuing the certificate.
Google Workspace and Microsoft 365 verification: both services require TXT record verification to confirm domain ownership before configuring custom domain email. Google provides a verification code to add as a TXT record. Microsoft does the same. Neither service activates domain email until the verification TXT record is found.
Service-specific configuration: various services use TXT records for configuration that does not fit other record types. Atlassian products use TXT records for workspace verification. Zendesk uses them for email configuration. Apple uses apple-domain-verification TXT records to verify domains for App Site Association. The pattern is consistent, the service provides a specific string to add as a TXT record and checks for it when the configuration is activated.
Security scanning and disclosure: some organisations publish security contact information as TXT records following a standard like security.txt adapted for DNS. This allows security researchers to find contact information for reporting vulnerabilities without needing the web server to be reachable.
TXT records and redirect management
TXT records appear in redirect management in two specific contexts, domain ownership verification and SSL certificate provisioning.
Domain ownership verification: when connecting a domain to a redirect management service the platform often requires confirming the domain owner has authorised the connection. One verification method is adding a TXT record with a service-provided value at the root domain or at a specific subdomain like _redirect-verify.example.com. The redirect service performs a DNS lookup for the TXT record and checks for its value before activating redirect rules for the domain.
This verification protects against unauthorised domain connections, someone cannot configure redirect rules for a domain they do not control because they cannot add the required TXT record to the domain’s DNS without access to the DNS management interface.
DNS validation for SSL certificates: redirect management platforms that automatically provision SSL certificates for connected domains typically use DNS validation rather than HTTP validation. DNS validation requires adding a TXT record at a specific subdomain, the certificate authority specifies the exact name and value. The redirect platform handles this automatically for domains connected via CNAME using CNAME-based delegation for certificate validation, the platform controls the validation subdomain through the CNAME and can complete validation without requiring manual TXT record additions from the domain owner.
For domains connected via A records rather than CNAMEs the domain owner may need to manually add TXT records for certificate validation, because the redirect platform does not control any part of the domain’s DNS through which it could automate validation.
TXT record format and syntax
TXT records have flexible syntax because their value is arbitrary text. However most uses follow specific structured formats defined by the standards that use them.
SPF records always begin with v=spf1 and contain structured directives:
DKIM records always begin with v=DKIM1 and contain structured key-value pairs:
DMARC records always begin with v=DMARC1 and contain policy directives:
Verification tokens are typically provided exactly as they should be entered, a string of characters that uniquely identifies the verification request:
Multiple strings in one record: TXT records can contain multiple text strings as a single record, enclosed in quotation marks:
DNS implementations join multiple strings seamlessly so the receiving system sees them as one continuous value. This is necessary when a TXT record value exceeds the 255-character per-string limit.
Multiple TXT records for the same name
Unlike CNAME records which cannot coexist with other records of the same type for the same name, multiple TXT records can exist simultaneously for the same domain name. Each TXT record is independent, services look for their specific value and ignore others.
A domain’s root TXT records might include all of the following simultaneously:
Each record serves a different service. The email system reads the SPF record. Google Search Console reads the verification record. Microsoft reads the MS= record. Apple reads its verification record. None interfere with each other.
The exception is SPF, only one SPF TXT record should exist for a domain. Multiple SPF records at the same name cause evaluation failures because receiving mail servers do not know which one to use. If multiple email providers need to be authorised in SPF they must all be included in a single SPF record using include: directives rather than separate records.
TXT record TTL considerations
TTL for TXT records follows the same principles as other DNS record types but has specific implications for the use cases TXT records serve.
For verification records: verification TXT records typically only need to be present long enough for the service to complete its check. Once verification is complete the record can stay or be removed, the service does not continually recheck it for most use cases. Setting a moderate TTL, 3600 seconds, is appropriate.
For email authentication records: SPF, DKIM, and DMARC records are checked on every email delivery. A very low TTL causes frequent DNS queries from mail servers worldwide on every email your domain receives. A high TTL, 86400 or higher, is appropriate for email authentication records since they change infrequently.
For frequently changing records: some services update TXT record values periodically, particularly for SSL certificate renewal using DNS validation. A lower TTL, 300 to 600 seconds, ensures the updated value propagates quickly when changes are needed.
Checking TXT records
TXT records are inspected using standard DNS query tools specifying the TXT record type.
dig command: on Linux and macOS:
Returns all TXT records for example.com. For a specific subdomain:
Adding +short returns just the record values without the additional DNS metadata:
nslookup: on Windows and other platforms:
Online tools: web-based DNS lookup tools show TXT records for any domain and are useful for quickly checking verification records, SPF configuration, and DMARC policies without command line access. MXToolbox and similar email-specific tools provide structured analysis of SPF, DKIM, and DMARC records with validation checks.
Common TXT record mistakes
Multiple SPF records: adding a second SPF TXT record when an existing one already exists for the domain. Multiple SPF records cause email authentication failures. The solution is to merge all SPF content into a single record.
SPF record too long: SPF records that exceed the DNS lookup limit, ten DNS lookups for include: and similar directives, fail evaluation. Reduce the number of include: directives or use IP address ranges directly.
Removing verification records too soon: removing a TXT verification record immediately after passing a one-time check. Some services periodically recheck the verification record and remove access if it is not found. Leave verification TXT records in place unless confirmed the service no longer checks them.
TXT record value not matching exactly: most TXT verification values are case-sensitive and must be entered exactly as provided by the service, including any prefix like google-site-verification=. Even a single character difference causes verification to fail.
TTL too high on records that need to change: a TXT record with a 24-hour TTL that needs to be updated for SSL renewal or a service change takes 24 hours to propagate after the update. Set reasonable TTLs, 3600 for most use cases, that allow changes to propagate within an hour.