A DNS TXT record stores text at a DNS name. Applications use that text for tasks such as domain verification or email authentication. One TXT record contains one or more character strings, and two strings inside one record are different from two separate TXT records at the same name.

When reading or publishing TXT data, identify the exact owner name, meaning the DNS name where the record is stored. The intended application and the boundary between records also matter. A DNS provider's edit form may hide that boundary behind text boxes or automatic quoting, so check the published DNS answer as well as the form.

Understand the TXT Record Structure

Every DNS resource record has an owner name, type, class, TTL and data. A TXT record's data consists of one or more strings, each preceded by a field that gives its length. That field occupies one octet, or eight bits, and allows up to 255 octets of content per string. A longer value can use several strings in one record if the consuming application permits that representation.

A simple display might look like _verify.example.com. 300 IN TXT "token=abc123". The name identifies where the example token is stored, 300 is the TTL in seconds, and IN identifies the Internet class. The quoted text is the TXT data; this is an illustrative token, not a live verification value. A token stored at the wrong owner name may not be found by the service checking it.

DNS does not assign one universal meaning to every TXT string. An SPF checker, a DKIM verifier and a site-ownership service can all query TXT data but apply different syntax and validation rules. A DNS lookup can show that a record was published; it cannot by itself prove that a particular application accepted the value.

One Record Can Contain Several Strings

A DNS tool may display a single TXT answer as example.com. 300 IN TXT "part-one" "part-two". In this display, both quoted chunks belong to one resource record. They are separate character strings within that record, and their order matters to applications that combine them.

DNS does not insert spaces between strings for the application. SPF joins the strings within one TXT record without adding any spaces. Under that joining rule, "alpha " "beta" produces alpha beta, while "alpha" "beta" produces alphabeta. A required space must therefore be part of a string, or the joined SPF policy may parse differently.

Other protocols define their own treatment of TXT strings. DKIM also joins them without adding spaces before using the value. A verification service may require an exact token and may or may not accept a split representation. Check that service's current requirements before dividing a long value.

DNS provider interfaces handle record entry differently, so follow the instructions for placing several strings in one record. Some forms expect all of those strings on the same line, while a separate row can create another TXT record. Two text boxes on a screen do not establish how many DNS records were published. An answer from an authoritative nameserver shows the resulting record boundaries.

Several TXT Records Form an RRset

Multiple TXT records with the same owner name and class form a resource record set, or RRset, because their record type is also the same. Each member can contain one or more strings. The records in an authoritative RRset must share a TTL.

For example, one DNS name could hold a TXT record for a verification token and another for a different application. Keep them separate when the applications expect separate values, because joining unrelated records can break both services. A long SPF policy must not be divided into independent SPF records. If a check selects more than one SPF policy at a domain, the result is a permanent error.

In a display that places each resource record on its own line, one line with two quoted strings represents one TXT record with two strings. Two lines that each repeat the owner, TTL, class and TXT type represent separate records. Other tools may wrap lines or group output differently, so use a view that preserves individual resource records if the boundary is unclear.

Publish and Verify the Intended Value

Start with the service's required owner name and value. Check whether it expects one TXT record, whether the value may contain several strings and whether it permits other TXT records at the same owner. Enter the record through the DNS provider that hosts the zone, then query its authoritative nameservers for type TXT at the exact name. A preview or successful form submission does not prove that the authoritative servers return the intended data.

Count the resource records in the answer, then inspect the strings within each record and their order. Check the TTL and the exact value, including spaces and punctuation required by the application. Outer quotation marks in the displayed answer normally delimit strings rather than form part of their stored content. If a resolver still shows old data after the authoritative record changes, its cached TXT RRset may remain until its TTL expires.

For SPF, check that the returned TXT records contain one applicable policy and combine only that record's strings according to SPF's rules. A verification service instead checks for its expected token at the required owner name. Successful DNS retrieval and successful application validation are separate steps.

If a value is missing, compare the authoritative answer with the provider entry and confirm the owner name. A timeout or SERVFAIL means the lookup failed, so it does not prove that the TXT record is absent. If unexpected records appear, check whether the provider created separate records instead of strings within one record. If DNS returns the intended value but the service rejects it, check that service's syntax and validation requirements.