TXT DNS Record

What the TXT record does

TXT is the least opinionated record type in DNS, and that is why it is everywhere. Anyone publishing a fact about a domain without standardising a new record type puts a string in TXT and defines a leading token — v=spf1, v=DKIM1, v=DMARC1 — so their parser recognises its own data and ignores everyone else’s.

The consequence is a shared namespace with no owner. A busy apex accumulates a policy record, verification tokens from vendors nobody remembers signing up with, and whatever a previous engineer left behind. Nothing marks which strings are still load-bearing, so keep a comment in your zone source recording who asked for each one.

Zone-file syntax and the 255-octet limit

A TXT record’s RDATA is not one string. It is a sequence of character-string values, each prefixed by a length octet, which caps every chunk at 255 octets. Longer values are written as several quoted strings on one line and concatenated on read. Whitespace between a closing and an opening quote is syntax, but a space inside the quotes is data, and that is the usual reason a split DKIM key fails to validate.

; one short string
example.com.   3600   IN   TXT   "v=spf1 include:_spf.provider.net -all"

; a long value split into 255-octet chunks, concatenated on read
sel1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; "
                                           "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A"
                                           "MIIBCgKCAQEAvvvv...IDAQAB" )

; several unrelated records happily share one name
example.com.   3600   IN   TXT   "site-verification=abc123"

Common uses

In practice TXT records do three jobs. They carry mail policy, the bulk of the volume and the reason SPF, DKIM, and DMARC each get their own page here. They prove domain control to third parties. And they answer ACME dns-01 challenges at _acme-challenge, where the value changes on every issuance and the TTL wants to stay low enough that a retry misses the cache.

Troubleshooting

Read the raw answer rather than a control panel’s rendering. Web DNS editors re-wrap, trim, and re-quote long values, so a record that looks correct in a browser may have gained a space at a chunk boundary. Comparing the bytes a resolver returns against the value your vendor supplied settles that in one query.

Size is the other recurring problem. A name carrying a dozen TXT records answers well past the old 512-byte UDP limit, so it depends on EDNS0 or TCP fallback. Middleboxes blocking DNS over TCP turn that into intermittent, source-dependent failures. Prune tokens you no longer need.

# everything published at the name, quoting intact
dig example.com TXT +noall +answer

# just the policy record you care about
dig example.com TXT +short | grep -i 'v=spf1'

# a large TXT set is where truncation and TCP fallback show up
dig example.com TXT +noall +comments        # look for the tc flag
dig +tcp example.com TXT +short | wc -c

The set of TXT records at a name has no defined order

Every TXT record at a busy apex belongs to the same RRset, and RFC 2181 §5.2 is explicit that all records within an RRset must share one TTL and that resolvers are free to return them in any order — an RRset is a set, not a list, and nothing in the specification lets you fix a preferred position for one string among several. A resolver, forwarder, or caching layer between the authoritative server and your application is entitled to reorder the set on every query, and several commonly do exactly that as a side effect of cache rotation or answer randomisation.

This matters specifically for TXT because so much of its use is vendor verification tokens read by automated systems, and a naive integration that grabs “the first TXT record at this name” rather than scanning the whole set for a matching prefix will pass in testing and fail intermittently once a second or third unrelated token accumulates at the same name. The fix is the same discipline the SPF and DMARC specifications already enforce for their own records: parse the entire RRset and match on the leading token — v=spf1, a specific verification prefix, whatever your own scheme defines — rather than assuming position. If you are building anything that reads a domain’s TXT records programmatically, treat order as actively hostile to rely on, not merely unspecified; a query that returns records in one order today can return the same records in a different order on the very next lookup, from the same resolver, with no configuration change on either end.

The defining RFC

TXT is type 16, defined in RFC 1035 §3.3.14, with the character-string encoding that imposes the 255-octet cap given in RFC 1035 §3.3. Storing attribute=value data in TXT is RFC 1464, Experimental and never followed to the letter, though its spirit survives in every v= token in use today. Responses over 512 bytes depend on EDNS0, RFC 6891. Dump a TXT set with the DNS lookup tool.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

TXT record

Zone-file example