What a TXT record is
RFC 1035 defines TXT as free-form text attached to a name, with each record made of one or more strings of up to 255 bytes. The format was meant for human notes, but it became the place where other protocols park their configuration because every DNS host can create one. A typical apex today carries an SPF policy such as v=spf1 include:_spf.google.com -all plus a handful of ownership tokens such as google-site-verification=abc123.
Longer values are stored as several strings in one record. A 2048-bit DKIM public key does not fit in 255 bytes, so the zone holds it as two quoted pieces that receivers concatenate. This tool shows each record as one line of text, so you see the whole value rather than the raw quoting.
Which name to query
Most TXT records are not at the apex. DMARC policies live at _dmarc.example.com, DKIM keys at selector._domainkey.example.com where the selector is chosen by the sender, MTA-STS at _mta-sts.example.com, TLS reporting at _smtp._tls.example.com, and BIMI at default._bimi.example.com. Query the exact name a receiver would use. The tool accepts labels that start with _ for this reason.
If you do not know the selector, look at a message's DKIM-Signature header, where the s= tag names it, or paste the headers into the Email Header Analyzer. Common selectors such as google, selector1, selector2 and k1 are worth trying when the header is not at hand.
Reading the table
Each row shows the Purpose label, the full text and a Copy button. The TTL column is blank for TXT records: the resolver interface used by this tool returns TTLs only for address records, so the value cannot be shown. The summary line counts the records and the lookup time, and Copy Records produces zone-file style lines you can paste into a ticket or a zone editor.
No TXT records is a real answer: the public resolvers returned NODATA or NXDOMAIN for that name. The notice suggests the _dmarc and _domainkey names in case you queried the apex by mistake. An error message, rather than an empty table, means the query failed outright (SERVFAIL, a timeout, or a name that failed validation), so the records may exist and you should retry.
Mistakes the lookup exposes
Duplicate SPF records are the top finding, usually created when a second mail vendor's instructions said add this record and nobody merged it into the existing one. A record saved with literal quotation marks inside the text, or with the v=spf1 prefix missing, shows up here exactly as resolvers see it, which is often the first time anyone reads it back. Stale verification tokens for services the company left years ago are harmless but inflate the response and make audits harder.
Records placed at the wrong name are the other classic: a DMARC policy pasted at the apex, or a DKIM key at _domainkey.example.com without the selector. The Purpose label makes these stand out because a DMARC label at the apex should never appear.
- Two SPF rows: merge the include mechanisms into one record ending in -all or ~all.
- DMARC label at the apex: move the record to _dmarc.example.com.
- Key shown with a gap in the base64: check the zone editor split the strings correctly rather than inserting a space.
- Tokens for retired services: delete them after confirming the service is gone.
What this tool leaves to its neighbours
The lookup shows raw text. It does not evaluate it. Whether an SPF record stays within the ten-lookup limit, whether a DMARC policy is enforced, or whether a DKIM key is 1024 or 2048 bits are questions for the SPF Checker, the DMARC Checker and the DKIM Checker. Answers come from the caches of public resolvers, so after a change use the DNS Change Analyzer with the TXT type to see which resolvers still hold the old text.