concept Domains & DNS
DNS TXT record
A DNS TXT record holds textual data at a DNS owner name.
What it means
A DNS TXT record holds textual data at a DNS owner name. Its RDATA may contain several length-limited character-strings, which a consumer joins inside that one record without inserting spaces. Two separate TXT records at the same name are not two chunks of a single value. TXT is used by many protocols and domain-verification workflows; DNS itself does not know whether an individual text value means SPF, a verification token or something else. TXT records are publicly retrievable; they are not secret-storage locations.
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.
TXT records: one RDATA or several?
Choose which application consumes the TXT RRset, then inspect chunks without merging different records.
The verification consumer ignores unrelated TXT values; text storage is public and is not a place for secrets.
| Observation | Model value |
|---|---|
| Record count | 2 |
| Chunks of selected example | verify=demo-123 |
| Joined RDATA | Not applicable: 2 independent TXT records |
| Individual RDATA values | record 1: verify=demo-123 | record 2: v=spf1 -all |
| Consumer matches | 1 |
Local, bounded educational fixture. No DNS, mail, certificate, network, socket or external request is performed.
About this model
One TXT record can contain multiple character-strings; consumers concatenate those strings without adding spaces. Distinct TXT records remain distinct. This bounded ASCII teaching parser does not make DNS queries.
See the article’s protocol sources and model limits. The scene does not alter a real system.
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.
Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.
In practice
For a real read-only review, identify the precise DNS owner and consumer first, then inspect authoritative TXT answers with a trustworthy DNS administration or query tool. Record whether an observed value is one record with multiple strings or several records. Do not paste a production verification secret into this example: the widget uses local invented tokens. When changing TXT in a real account, preserve unrelated SPF, DKIM and service-verification records and verify the intended consumer's outcome through its official workflow.
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
Keep TXT record boundaries separate from character-string chunks inside one record. First identify the owner name and the application consuming the data; a verification token and an SPF policy can coexist without becoming one value. Public TXT is unsuitable for credentials, and no synthetic match proves a live service accepted it.
Frequently asked questions
Editorial questions, answered from the sources listed for this article.
Do two TXT strings always mean two records?
No. Several quoted character-strings may form one RDATA, while separate DNS TXT resource records are independent. Confirm the record boundary in the authoritative answer.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.
- Domain names — implementation and specification
Resource-record RDATA formats (TXT §3.3.14, NS §3.3.11 and SOA §3.3.13). DNS wire/text RDATA, TXT/NS/SOA. Read applicable sections with later updates.
Checked .
- Sender Policy Framework (SPF)
DNS record selection and evaluation (§§3–4); mechanism results (§8). SPF identity, TXT assembly, multiple records, mechanisms, results and DNS-term limits; verify subsequent updates.
Checked .