What Is a DNS TXT Record?

Most of them, and they are told apart by the name they sit at rather than by their type. SPF sits on the domain itself, DKIM at selector._domainkey.yourdomain.com, DMARC at _dmarc.yourdomain.com, MTA-STS at _mta-sts.yourdomain.com and TLS-RPT at _smtp._tls.yourdomain.com.

MX and PTR are the exceptions, because each is its own record type. Everything a receiver reads as policy is text inside a TXT record, which is why one mistyped name is enough to make a perfectly written record invisible.

A TXT record is made of one or more strings, and a single string may be at most 255 characters, because its length is stored in one byte. A longer value is published as several quoted strings inside the same record.

Resolvers join those strings with nothing between them, so the reassembled value is identical to the original. This is how a 2048-bit DKIM public key fits, split across two strings, and it is why a stray space left at the join is a common reason a key stops verifying.

One command, on any machine. dig +short TXT _dmarc.yourdomain.com returns the value a resolver currently holds, and nslookup -type=TXT does the same on Windows. The name matters more than the flag: querying the domain when the record lives at a prefixed name returns nothing, and reads as a missing record rather than a mistyped query.

When a checker and your DNS panel disagree, ask the authoritative nameserver directly with dig @ns1.yourprovider.com TXT name. That answer is what is actually published, while everything else is a cached copy of what was published earlier, and knowing which of the two you are reading is usually the whole diagnosis.

Almost always caching rather than the record. Every answer carries a TTL, and a resolver that already holds the old value keeps serving it until that time expires no matter what the zone now says. Lowering the TTL before a change, rather than after, is what makes the change fast.

The version that confuses people is negative caching. A resolver asked for a name before the record existed caches the absence too, for a period set in the zone SOA record, so the first checker run after publishing can report nothing and stay wrong for hours. Republishing does not clear it, and neither does deleting and re-adding the record.

Yes, and most zones do at the apex, where domain verification strings from several vendors sit alongside each other. A receiver looking for one specific record reads every TXT record at the name and picks the one carrying the version tag it wants.

SPF is the exception that catches people out. Two records that both begin v=spf1 is a permanent error, so a second sending platform is added inside the existing record rather than published as a new one.