DNS TXT record

What it means

DNS TXT records publish text data associated with a DNS owner name. Applications such as SPF interpret some TXT records according to their own syntax, but DNS does not combine all TXT RRsets into one universal policy. A TXT record can contain multiple character strings, and multiple TXT records at one name are different records. TXT wire format SPF rules

Try it

Example — inspect a synthetic TXT RRset. Change the consumer from domain verification to SPF and watch which values are considered. Select the split-SPF fixture to see two chunks form one value; select two SPF records to see the consumer reject the duplicate policy. Edit the short ASCII token locally, then use Inspect TXT records and Reset. Nothing is looked up or published.

How the mechanism works

In a DNS zone, an RRset groups records by owner, class and type. Consider example.com TXT with "verify=demo-123" and separately "v=spf1 -all". A verification service may look for a value beginning verify=, while an SPF evaluator looks for exactly one applicable v=spf1 record for the selected identity. The values can coexist because the consumers have different rules. By contrast, "v=spf1 " "-all" within one RDATA is interpreted as v=spf1 -all: the space belongs to the first character-string, not a separator automatically supplied by DNS.

A TXT character-string is at most 255 octets. Long TXT RDATA may comprise more than one such string; 255 is not a blanket length limit for the entire record or its RRset. Quoting and escaping depend on the zone-file or DNS-provider interface. Treat a provider UI's visual line break separately from the on-wire RDATA structure. When copying a challenge token, check exact bytes and owner name, not appearance alone.

TXT record boundaries in a sample RRset

Suppose the authoritative answer at example.com contains two separate TXT RDATA values:

• Record 1: "verify=demo-123" for a domain-verification service.
• Record 2: "v=spf1 " "-all" — two strings inside one TXT record for an SPF evaluator.

The SPF consumer joins the second record's character-strings into v=spf1 -all, but it must not concatenate record 1 and record 2. Switch the example to two SPF records and the consumer has more than one candidate SPF policy; that is a configuration problem, not a longer SPF value. A provider's display that wraps a record onto two lines is insufficient evidence of two DNS records. Inspect the actual RDATA boundaries before editing or deleting any TXT value.

The owner name and the consumer are separate boundaries

A TXT value does not acquire an application meaning merely because its text looks familiar. For example, example.com TXT "verify=demo-123" and _proof.example.com TXT "verify=demo-123" are records at different DNS owner names. A verification service that queries the second name will not find a value placed only at the first; changing the string is not the same as changing the record's owner.

Likewise, an SPF evaluator selects records at the domain required by the SMTP identity it is checking; it does not join every TXT value beneath an entire zone. Ask which name, which TXT record, and which application rule are in play before diagnosing a missing token or removing another service's record. The lab only joins character-strings within a single record and applies its explicitly selected consumer. DNS record owner/type SPF record selection

In practice

Inspect the full authoritative RRset and distinguish the presentation of quoted chunks from separate records. Preserve unrelated TXT values when changing a specific policy. Validate the consuming application’s syntax against its current standard and the actual DNS output; stop before collapsing or deleting unrelated verification/authentication strings.

Limits and common mistakes

This teaching parser accepts bounded printable ASCII only and deliberately refuses arbitrary quoting, control characters and Unicode. Actual TXT content may have wider encodings and many service-specific validation rules. A TXT answer cannot by itself prove domain ownership, email deliverability or service health. If a provider shows different data than the authoritative zone, stop before deleting anything and first reconcile delegation, caches and UI representation.

Key takeaways

DNS stores records; each application decides what a TXT value means. Count records and character-string parts separately, and verify the consuming protocol before editing an apparently similar value.