What sits in a TXT record
TXT is the one record type with no fixed meaning, so unrelated things ended up sharing it. A domain that has been in use for a few years usually holds a mail policy, a couple of keys and a pile of ownership tokens for services nobody remembers signing up for. Each of them is recognised by how it starts.
- v=spf1
- The sender policy: which hosts may send mail with this domain in the envelope sender. One domain may publish only one of these. Check the SPF record.
- v=DMARC1
- What a receiver should do with mail that fails SPF and DKIM, and where to send the reports. It is read at _dmarc under the domain, never on the domain itself. Check the DMARC record.
- v=DKIM1
- A public key receivers use to verify the signature on a message. Keys live under a selector name, so there is no single place to look. Check a DKIM selector.
- v=BIMI1
- Where the logo a mailbox may show next to your mail is published, along with the certificate that vouches for it.
- v=STSv1
- The MTA-STS policy id. The policy itself is not in DNS, it is served over https, and this record only changes when that policy changes.
- v=TLSRPTv1
- Where daily reports about failed TLS connections to your mail servers should be sent.
- Ownership tokens
- Strings like google-site-verification= or MS= prove to one service that you control the domain. They do nothing else, and most of them stay in the zone long after the service is gone.
Where each record has to be published
A record in the wrong place is not an error anywhere. DNS answers it happily, no server complains, and the protocol that was supposed to read it simply never looks there. That is why a DMARC policy on the domain itself can sit unused for years while everyone believes DMARC is switched on.
- SPF: on the domain itself, and on every subdomain that sends mail on its own.
- DMARC: at _dmarc.example.com.
- DKIM: at selector._domainkey.example.com, where the selector is the s= value in the DKIM-Signature header of a message you have sent.
- BIMI: at default._bimi.example.com, or under another selector when the mail is signed with one.
- MTA-STS: at _mta-sts.example.com, with the policy itself on the web server.
- TLS reporting: at _smtp._tls.example.com.
This tool queries the domain itself and the well known names above, so a record published at the right name is found and a record published at the wrong one is named as such. DKIM is the exception: DNS holds no list of selectors, so keys cannot be enumerated, only checked one selector at a time. To see every record type of a zone rather than TXT alone, use the DNS record lookup.
The 255 byte limit, and why records look split
One TXT string cannot be longer than 255 bytes. That is a limit of the record format itself, not of any DNS provider. A longer value, which is what a 2048 bit DKIM key or a long policy usually is, is published as several strings inside one record, and every client joins them back together before reading them. The result is the same value, and this tool shows the joined form with its full length in bytes.
It only becomes a problem in a DNS panel that refuses a value over 255 characters instead of splitting it for you. In that case the value has to be entered as several quoted strings, one after another, in the same record. What must never happen is the value being split across two separate TXT records: the two are then read as two independent records, and for SPF or DKIM that breaks the record instead of extending it.