TXT records are the Swiss Army knife of DNS—used for email authentication, domain verification, security policies, and more. Yet their flexibility often leads to bloated, conflicting, or stale records that silently break mail delivery. This guide covers every major TXT use case, the 255-byte string limit, and management best practices.
What Are DNS TXT Records?
A TXT record stores arbitrary text data in DNS. Originally intended for human-readable notes, TXT records are now the primary mechanism for machine-readable metadata: email authentication policies, domain ownership verification, and security directives.
📖 Definition — A TXT record associates free-form text strings with a DNS name. Multiple TXT records can exist at the same name, and each record can contain multiple character strings concatenated together.
Email Authentication TXT Records
The majority of TXT records in production zones exist for email security. Here are the key protocols:
| Protocol | Record Location | Purpose | Example |
|---|---|---|---|
| SPF | example.com | Authorize sending IPs | v=spf1 include:_spf.google.com ~all |
| DKIM | selector._domainkey.example.com | Public key for signature verification | v=DKIM1; k=rsa; p=MIGfMA0G... |
| DMARC | _dmarc.example.com | Policy for SPF/DKIM failures | v=DMARC1; p=reject; rua=mailto:... |
| BIMI | default._bimi.example.com | Brand logo in email clients | v=BIMI1; l=https://example.com/logo.svg |
| MTA-STS | _mta-sts.example.com | Enforce TLS for inbound SMTP | v=STSv1; id=20260101T000000 |
Domain Verification Tokens
Cloud providers and SaaS platforms use TXT records to prove domain ownership. You add a provider-specific token and they query DNS to confirm control.
| Provider | Record Name | Token Format |
|---|---|---|
| Google Workspace | example.com | google-site-verification=XXXXXXXXXX |
| Microsoft 365 | example.com | MS=msXXXXXXXX |
example.com | facebook-domain-verification=XXXXXXXXXX | |
| Adobe | example.com | adobe-idp-site-verification=XXXXXXXXXX |
| Atlassian | example.com | atlassian-domain-verification=XXXXXXXXXX |
💡 After domain verification is complete and the provider confirms ownership, check whether the verification token can be safely removed. Some providers re-verify periodically—consult their documentation before deleting.
Security & Policy TXT Records
DANE (TLSA)
While DANE uses the TLSA record type (not TXT), it works alongside DNSSEC-signed zones to pin TLS certificates for SMTP, reducing reliance on CAs.
DNSBL
DNS-based blocklists use TXT records at lookup names to return human-readable reasons for blacklisting: 2.0.0.127.zen.spamhaus.org TXT "Listed in SBL; see https://...".
CAA
Certificate Authority Authorization (CAA) records (a dedicated record type) restrict which CAs can issue certificates for your domain—often configured alongside TXT-based security records.
The 255-Byte String Limit
Each character string within a TXT record is limited to 255 bytes (RFC 1035 §3.3.14). However, a single TXT RDATA can contain multiple concatenated strings:
; Zone file with concatenated strings
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com "
"include:sendgrid.net include:mail.zendesk.com ~all"
; The resolver concatenates both strings into a single value:
; v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mail.zendesk.com ~all⚠️ Most DNS providers handle string splitting automatically in their UI. If editing zone files directly, ensure each quoted string segment is ≤ 255 bytes and segments are within the same TXT RDATA, not separate TXT records.
TXT Record Management
1. Inventory — List all TXT records with dig example.com TXT +short and document the owner/purpose of each.
2. Categorize — Tag each record: email-auth, verification, security, or legacy.
3. Prune — Remove verification tokens for services no longer in use and decommissioned SPF includes.
4. Validate — Run SPF, DKIM, and DMARC checkers after every change to catch syntax errors.
Best Practices
- Maintain only one SPF record per domain—multiple SPF records cause a PermError (RFC 7208 §4.5).
- Keep SPF records under 10 DNS lookups; use
includeflattening or subdomain delegation for complex setups. - Rotate DKIM keys annually—add the new key, update the signing config, then remove the old key after propagation.
- Document every TXT record with the responsible team and service name.
- Schedule semi-annual TXT record audits to remove stale entries.
Common Mistakes
| Mistake | Impact | Fix |
|---|---|---|
| Multiple SPF TXT records at apex | SPF PermError; mail rejected | Merge into a single record using include: |
| Exceeding 10 SPF DNS lookups | SPF PermError after 10th lookup | Flatten includes or split across subdomains |
| Stale DKIM key after rotation | DKIM validation fails; DMARC alignment breaks | Remove old selector TXT record after cutover |
| Verification tokens left permanently | DNS bloat; potential information leakage | Remove after verification if provider allows |
| Improper string splitting across 255-byte boundary | Truncated or malformed TXT data | Split at word boundaries inside a single RDATA entry |
Tools
TXT Lookup — Retrieve and display all TXT records for a domain.
DNS Lookup — Query any record type for cross-referencing TXT records with other data.
References
- 📄 RFC 1035 — Domain Names: Implementation and Specification (§3.3.14 TXT RDATA)
- 📄 RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
- 📄 RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures
- 📄 RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
🚀 Free ToolZilla tools used in this article
All client-side, no signup, no upload — open them in a new tab while you read:
- 🔧 Txt Lookup — try it free in your browser.
- 🔧 DNS Lookup — try it free in your browser.
- 🧰 Browse all 60+ free tools →
🎯 TXT records power critical email security and domain verification—but they accumulate fast. Maintain a single SPF record, stay under the 10-lookup limit, rotate DKIM keys on schedule, and audit quarterly to prune stale entries.