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 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