TXT Record — DNS Record Type Reference

What it's for

A TXT record stores arbitrary text data attached to a hostname. It was originally designed as a generic free-text field, but in practice it's become the backbone of two huge categories of modern DNS usage: domain ownership verification (proving to a service you control a domain) and email authentication (SPF, DKIM, DMARC — the mechanisms that prevent your domain from being spoofed by spammers).

Because TXT is unstructured, a single domain often has many TXT records simultaneously — one for Google Search Console verification, one for SPF, several for DKIM selectors, one for DMARC, one for a payment processor's domain check, and so on. They all coexist independently.

Format & syntax

example.com.           3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com.    3600    IN    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"
google123abc.example.com. 3600 IN    TXT    "google-site-verification=abc123..."

Name — the hostname the text is attached to. Often the apex for SPF, but frequently a prefixed subdomain (_dmarc., a DKIM selector like selector1._domainkey.) for other purposes — the leading underscore is a convention (RFC 8552) marking "service" records that aren't meant to be regular hostnames.
Value — a quoted string, up to 255 characters per string segment. DNS supports splitting longer values across multiple quoted strings within one record, which resolvers concatenate back together — useful for long DKIM public keys that exceed 255 characters.

Unlike A or CNAME, there's no fixed schema for TXT — the v=spf1..., v=DMARC1... prefixes are conventions defined by the specific standards (SPF, DMARC) that consume them, not enforced by DNS itself.

How it's used in practice

SPF (Sender Policy Framework) — a TXT record at the apex listing which mail servers are authorized to send email as your domain, so receiving servers can reject spoofed messages that didn't originate from an authorized source.
DKIM (DomainKeys Identified Mail) — a TXT record (usually at selector._domainkey.example.com) publishing a public key used to verify a cryptographic signature attached to outbound mail, proving the message wasn't tampered with in transit.
DMARC — a TXT record at _dmarc.example.com declaring a policy for what receiving servers should do when SPF/DKIM checks fail (quarantine, reject, or just monitor), plus where to send aggregate reports.
Domain ownership verification — nearly every SaaS platform, SSL certificate authority, or cloud provider asks you to add a specific TXT record as proof you control the domain before they'll issue a certificate or activate a service.
Miscellaneous machine-readable metadata — some services (like certain service discovery or configuration tools) use TXT records to publish small bits of structured config data directly in DNS.

Common mistakes & gotchas

Multiple SPF records instead of one merged record — SPF explicitly forbids having more than one SPF-type TXT record per domain; if you have two, mail servers may treat SPF as failing entirely (a "permerror"). If you need multiple sources authorized, merge them into a single v=spf1 include:... include:... ~all record instead of adding separate TXT entries.
Exceeding SPF's 10 DNS lookup limit — each include: mechanism in an SPF record triggers its own DNS lookup, and SPF caps this at 10 total lookups. Chaining too many third-party services together (each with their own include:) can silently break SPF validation once you cross that limit.
Forgetting quotes around the value — TXT record values need to be quoted strings; unquoted values can cause parsing issues depending on the DNS provider's UI or zone file syntax.
DKIM key length exceeding the 255-character single-string limit — long RSA public keys need to be split across multiple quoted string segments within the same TXT record. Providers usually handle this automatically, but manually pasted DKIM records from certain generators sometimes get mangled if this splitting isn't done correctly.
Wrong DMARC policy for your stage of rollout — jumping straight to p=reject before you've confirmed SPF/DKIM are correctly passing for all your legitimate mail sources can cause real email to bounce. Most guidance recommends starting at p=none (monitor only), then p=quarantine, then p=reject once you've verified reports look clean.

Comparison & FAQ

Type	Purpose	Key difference from TXT
MX	Routes inbound mail	Structured, single-purpose; TXT holds the outbound authentication data (SPF/DKIM/DMARC) that complements it
CAA	Restricts which CAs can issue certificates	Structured and narrowly scoped, unlike TXT's free-form text
NS	Delegates a subdomain to other nameservers	Structural DNS delegation, unrelated to TXT's arbitrary data role

Can I have multiple TXT records on the same name?

Yes, and it's normal — a domain commonly has TXT records for SPF, domain verification, and other purposes all on the same name simultaneously. The one exception is SPF specifically, which must be a single merged record, not multiple separate SPF-type TXT entries.

Why does my SPF record need to be one record instead of several?

The SPF spec treats multiple SPF TXT records on the same name as an error condition ("permerror"), which can cause receiving mail servers to fail SPF validation entirely rather than picking one. Combine all your authorized sources into a single v=spf1 ... string using include: mechanisms.

What's the maximum length of a TXT record?

Each individual quoted string within a TXT record is limited to 255 characters, but a single TXT record can contain multiple quoted strings that get concatenated, effectively removing the practical length limit for things like long DKIM keys.

Does adding a TXT record for domain verification affect anything else on my domain?

No — TXT records for different purposes coexist independently as long as they're on different names or don't conflict with SPF's single-record rule. Adding a verification TXT record doesn't interfere with existing mail, web, or other DNS configuration.

TXT Text Flagship