How to Read DNS TXT Records for Domain Verification, Email, and Site Ownership

A DNS TXT record is text attached to a DNS name. That simple definition covers several very different jobs: proving control of a domain to a service, publishing an email-sending policy, publishing a DMARC policy, or providing application-specific configuration. The reliable way to read one is to start with the exact DNS name the service asks for, then identify the record's purpose from its content rather than assuming every TXT value means the same thing.

This guide answers a practical question: how can you inspect a DNS TXT record and tell whether it is the record you actually need?

Start with the owner name, not just the domain

Every DNS record has an owner name—the name at which it is published. A verification service may ask for a TXT record at the root domain, such as example.com, or at a host it specifies, such as _verify.example.com. Email-related records commonly use dedicated names such as _dmarc.example.com.

Those names are not interchangeable. A TXT value added at example.com does not automatically satisfy a request for _verify.example.com, and a correct value at the wrong name is still the wrong DNS record for the task.

Before looking up anything, write down these three items exactly as supplied by the service or administrator:

1. The requested record type: TXT.
2. The complete owner name, including any prefix such as _dmarc or _verify.
3. The complete value or token to publish.

DNS permits more than one TXT record at a name. RFC 1035 defines TXT data as character strings, so seeing several results at the same owner name is not automatically an error. 1 Compare the exact requested value with the returned values instead of expecting a single TXT result.

Recognize common TXT record patterns

The text itself usually indicates which system owns the record. Treat the following patterns as clues, not as a reason to change a record you did not create.

Pattern	Typical purpose	What to check
A service-specific token, often with an = sign	Domain or site verification	The owner name and token match the service's instructions exactly.
v=spf1	SPF email-sending policy	The policy is published at the domain used in the email identity's SPF check.
v=DMARC1	DMARC policy	The record is published at _dmarc plus the domain.
Other vendor-specific text	Application or service configuration	Use that service's documentation for the owner name, syntax, and expected value.

An SPF record is a TXT record beginning with v=spf1. RFC 7208 says that a domain name must not have multiple records that would cause more than one SPF record to be selected; multiple DNS TXT records can exist, but publishing multiple SPF policy records for the same domain can make SPF evaluation return permerror. 2 Do not combine unrelated verification tokens into an SPF policy or add a second v=spf1 record to preserve an older configuration. Review the existing policy and the sending service's documented change instead.

A DMARC record is a DNS TXT record at _dmarc plus the organizational domain and begins with v=DMARC1. 3 It is separate from the root-domain TXT records where SPF or verification tokens may appear.

Check the exact value without rewriting it

For a service-verification token, copy the requested value as a whole. Extra characters, a missing character, publishing only part of the token, or placing the token at a different owner name can prevent verification. If a DNS control panel presents a separate Name or Host field and a Value field, confirm how that provider displays the resulting fully qualified name before saving.

Quotation marks in a DNS lookup display deserve care. DNS software may render TXT character strings with quotes or split a long logical value into multiple quoted chunks. RFC 1035 permits a TXT record to contain one or more character strings. 1 A split display is therefore not, by itself, evidence that the published value is broken. Compare the content according to the service's instructions and the DNS provider's representation; do not insert display quotes into a token unless the provider explicitly requires them as input syntax.

For SPF and DMARC records, avoid editing a policy by visual similarity. Their terms have defined syntax and evaluation rules. Confirm the intended sending service, domain, and policy change in the relevant documentation before changing an email-authentication record. 2 3

Separate publication from resolver caching

When a service says it cannot find a newly added TXT record, first distinguish two questions:

1. Is the record present on the authoritative DNS servers for the intended owner name?
2. If it is present there, is a recursive resolver or the service still returning a cached earlier answer?

Querying an authoritative server for the exact owner name and TXT type checks the first question. Then compare that response with a recursive lookup. DNS responses have TTLs, and caches can continue to use a previous answer until their cached data expires. For a record that was previously absent, negative caching can also affect when resolvers stop returning the previous negative result. RFC 2308 describes negative DNS caching and its use of SOA information. 4

Do not treat a general propagation estimate as proof that a record is correct. Preserve the lookup time, queried name, record type, response code, returned value, and server used. Those details make it possible to tell a misplaced record from a cache-related difference.

A practical TXT record troubleshooting sequence

1. Copy the requested owner name, record type, and value from the service's instructions.
2. Look up that exact owner name as TXT; do not start with the root domain unless it is the requested name.
3. Compare the entire intended token or policy prefix with the returned result.
4. Check for another record with the same role—for example, a second v=spf1 record—before adding or replacing anything.
5. If the record looks absent, verify which DNS provider is authoritative for the domain and whether the change was made in that provider's active zone.
6. If authorities return the expected value but another lookup differs, record TTLs and times and investigate caching rather than creating duplicate records.
7. Return to the requesting service only after its exact owner name and required value are visible in DNS.

The yukt.tools homepage lists DNS lookup among its available utilities. Use a DNS lookup to inspect a non-sensitive TXT response, then keep the owner name and returned values with your troubleshooting notes. A lookup can show published DNS data; it cannot decide whether a third-party service's private verification rules have been satisfied.

Frequently asked questions

Can a domain have more than one TXT record?

Yes. DNS TXT data can contain character strings, and a DNS name can return multiple TXT records. 1 The important question is whether the records are compatible. A domain may have separate verification and email-related TXT records, but SPF has its own rule: multiple SPF policy records that cause more than one record to be selected can result in permerror. 2

Why is my TXT record visible at the root domain but verification still fails?

The service may be checking a different owner name. Compare the requested full name with the name you queried. A record at example.com is distinct from one at _verify.example.com or _dmarc.example.com, even though all are associated with the same domain.

Are TXT record quotes part of the value?

Not necessarily. Lookup tools often display DNS character strings in quotes, and a long record can be displayed in more than one chunk. RFC 1035 allows a TXT record to contain one or more character strings. 1 Use your DNS provider's input guidance and the requesting service's exact instructions; do not add display punctuation to a token by assumption.

Is a DNS TXT record the same as an SPF or DMARC record?

SPF and DMARC policies are commonly published using DNS TXT records, but they have distinct names and defined formats. SPF uses a record beginning with v=spf1; DMARC uses v=DMARC1 at _dmarc plus the domain. 2 3 A generic domain-verification token is another TXT use case, not an SPF or DMARC policy.

Sources and research

1. RFC 1035, section 3.3.14: TXT RDATA format — IETF DNS TXT record definition, accessed 2026-10-18.
2. RFC 7208, sections 3.1 and 3.2: SPF records — IETF SPF record selection and multiple-record handling, accessed 2026-10-18.
3. RFC 7489, section 6.1: DMARC DNS record — IETF DMARC record location and syntax, accessed 2026-10-18.
4. RFC 2308: Negative Caching of DNS Queries — IETF specification for negative DNS caching, accessed 2026-10-18.