Retrieve all TXT records for any domain or subdomain. Auto-detects SPF, DKIM, and DMARC records.
TXT Record Lookup: View and Identify All DNS Text Records
DNS TXT records store email authentication data, domain ownership proofs, and service verification tokens. Every email authentication standard — SPF, DKIM, DMARC, and BIMI — uses TXT records. This tool retrieves all TXT records at any DNS name you specify and automatically identifies the type based on the record's prefix.
Why TXT instead of dedicated record types: the DNS spec did not anticipate the variety of metadata domains would eventually need to publish, so the TXT type became the catch-all. Each new standard layers its own prefix convention (v=spf1, v=DMARC1, v=DKIM1) so resolvers can distinguish them without coordination. The downside is that a single DNS name can return multiple unrelated TXT records, and queries must filter by prefix to find the relevant one.
Common TXT Record Lookups for Email
The table below covers the lookups that matter for production email infrastructure. DKIM is the only one that uses a selector subdomain (the selector name is configured at the sender and varies per provider); the others sit at well-known prefixes.
| What to check | DNS name to query | Expected prefix |
|---|---|---|
| SPF record | yourdomain.com | v=spf1 |
| DMARC record | _dmarc.yourdomain.com | v=DMARC1 |
| DKIM record | selector._domainkey.yourdomain.com | v=DKIM1 |
| BIMI record | default._bimi.yourdomain.com | v=BIMI1 |
| Google verification | yourdomain.com | google-site-verification= |
What TXT records actually do at the receiving MTA
Receiving MTAs perform these lookups during the SMTP transaction, in order: SPF is checked against the connecting IP after the MAIL FROM command, DKIM is verified against the signature in the message headers after DATA, DMARC is evaluated using the domain in From: to check alignment with the SPF and DKIM results. Each step adds 50-200ms to the transaction; well-cached TXT records keep this in the lower band.
DNS caching matters operationally. Changes to TXT records propagate at the TTL rate set on each record; common defaults are 3600 seconds (1 hour), and aggressive caching can extend that another hour at intermediate resolvers. A DKIM key rotation that does not respect the propagation window produces authentication failures during the rollover — one of the more common causes of unexpected placement drops post-DKIM change.