The Technical Foundation and Syntax of TXT Records
A TXT record associates one or more strings of text with a DNS name. The record type is generic—DNS has no opinion on what the text contains or what it means. The meaning is defined entirely by the application that queries for and processes the record. This "unstructured" nature is precisely what makes TXT records so versatile; any service can invent its own protocol using TXT records without needing to update global DNS standards.
Each TXT record consists of one or more quoted strings. Individual strings are limited to 255 characters by the underlying DNS protocol. For values longer than 255 characters, the value is split across multiple strings within the same record. DNS resolvers and applications are responsible for concatenating these strings together upon retrieval to form the full configuration value.
; TXT record over 255 characters — split into multiple strings
; DNS concatenates these automatically on retrieval
example.com. 3600 IN TXT
"v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com"
" include:amazonses.com include:_spf.salesforce.com ~all"
DNS allows multiple TXT records at the same name. This is a crucial feature that allows a domain to have an SPF record, multiple verification tokens, and miscellaneous service identifiers all living at the "apex" (example.com) simultaneously. When a resolver queries for TXT records, it receives the entire set and must filter through them to find the specific prefix (like v=spf1 or google-site-verification=) relevant to its needs.
However, this flexibility has practical limits. As the number of TXT records grow, the size of the DNS response increases. If a response exceeds 512 bytes, it may trigger a fallback from the fast UDP protocol to the slower TCP protocol. While most modern networks handle this correctly, maintaining a lean zone by removing stale verification tokens is a best practice for domain performance.
Email Authentication Stack: SPF, DKIM, and DMARC
Email security is by far the most dominant use case for TXT records today. Three protocols—SPF, DKIM, and DMARC—form a "trinity" of authentication that works together to prevent domain spoofing and improve deliverability. Each of these protocols uses TXT records to publish their specific rules and public keys to the internet.
SPF (Sender Policy Framework) identifies which IP addresses and services are authorized to send email on behalf of your domain. It is published at the zone apex. Notably, RFC 7208 prohibits having more than one SPF record at a single name. If you have multiple v=spf1 records, verification will return a permerror, effectively breaking your email authentication.
; CORRECT — all sources in one record
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
DKIM (DomainKeys Identified Mail) uses a more decentralized approach. Instead of a single record at the apex, it uses "selectors" to allow for multiple different keys. This is helpful for organizations that use different providers (e.g., Google for corporate mail and SendGrid for marketing). Each key is published at a subdomain prefixed with _domainkey.
; DKIM record format
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIB..."
DMARC (Domain-based Message Authentication) acts as the "manager" of the stack. It is published at the _dmarc subdomain and tells receiving servers how to handle mail that fails SPF or DKIM checks. It also specifies where to send audit reports (rua and ruf tags). Without a DMARC record, your SPF and DKIM policies are essentially "advisory"—DMARC provides the enforcement instructions that mail servers need to take action against spoofers.
| Protocol | Record Location | Primary Function |
|---|---|---|
| SPF | example.com | Authorize sending IP addresses |
| DKIM | s1._domainkey.example.com | Publish public cryptography keys |
| DMARC | _dmarc.example.com | Instruct servers on failure handling |
For a deep dive into setting up these records, see our SPF Record guide and DMARC Policy Enforcement guide. Proper configuration of these TXT records is the first and most important step in protecting your brand's email reputation.
Domain Ownership Proofs and Certificate Validation
Outside of email, TXT records are the industry standard for "Domain Ownership Verification." When you sign up for a service like Google Search Console, Microsoft 365, or Atlassian, the service needs to know you actually control the domain before displaying private data. They provide a unique string that you must publish as a TXT record. The service then queries your DNS to "prove" you have administrative access.
These tokens are generally safe to accumulate at the zone apex. Unlike SPF, there is no limit on how many verification tokens you can have. However, many administrators forget to clean these up after the verification is complete. While harmless, they contribute to "DNS bloat."
- Google:
google-site-verification=abc... - Microsoft:
MS=ms... - Atlassian:
atlassian-domain-verification=xyz... - Zoho:
zoho-verification=zb...
Another high-stakes use case is ACME DNS-01 validation, used by Let's Encrypt to issue SSL certificates. While many certificates are issued via HTTP proof (loading a file on the web server), some scenarios—like wildcard certificates (*.example.com)—require DNS proof. The ACME client creates a temporary TXT record at _acme-challenge.
_acme-challenge.example.com. 300 IN TXT "ePWS6xJnNImdE0bHnqHZMsGGJkB8XY..."
Because wildcards cannot be validated via HTTP, TXT records are the only way to automate the issuance of broad security certificates across an entire infrastructure. Most modern ACME clients (like Certbot or Lego) can automatically create and delete these TXT records using your DNS provider's API, ensuring that your certificates stay current without manual intervention.
💡 Tip: If you are using a CNAME for your website (common with CDNs), you might be unable to add TXT records at the apex due to CNAME collision rules. In these cases, check if your provider supports "CNAME Flattening" or offers a dedicated verification path.
Extended Security Standards and Service Identifiers
As the internet has become more security-focused, several new standards have emerged that rely exclusively on TXT records for configuration. One such standard is BIMI (Brand Indicators for Message Identification). BIMI allows your brand logo to appear directly in the inbox of supporting email clients, but only if you have a valid BIMI TXT record (and a strong DMARC policy).
; BIMI record pointing to an SVG logo
default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/logo.svg;"
Another pair of records, MTA-STS and TLS-RPT, work together to enforce encrypted connections between mail servers. MTA-STS uses a TXT record to "signal" to other servers that your domain supports (and requires) TLS encryption. TLS-RPT provides a mechanism for those servers to report back to you if the encryption fails.
| Record Type | Location | Purpose |
|---|---|---|
| BIMI | default._bimi.example.com | Display brand logos in email clients |
| MTA-STS | _mta-sts.example.com | Enforce TLS encryption for inbound mail |
| TLS-RPT | _smtp._tls.example.com | Receive reports on encryption failures |
Even specialized services use TXT records for "Domain Association." For instance, Apple Push Notification Service (APNs) requires a TXT record to associate a server with a specific developer team. Cisco Umbrella and other DNS-based security filters use them to verify that a client's network is allowed to route traffic through their scrubbing centers.
The proliferation of these records reflects a shift in how we manage internet identity. Instead of building new DNS record types for every new technology, we use TXT records as a "key-value store" that is accessible globally. This has centralized most of a domain's technical "policy" into a handful of strings that are easy to view but difficult to spoof.
Auditing Methodology and Troubleshooting Common Issues
Given how "busy" a typical zone's TXT records can be, periodic audits are essential. The most common technical error is the Duplicate SPF record. Because many people treat TXT records as "add-only," they often paste a new SPF record underneath the old one. As mentioned previously, this results in an immediate authentication failure for almost all receiving mail servers.
A second common issue is Syntax Errors. Unlike A or MX records, which have very rigid structures, TXT records are just strings. A missing quote, a missing semicolon, or a typo in a tag like p=quarantine (accidentally written as p=quarintine) will cause the entire policy to be ignored.
# Audit Step 1: List all Apex records
dig TXT example.com +short
# Audit Step 2: Check for DMARC at the specific prefix
dig TXT _dmarc.example.com +short
# Audit Step 3: Check for "Ghost" DKIM selectors
# These are selectors for providers you no longer use
dig TXT google._domainkey.example.com
When auditing, you should look for "Ghost Records"—verification tokens or DKIM selectors for services you stopped using months or years ago. While they don't explicitly break anything, they make your DNS responses larger and can confuse other administrators during a migration.
- Check Lookups: Ensure your SPF record doesn't trigger more than 10 DNS lookups.
- Check Propagation: Use an anycast DNS checker to ensure your TXT records have spread across all global nodes.
- Check Formatting: Verify that 2048-bit DKIM keys are correctly split across 255-character strings.
💡 Tip: If you are troubleshooting an email deliverability issue, always start with a TXT record audit. Over 80% of authentication failures are caused by typos or duplicate records in the TXT layer of the DNS.
Frequently Asked Questions
Q: Can I have too many TXT records at the same name?
Theoretically, yes. While there is no hard count limit, very large DNS responses (over 512 bytes) can have trouble passing through some firewalls or older DNS resolvers that don't support TCP fallback. As a rule of thumb, if you have more than 20 TXT records at the apex, it's time to clean out the stale verification tokens for services you no longer use.
Q: Why does my DKIM record have two sets of quotes?
This is due to the 255-character limit for individual strings within a TXT record. If your public key is long (like a 2048-bit key), your DNS provider or zone file must split it into two strings. On retrieval, your computer joins them back together. If you see two sets of quotes, it's a sign that the record is correctly following the DNS specification for long strings.
Q: Is it safe to leave my verification tokens public in DNS?
Yes. Verification tokens are designed to be public. They are not passwords; they are merely "proof of access" codes. Knowing your Google verification string doesn't give a hacker access to your account—it only proves to Google that whoever set that record had access to your DNS manager at the time.
Q: What is the difference between a TXT record and an SPF record?
Historically, there was a dedicated "SPF" record type. However, it was depreciated years ago. Today, all SPF records are simply TXT records that happen to start with the prefix v=spf1. If your DNS provider still shows an "SPF" record type option, it is best to ignore it and use the "TXT" type instead for maximum compatibility.
Q: How do I handle a TXT record that needs to be longer than 255 characters?
You must split the value into multiple quoted strings. For example: "first 255 characters" "the next 255 characters". Most modern DNS control panels handle this automatically—you just paste the long string, and the system formats it for you. You can verify if it's correct by running dig TXT [name] and looking for multiple quoted strings in the response.
Q: Why isn't my DMARC record working?
The most frequent reason is publishing it at the "root" level (e.g., example.com) instead of at the specialized _dmarc subdomain. Mail servers only look for the DMARC policy at _dmarc.yourdomain.com. If you've placed the record at the root apex, it will be completely ignored by all email receiving systems.
Next Steps
Use our TXT Lookup tool to retrieve all TXT records for your domain and identify potential issues. For specialized audits, use the SPF Checker and DMARC Checker to verify your syntax against current standards.
For more information on the specific protocols mentioned here, see our DKIM Explained guide or our ACME Validation guide.
Browse all DNS guides on DNSnexus for related topics.
Related Guides
- SPF Record Explained: Setup, Syntax, and the 10-Lookup Limit
- DKIM Explained: How It Works and How to Verify
- DMARC Policy Enforcement: Moving Safely from monitoring to reject
- MX Records Explained: How Email Routing Works and How to Validate Yours
- SOA Record Explained: What Every Field Means and Why It Matters