Quick answer
A TXT record stores free-form text at a DNS name. Its data is one or more text strings (RFC 1035 §3.3.14), and the meaning of that text depends on whatever service reads it. The dominant use today is email authentication: TXT records carry your SPF policy, DKIM public keys, and DMARC policy, plus domain-ownership verification strings for services like Google Workspace and Microsoft 365. You can publish many TXT records at the same name, but only one of them may be an SPF record beginning v=spf1.
What a TXT record actually stores
The DNS TXT record type has almost no built-in structure. RFC 1035 §3.3.14 defines its data field, TXT-DATA, as "one or more <character-string>s," and says only that TXT records "are used to hold descriptive text" whose semantics depend on the domain where they are found. There is no schema. The format that gives a value meaning — v=spf1 ..., v=DKIM1; ..., google-site-verification=... — is a convention defined by whatever protocol consumes it, not by DNS itself.
The one hard constraint is length. A <character-string> in DNS is a single length octet followed by that many bytes, so a single string can hold at most 255 octets (RFC 1035 §3.3). A TXT record can hold several of these strings back to back, which is how longer values are published: a value over 255 characters is split into multiple quoted strings, and the resolver concatenates them with no separator when it reads the record. RFC 7208 §3.3 states this explicitly for SPF — multiple strings "MUST be treated as if those strings are concatenated together without adding spaces."
This matters most for DKIM. A 2048-bit RSA public key in base64 runs well past 255 characters, so a DKIM record is normally published as two strings:
selector._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
"...restofthebase64key...IDAQAB" )
The two quoted strings join into one key on read. Splitting on a character boundary is fine; the resolver does not care where the break falls. Most DNS providers handle the split automatically when you paste a long value, but some require you to insert the quotes yourself.
What TXT records are used for
Almost every well-known TXT use is a text prefix that a specific protocol looks for at a specific name:
- SPF — a
v=spf1 ...record at the domain name, listing which servers may send mail for it (RFC 7208). - DKIM — a
v=DKIM1; ...public key atselector._domainkey.example.com, used to verify message signatures (RFC 6376). - DMARC — a
v=DMARC1; p=...policy at_dmarc.example.com, telling receivers what to do when SPF and DKIM fail (RFC 7489). - Domain-ownership verification — strings like
google-site-verification=...orMS=...that a provider tells you to publish to prove you control the domain. - BIMI and MTA-STS —
v=BIMI1atdefault._bimi.example.comandv=STSv1at_mta-sts.example.com, for brand logos and enforced TLS.
This page defines the record type, not the protocols. To learn how the three email-authentication records fit together, start with Email authentication explained. To validate what you have published, use the SPF checker, DKIM checker, and DMARC checker, which parse the TXT value and report specific errors rather than just showing the raw string.
Multiple TXT records, and the one-SPF-record limit
Publishing several TXT records at the same name is normal and expected. A Google verification string, a DMARC record, and a DKIM key can all live at their respective names without conflict, and nothing in DNS forbids two unrelated TXT records at the apex.
SPF is the exception. A domain may publish only one SPF record per name — one TXT record beginning v=spf1. If a receiver finds two or more v=spf1 records at the same name, SPF evaluation returns permerror and passes for no message from that domain (RFC 7208 §4.5). Receivers do not merge them or pick one. This usually happens when different teams each add their own SPF record over time. If a check reports more than one SPF record, see multiple SPF records for how to merge them, and SPF too many DNS lookups if the merged record then exceeds the 10-lookup limit.
How to query a TXT record
To read the TXT records at a name, query the exact name the protocol uses, not just the apex. On Windows, run nslookup -q=TXT example.com; on macOS or Linux, run dig TXT example.com +short. For DKIM, query the selector name (dig TXT selector._domainkey.example.com); for DMARC, query _dmarc.example.com.
A few things to watch for in the output. Split values print as separate quoted strings — join them yourself to see the real value, since the resolver would concatenate them. If a value looks truncated in a provider's web UI but complete in a command-line query, trust the query. And if a record you just published does not appear, the old answer may still be cached; wait out the record's TTL before concluding the change did not take.