Guide
Making sense of a domain's TXT records
The TXT record began as a place for free-form notes and became the Swiss army knife of DNS. Email authentication uses it, so do certificate authorities and almost every software-as-a-service product that needs proof you own a domain. Over the years a busy domain collects dozens. The page lists them and says what each one is for.
What you will find there
Common kinds include SPF (v=spf1 …) listing who may send mail; DMARC (v=DMARC1; …) at the _dmarc subdomain; DKIM keys at selector._domainkey; MTA-STS and TLS-RPT markers; BIMI logos; and verification strings from Google, Microsoft, Facebook, DocuSign, Atlassian, Adobe and many others that prove control of the domain. The page labels each by matching the start of the value against these formats, and gives a one-line explanation. Anything it does not recognise is labelled “Other: free-form text with no standard meaning”.
How long values are stored
DNS limits one character string to 255 bytes. A longer value, such as a 2048-bit DKIM public key, is split across several strings in one record, and the reader concatenates them with nothing between. Some tools display the pieces in quotes separated by spaces; the page joins them so the text is complete and shows its total length in a column. Cloudflare and Google format their JSON answers differently, with quotes or without, and the page normalises both.
Looking up other names
The lookup is for any name, not only the domain itself. Type _dmarc.example.com to read a DMARC policy, selector1._domainkey.example.com for a DKIM key or _mta-sts.example.com for the policy marker. For these purposes the dedicated checkers do more analysis, but the raw lookup is the quickest way to see exactly what is published. A name with no TXT records shows an empty table with the resolver status, which distinguishes a missing name (NXDOMAIN) from a name that exists but has no TXT.
Housekeeping
Large TXT sets cause two real problems. The first is size: many records at the apex push a UDP DNS answer past the limit, so resolvers retry over TCP, and misconfigured networks drop the retry. The second is hygiene: only one SPF record is allowed per name, and two records starting with v=spf1 make SPF fail for the domain. If the table shows two, merge them. Old verification strings can be removed once the service no longer needs them.
A worked example
Press Sample to look up google.com. The table lists the TXT records with a kind such as “Microsoft 365 verification”, “Facebook domain verification”, “DocuSign verification”, “SPF” and “Google site verification”, each with its text, length and TTL. The SPF line reads v=spf1 include:_spf.google.com ~all, a 35-character record; “Other” marks values the page cannot identify. The exact set changes whenever the owner adds or removes a service.
Limits
Labels are guesses based on the beginning of each value, not checks that the record is valid or the service still exists. The page reads one name at a time and does not search subdomains for you. For analysis of the records that matter for mail, use the SPF Record Checker, DMARC Checker or DKIM Record Checker.
Related tools
- SPF Record Checker counts lookups and follows includes.
- DMARC Checker grades the policy at the _dmarc name.
- DKIM Record Checker inspects the key behind a selector.
- DNS Lookup shows all common record types together.
Checked against the current version of the TXT Record Lookup on .