What a TXT record does
A DNS TXT record associates text with a domain name. Many people first encounter TXT records while setting up email authentication, but they also serve a broader purpose: they let a domain owner publish a short value that another system can look up. A service might ask for a TXT record before allowing a domain to be connected to an account, for example.
Think of a TXT record as a public note at a specific DNS name, not as a private storage field. Anyone who knows where to look can query it. The text may be a label, an instruction in a format understood by a particular service, or a verification value supplied during setup. DNS publishes the value; the service decides what that value means.
How domain verification uses TXT records
A common verification flow starts when a service gives you a DNS name and a value to publish. You add a TXT record through the DNS provider that manages your domain’s authoritative nameservers. The service then queries DNS for that name and checks whether the expected value appears. Publishing it shows that you have enough control over the domain’s DNS settings to complete that step.
For a fictional domain, a service might request a TXT record at _verify.example.test with the value service-check=sample-value. In a DNS editor, the name field might require the full name, _verify.example.test, or only the relative part, _verify. Interfaces differ, so check how your provider displays existing records before saving. Enter the supplied value exactly; spaces, punctuation, and letter case can matter to the service checking it.
Verification values are not usually passwords, but they are publicly readable and may remain useful to the service that issued them. Treat them as account-related setup data: use only values from a service you intend to connect, and follow that service’s guidance before removing a record after verification.
Other useful text, and the limits of TXT
TXT records can carry service-specific configuration as well as proof of control. A tool may request a short identifier or a structured string at a particular name so it can find settings associated with your domain. Some domain owners also use TXT records for brief human-readable notes. These uses work best when the intended reader knows both the DNS name to query and how to interpret the text.
TXT is not a general-purpose place for website content, secrets, or large documents. DNS answers are public, and different applications may interpret the same text differently. Long values can also be awkward: a DNS TXT record can contain multiple character strings, while software may treat those strings as one value. If a provider asks you to split a long value, follow its instructions rather than guessing where to break it.
One name can have multiple TXT records. That flexibility is useful, but it also makes careful editing important. An email-related TXT record at the root of a domain, for instance, should not be replaced merely because another service requests a verification record at the same name. Add the new value as a separate record if the instructions call for one, and check whether the DNS editor supports that arrangement.
A careful way to add and check a record
Before changing DNS, copy the service’s requested record type, name, and value into a private setup note. In your DNS editor, confirm that you are working in the correct domain and that the record type is TXT. Compare the proposed name with nearby records to see whether the editor automatically appends the domain. Then paste the value, review it for accidental spaces or missing characters, and save.
A record’s time to live, or TTL, tells DNS resolvers how long they may cache an answer. New or changed records may therefore take time to appear consistently in lookups. If verification does not succeed immediately, inspect the TXT answer for the exact requested name using a DNS lookup tool. Check whether the value is present before repeatedly changing the record.
If the lookup shows nothing, confirm that you edited the provider responsible for the domain’s active nameservers and that the name was not duplicated, such as _verify.example.test.example.test. If the lookup shows an unexpected value, compare it with the service’s instructions character by character. A successful DNS lookup only confirms that the record is published; the service must still accept it.
Keep TXT records understandable over time
As a domain gains services, its TXT records can become difficult to recognize. Keep a simple inventory of each record’s name, purpose, and associated service, without storing account passwords alongside it. When a service is retired, check whether its TXT record is still needed before deleting it. Leave unrelated records in place, especially those used for email.
The safest habit is to treat each TXT request as a precise DNS change rather than a generic text field. Know who asked for the record, publish it at the specified name, confirm what DNS returns, and revisit it when the service is no longer in use.
