TXT Lookup

What TXT records are used for

A TXT record carries free-form text attached to a name. It was designed for human-readable notes, but in practice it became the general carrier for machine-readable policy and proof of control: SPF lists the servers allowed to send mail for a domain, DMARC publishes a mail-authentication policy, DKIM publishes public signing keys, and cloud, search and certificate providers ask you to add a token to prove you control the domain.

Because so many unrelated systems share the same record type, one name can hold a long, mixed list. This tool fetches the TXT set at the exact name you enter, from the system resolver and from the zone's authoritative servers, and sorts each entry into a class.

How the tool classifies what it finds

Classification is done by looking at the start and shape of each value. It is a reading aid, not validation of the content.

• SPF: a value beginning with v=spf1. The tool counts them and reminds you to evaluate the mechanisms with the SPF checker.
• DMARC: a value beginning with v=DMARC1. DMARC is only read from the _dmarc label under your domain.
• DKIM-looking: a value that starts with v=DKIM1, or has a key tag such as k=rsa; or a long p= public-key string. These are only used at selector._domainkey.example.com.
• Verification tokens and others: everything else, including site-verification strings. The tool shows them as published but does not know which service they belong to or whether they are still needed.

How to read the findings

• More than one SPF record: a risk. RFC 7208 allows exactly one v=spf1 record per name; with two, receivers return a permanent error and SPF fails for every message.
• DMARC-looking value at the wrong name: shown as something to improve, because a DMARC policy anywhere other than _dmarc.example.com is ignored.
• DKIM-looking value outside a selector name: informational. The key exists in DNS but nothing will use it at that name.
• Long records split into several strings: informational and normal. A single character-string holds up to 255 bytes, so longer values, such as DKIM keys, are stored as several strings that readers join together.
• A record over 1000 bytes: flagged as low-severity. A large answer can exceed the usual UDP size, forcing a fall-back to TCP that some networks block, which causes intermittent failures.
• NODATA and NXDOMAIN: NODATA means the name exists but has no TXT. NXDOMAIN means the name does not exist at all, which for a _domainkey or _dmarc name usually means nothing was published there. A timeout or SERVFAIL tells you nothing about the content.

Common TXT problems

• Quoting and copy-paste errors: smart quotes, extra spaces and line breaks pasted from a document change the value. Some DNS panels add surrounding quotes themselves, so a value ends up doubly quoted.
• Split at the wrong place: an SPF or DKIM value divided in the middle of a tag, or with stray characters between the pieces.
• Stale verification tokens: old tokens do no harm individually but they make the set larger and obscure the records that matter.
• Records at the wrong name: a DMARC record entered on the bare domain, or a DKIM key entered without its selector label, never takes effect.
• Lookup limits in SPF: the number of included domains is a separate problem from TXT size. See the SPF guide linked below.

How to change TXT records safely

Editing TXT is risky mainly because the SPF and DMARC values affect mail delivery immediately and can silently override one another. Always copy the existing value first, edit a single record, and keep the previous text so you can restore it.

When merging two SPF records, combine the mechanisms into one record and delete the others in the same change; leaving both published even briefly breaks SPF. Do not move a DMARC policy to the correct name and tighten it to quarantine or reject in the same step.

1. Copy every TXT value at the name, including the exact punctuation.
2. Change one record at a time and note which service it belongs to.
3. Re-run this lookup and confirm the classification is what you intended.
4. Evaluate SPF or DMARC with the email tools, and test with a real message.
5. To roll back, restore the saved text; the TTL decides how long the old value lingers.

Limits of this test

The tool shows what was published at one name when the scanner asked. It does not evaluate SPF, check DKIM signatures, or read DMARC policy, and it never treats TXT content as proof of authentication. Values shown are untrusted DNS data, displayed as plain text. It cannot enumerate other names in your zone, so a token published at a different label will not appear.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09