TXT is the DNS resource record type that attaches arbitrary text strings to a domain name. Among DNS records it is the general-purpose container: the DNS itself does not interpret the content, so other protocols and services define their own formats inside it, most notably email authentication policies and domain ownership verification tokens.
The TXT type, numbered 16, was defined in the original DNS specification, RFC 1035, for descriptive information. Today the overwhelming majority of TXT data is machine-readable, and a single domain often carries several TXT records at its apex and at specially prefixed names such as _dmarc or selector._domainkey.
How a TXT record stores data
A TXT record contains one or more character strings, each limited to 255 bytes and stored with a one-byte length prefix. Longer values, such as a 2,048-bit DKIM public key, are split into several strings within the same record, and the consuming application concatenates them without separators.
A name can hold multiple TXT records at once. Resolvers return all of them together in one answer, in no guaranteed order, so each consuming protocol must identify its own record by a prefix, such as v=spf1 or v=DMARC1, and ignore the rest.
The structural limits that govern TXT data are summarized below.
| Property | Value or rule | Practical consequence |
|---|---|---|
| Record type number | 16 | Queried as type TXT |
| String length | Up to 255 bytes each | Long values must be split |
| Strings per record | Several, concatenated by the reader | DNS panels may split automatically |
| Records per name | Multiple allowed | Protocols must filter by prefix |
| Response size | Large answers may exceed UDP limits | Falls back to TCP or truncation |
Common uses of TXT records
Most TXT records today serve email security and service verification. Several standards place their policies in TXT because adding a new record type would have required software changes across the whole DNS ecosystem.
| Use | Owner name | Example prefix | Purpose |
|---|---|---|---|
| SPF | Domain apex | v=spf1 | Lists servers allowed to send mail |
| DKIM | selector._domainkey | v=DKIM1 | Publishes the signing public key |
| DMARC | _dmarc | v=DMARC1 | Sets policy and reporting for failures |
| MTA-STS | _mta-sts | v=STSv1 | Signals an enforced TLS policy for mail |
| Domain verification | Apex or random label | Service-specific token | Proves control to a cloud service |
| ACME DNS-01 challenge | _acme-challenge | Random token | Proves control for a TLS certificate |
Using underscore-prefixed names keeps protocol data away from the apex and avoids collisions. This convention is formalized for many services and is the preferred design for any new TXT-based mechanism.
TXT compared with other DNS record types
Unlike A, AAAA, MX or NS records, a TXT record has no meaning to the DNS resolution process itself. Resolvers cache and return it but never follow it, while other types direct traffic or delegate authority.
| Record type | Content | Interpreted by |
|---|---|---|
| TXT | Free-form text strings | Applications and external services |
| A and AAAA | IPv4 or IPv6 address | Clients connecting to a host |
| MX | Mail server name and priority | Sending mail servers |
| CNAME | Alias to another name | Resolvers during lookup |
| SRV and SVCB | Service location and parameters | Protocol-aware clients |
A dedicated SPF record type, number 99, once existed but was deprecated in favor of TXT, because deployment never caught up. This history illustrates why TXT remains the practical choice for new text-based policies despite its lack of structure.
Managing TXT records in practice
Administrators should treat TXT records as configuration with consequences, not as notes. A single mistyped SPF or DMARC value can send legitimate mail to spam folders, and a removed verification token can disconnect a cloud service.
| Task | Recommended practice | Reason |
|---|---|---|
| Adding a mail sender | Edit the existing SPF record | Only one SPF record is allowed |
| Publishing a DKIM key | Use a dated or rotated selector | Allows key rotation without downtime |
| Introducing DMARC | Start with `p=none` and reports | Reveals senders before enforcement |
| Verifying a service | Keep the token while the service is used | Some services recheck periodically |
| Changing a policy | Lower the TTL beforehand | Shortens propagation of the change |
Querying with tools such as dig TXT example.com or nslookup -type=TXT shows exactly what resolvers see, including how long strings were split. Checking the live answer after every change is faster than waiting for delivery reports.
Limits, pitfalls and security concerns
Because TXT records are flexible, they accumulate. Large domains often carry dozens of stale verification tokens, which enlarge responses and reveal which services an organization uses.
- Multiple SPF records: two
v=spf1records cause a permanent SPF error; merge them into one. - SPF lookup limit: SPF evaluation allows at most 10 DNS-querying mechanisms; nested includes exceed it quickly.
- Broken long values: copying a DKIM key with stray quotes or spaces invalidates the signature.
- Oversized responses: very large TXT sets push answers past common UDP sizes and depend on TCP fallback.
- Information exposure: tokens and policies are public and reveal providers and infrastructure.
A periodic audit that removes unused tokens and documents the owner of each remaining record keeps TXT data small, accurate and less revealing.
A non-technical view
A TXT record is like a notice board attached to a domain name. Anyone can read what is pinned there, but the domain owner decides what to post.
Email systems read the board to check which servers may send mail for the domain. Online services ask owners to pin a secret code there to prove they control the domain. The board itself does nothing. Its value comes from the services that read it.
A concrete example
A mid-sized accounting firm discovers that criminals are sending invoices that appear to come from its domain. Its DNS contains only an outdated SPF record that does not list the cloud mail service the firm uses, so genuine mail also fails checks.
The administrator replaces the SPF value with one record that includes the mail provider and the invoicing platform, publishes a 2,048-bit DKIM key under a new selector and adds a DMARC record with p=none and an address for aggregate reports.
After four weeks of reports confirm that every legitimate sender passes, the policy moves to p=quarantine and then to p=reject. Spoofed invoices stop reaching clients, and legitimate mail lands in inboxes reliably.