Free TXT Record Lookup

What a TXT record actually is

A TXT record is the only DNS record type with no defined meaning. Every other type has a shape the resolver understands: an A record holds an IPv4 address, an MX record holds a mail host and a priority. TXT holds arbitrary text, and whatever reads it decides what it means.

That is why one domain's TXT set is a pile of unrelated things at the same name. A typical apex looks like this:

Nothing coordinates these. They coexist because each reader filters for its own prefix and ignores everything else.

The 255-byte limit, and why long records look broken

This is the single most common TXT problem, and it is a protocol rule rather than a provider quirk. A DNS character-string cannot exceed 255 bytes. A TXT record can be longer than that, but only by being split into several strings, which the resolver concatenates with no separator.

Measured on real records:

The split is exactly the 1024-bit versus 2048-bit DKIM key difference. A 1024-bit key encodes to about 236 bytes and fits in one string. A 2048-bit key is around 410 and cannot, so it must be published as two. Note that GitHub's first string is 253 bytes, not 255: the limit is a ceiling, and signers split wherever they like.

Three things follow, and they cause most DKIM failures:

• The strings are joined with nothing between them. A provider that inserts a space or a newline at the join corrupts the key. The record will look right and fail to verify.
• Some DNS UIs will not accept a >255-byte value at all and reject the paste rather than splitting it. Others split silently. You cannot tell which without checking.
• A tool that shows you only the first string is lying to you. This one joins the strings before displaying, which is what a resolver does, so what you see is what a mail server sees.

Multiple strings is not the same as multiple records

These look similar in a DNS UI and behave completely differently.

One record, several strings is the 2048-bit DKIM case above. The resolver glues them into a single value. This is normal and correct.

Several records at the same name means the resolver returns a set, and the reader decides what to do with it. For most purposes that is fine, and it is how verification tokens from a dozen vendors coexist. For SPF it is a hard failure: RFC 7208 permits exactly one SPF record per name, and a domain publishing two gets a permerror, which typically means mail stops authenticating. Two SPF records is the classic outage after adding a second email vendor. The fix is to merge them into one, not to add another.

DMARC has the same rule on the _dmarc name. DKIM does not, because each key lives on its own selector.

Why big TXT sets sometimes fail to resolve

A DNS response over UDP was historically capped at 512 bytes. EDNS0 raised that, and nearly everything supports it now, but the failure mode still appears on networks with middleboxes that block large UDP responses or strip EDNS0. When the response does not fit, the server sets the truncation bit and the resolver is supposed to retry over TCP.

Resolvers that handle this badly return a partial set or nothing at all. If a domain with many TXT records resolves from one network and not another, that is the usual cause, and dig +tcp TXT example.com against dig TXT example.com will show it immediately.

It is a real argument for keeping the apex TXT set small: retire verification tokens once a vendor has confirmed, rather than leaving a decade of them in place.

Reading this tool's output

We query the domain's TXT records, join the strings in each record the way a resolver does, and label each one by prefix: SPF, DMARC, DKIM, MTA-STS, a recognised vendor verification token, or Other.

Two things worth knowing about what you get back:

• Other is not a problem. It means we do not recognise the prefix, which is the expected result for internal tokens and newer vendors.
• DKIM keys will usually not appear at the apex. They live on <selector>._domainkey.example.com, so query that name directly. If you do not know the selector, the DKIM record checker tries the common ones for you.

For SPF specifically, the count that matters is not the record length but the number of DNS lookups it triggers, which is capped at 10. The SPF record checker resolves the whole include tree and counts them.

Looking up TXT records from code

dig is the fastest way, and the +short output shows the strings already quoted, so you can see any split:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

Watch for a subtlety when you script this: most DNS libraries hand you TXT records as an array of strings per record, precisely because of the 255-byte rule. Joining them is your job, and forgetting to is why a DKIM key that verifies in dig fails in your code.

Our hosted endpoint does the join and the categorisation, is documented at the TXT record lookup API reference, and needs no key. The DNS record lookup returns the other record types for the same name if you need the full picture, and DNS propagation explains why a record you just added is not visible everywhere yet.

If you are running a SaaS

TXT records are how nearly every platform proves domain ownership, so if you let customers attach their own domain you will end up asking them to add one and then polling for it. The awkward parts are the ones above: caching, the propagation window, and customers pasting a key their DNS provider silently mangled.

Domainee is a custom domains API for SaaS with a native MCP server — 50 domains and 100 GB free. It runs the DNS verification loop and certificate provisioning for multi-tenant custom domains so you are not writing the polling and retry logic yourself.