DNS Checker.eu

TXT Record Lookup

Look up every TXT record on a name and read the full value of each - SPF, DKIM, DMARC, MTA-STS, TLS-RPT, ownership verification strings and free-form text - with TTLs.

About TXT Record Lookup

The TXT Record Lookup returns every TXT record published at the exact name you query, with the full value of each and its TTL. TXT is the catch-all record type, so one name can carry an SPF policy, a domain-ownership token from a SaaS provider and a note left by a colleague years ago, all side by side. Seeing the complete set matters because several standards break when a name carries two policies instead of one, and because a verification string is easy to publish at the wrong label.

A single DNS character-string cannot exceed 255 octets (RFC 1035), so a long value such as a 2048-bit DKIM public key is published as several quoted strings inside one TXT record. Consumers join those strings together with nothing between them, as RFC 7208 spells out for SPF, which is why the chunk boundaries can fall anywhere. The failure mode is subtle: splitting a value across two separate TXT records instead of one record with multiple strings yields two policies, and for SPF that is a permerror, because RFC 7208 allows exactly one record per name.

The lookup runs server-side through our own European resolver and reassembles each record's character-strings into the single value a consumer would see, one row per record with its name, TTL and value. Because it queries the exact name given, it is the right tool for underscore-prefixed policy names: _dmarc.example.eu, selector._domainkey.example.eu, _mta-sts.example.eu or _smtp._tls.example.eu. It reports what is published rather than judging it, so when you want a policy parsed and validated, follow up with the SPF, DKIM, DMARC, MTA-STS or TLS-RPT checkers.

How to use it

  1. 1Enter the exact name that holds the records: example.eu for SPF and verification strings, _dmarc.example.eu for a DMARC policy, selector._domainkey.example.eu for a DKIM key.
  2. 2Select Lookup to query that name through our European resolver.
  3. 3Read each row as one TXT record; long values are shown already reassembled from their 255-character strings.
  4. 4Check for duplicates, since two records starting with v=spf1, or two DMARC policies, are treated as an error by mail receivers.
  5. 5Note the TTL before editing a record so you know how long the old value can remain cached elsewhere.
  6. 6Copy a verification string straight from the Value column to compare it character by character with the one your provider issued.

Common use cases

  • -Confirming a domain-ownership TXT record is visible before clicking verify in a SaaS console.
  • -Troubleshooting mail delivery by reading the SPF, DKIM and DMARC records exactly as receivers see them.
  • -Auditing a domain for leftover verification strings belonging to services you no longer use.
  • -Checking that a long DKIM key was published as one record with multiple strings rather than split across two records.
  • -Verifying MTA-STS and TLS-RPT policy records at _mta-sts and _smtp._tls after enabling SMTP transport security.

Frequently asked questions

Can a domain have more than one TXT record?
Yes, and most do. A name can hold any number of TXT records and resolvers return the whole set. The limits come from the standards that use TXT: RFC 7208 allows exactly one SPF record per name, and DMARC and DKIM likewise expect a single policy at their respective names. Duplicates there cause a permerror or an outright failure, while unrelated TXT records sit alongside each other harmlessly.
Why is a DKIM TXT record split into two strings?
A DNS character-string is limited to 255 octets by RFC 1035, and a 2048-bit DKIM public key is longer than that. The value is therefore published as several quoted strings inside one TXT record, and consumers concatenate them with no separator, so the split point does not matter. What does matter is keeping them in a single record: two separate TXT records are read as two keys, not one.
What is the maximum length of a TXT record?
Each character-string inside the record is capped at 255 octets, but a record can contain many strings, so the practical ceiling is the DNS message size. Once a response no longer fits the advertised EDNS0 buffer, the resolver retries over TCP. Very large TXT sets therefore still work, but they add latency and depend on TCP port 53 being reachable, which some restrictive networks block.
How long do TXT record changes take to appear?
Only as long as the old record's TTL. A resolver that has cached the previous value keeps serving it until the TTL expires and then fetches the new one, so lowering the TTL before an edit shortens the wait. If the name did not exist before, the delay is governed by the zone's SOA minimum instead, which is why a brand new TXT name can stay absent for a while.