TXT Record Lookup

Read every TXT record published for a domain. Enter a domain and this tool queries live DNS, lists each text record, and tags the well-known ones — SPF policies, domain-verification strings, service tokens — so you can see at a glance what they are. TXT records are where a lot of email and ownership-verification configuration lives, and this is the quickest way to inspect it.

How to use the TXT Record Lookup

Enter a domain and press Look up TXT records. The tool reports:

• Every TXT record at the name, with long values re-joined from the multiple quoted chunks DNS splits them into.
• A type tag on recognised records — SPF, DMARC, DKIM, BIMI, and common verification strings (Google, Microsoft, Facebook, Apple).
• The TTL for each record.

By default this queries the domain you enter. Remember that some TXT records live at subnames: DMARC at _dmarc.example.com, DKIM at selector._domainkey.example.com. To read those, enter that full name, or use the dedicated DMARC and DKIM checkers.

What TXT records are used for

A TXT record holds arbitrary text in DNS. It was originally meant for human-readable notes, but because it is a simple, universally supported way to attach a string to a name, it has become the place where machines publish all sorts of policy and proof-of-ownership data. Reading a domain's TXT records tells you a great deal about how its email is configured and which third-party services it uses.

The common kinds you will find, each flagged by this tool:

• SPF — a record starting v=spf1 that lists which servers are allowed to send email for the domain. There must be only one SPF record per name.
• Domain verification — strings like google-site-verification=…, MS=… or facebook-domain-verification=… that prove to a provider you control the domain, so you can use their service.
• DMARC and DKIM — these are TXT records too, but they live at special subnames (_dmarc and selector._domainkey) rather than the apex, so you query those names directly.
• Service tokens — various SaaS tools ask you to add a TXT record to enable a feature or confirm ownership.

One quirk of TXT records is length. A single DNS string is capped at 255 characters, so a long value (like a DKIM key or a big SPF record) is published as several quoted chunks that resolvers concatenate back together. This tool re-joins them so you see the whole value. It is also why you should keep the number of TXT records reasonable — too many, or a bloated SPF record, can push a DNS response over the size that fits in a single UDP packet and cause lookups to fall back to slower TCP.

Common use cases

• Checking SPF — confirm the domain publishes exactly one v=spf1 record and see what it allows.
• Verifying domain ownership — confirm a verification TXT a provider asked you to add is present and correct.
• Auditing third-party services — see which services a domain has been connected to via TXT tokens.
• Debugging email — read the raw SPF and other text records when mail is failing authentication.
• Catching duplicates — spot a second SPF record, which silently breaks SPF.

Where the email-auth TXT records actually live

Email authentication uses several TXT records, but only one of them sits at the domain apex. Knowing the exact name to query saves confusion:

• SPF — at the apex (example.com). Visible in this lookup directly.
• DMARC — at _dmarc.example.com. Enter that name here, or use the DMARC Record Checker which parses it.
• DKIM — at selector._domainkey.example.com, where the selector is provider-specific. Use the DKIM Checker, which can probe common selectors for you.
• BIMI — at default._bimi.example.com. Use the BIMI Checker.

So if a DMARC or DKIM record "isn't showing up" in a plain apex TXT lookup, that is expected — they are published at their own subnames, not the apex.