I queried example.com but don't see DMARC or DKIM. Why?

Those records do not live on the apex. DMARC sits at `_dmarc.example.com`. DKIM sits at ` ._domainkey.example.com` (selector varies: `default`, `google`, `k1`, etc.). Type the full subdomain into the field and look it up. For a guided audit that probes the common DKIM selectors automatically, use Mail Security.

What kinds of TXT records usually sit on the apex?

SPF (`v=spf1 ...`), domain-verification tokens (Google Site Verification, Apple, Bing, Facebook), and free-form notes the owner left for themselves. Mail security records (DMARC, DKIM) live on specific subdomains and are not seen here unless you query that subdomain.

I see multiple SPF records. Is that valid?

No. RFC 7208 requires exactly one SPF record per domain. Multiple SPF records is a misconfiguration that breaks email authentication. Receivers should treat it as PermError and skip SPF altogether. Merge them into one record with combined mechanisms. For a guided check use Mail Security.

TXT records are limited to 255 characters per string. How are longer values handled?

DNS splits values longer than 255 chars into multiple quoted strings within the same record. The tool returns them as the concatenated final string, which is what mail receivers do. So a 500-char DKIM key shows here as one continuous value even though on the wire it is two strings.

Where does the data come from?

The TXT query runs from the packet.guru server, not from your browser, so the answer bypasses your browser and OS cache. The answer still respects the record's TTL on the server side.

Free, no signup, rate-limited per IP.

DNS

TXT Lookup

Text records lookup

Input

Extract TXT records used for verification (Google Site Verification), security (SPF, DKIM, DMARC), and other metadata.

Terminal

Console ready. Execute a command to see output...

About TXT Lookup

The "Notes" Field of DNS

TXT records were originally for human notes, but now they are the backbone of Domain Verification and Email Security.

Common Uses

SPF (Sender Policy Framework): Defines who can send email as you.
DKIM/DMARC: Cryptographic signatures and policy enforcement for email.
Verification: Proof of ownership for Google Search Console, Facebook, etc.

How to use TXT Lookup

Pick the right name
For SPF or general TXT, enter example.com. For DMARC, enter _dmarc.example.com. For DKIM, enter <selector>._domainkey.example.com.
Hit Lookup
All TXT records for that exact name come back from the packet.guru server.
Read the result
Each line is one TXT record. Long records look concatenated (DNS splits over 255 chars into multiple strings on the wire, the tool joins them).
For a full mail audit
Use Mail Security. It probes the right subdomains for DMARC / DKIM / BIMI automatically and grades the result.

Frequently Asked Questions

: Those records do not live on the apex. DMARC sits at _dmarc.example.com. DKIM sits at <selector>._domainkey.example.com (selector varies: default, google, k1, etc.). Type the full subdomain into the field and look it up. For a guided audit that probes the common DKIM selectors automatically, use Mail Security.
: SPF (v=spf1 ...), domain-verification tokens (Google Site Verification, Apple, Bing, Facebook), and free-form notes the owner left for themselves. Mail security records (DMARC, DKIM) live on specific subdomains and are not seen here unless you query that subdomain.
: No. RFC 7208 requires exactly one SPF record per domain. Multiple SPF records is a misconfiguration that breaks email authentication. Receivers should treat it as PermError and skip SPF altogether. Merge them into one record with combined mechanisms. For a guided check use Mail Security.
: DNS splits values longer than 255 chars into multiple quoted strings within the same record. The tool returns them as the concatenated final string, which is what mail receivers do. So a 500-char DKIM key shows here as one continuous value even though on the wire it is two strings.
: The TXT query runs from the packet.guru server, not from your browser, so the answer bypasses your browser and OS cache. The answer still respects the record's TTL on the server side.
: Free, no signup, rate-limited per IP.