TXT Lookup
TXT Lookup helps you query txt records for domain verification and policies, for authoritative DNS validation, resolver checks, and faster troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
TXT Lookup retrieves every TXT record published at the exact name you enter, joins the 255-byte character-strings of each record into one value, and sorts the results into SPF, DKIM, DMARC, verification and other buckets. It is the quickest way to see which policies, ownership tokens and service keys a domain is exposing in DNS.
Why It Matters
- →Email authentication: SPF lives at the domain apex, DKIM keys at selector._domainkey and DMARC at _dmarc, all as TXT records; one typo breaks deliverability.
- →Duplicate SPF detection: RFC 7208 allows only one v=spf1 record per name; two of them cause a permerror and receivers may treat the mail as unauthenticated.
- →Ownership proofs: Search consoles, certificate authorities, SaaS platforms and cloud providers verify domain control by asking you to publish a unique TXT token.
- →Clutter and exposure: Old verification strings reveal which vendors you use (or used) and inflate the response size, which can push answers over UDP limits.
- →Change confirmation: After editing a TXT record in a provider dashboard, this lookup shows whether resolvers already serve the new value or still cache the old one.
How to Read Results
- total: Number of distinct TXT records at that name. Each record may have been split into several 255-byte strings; the tool concatenates them without spaces, exactly as SPF and DKIM evaluators do.
- categorized.spf: Records beginning with v=spf1. More than one entry here is a misconfiguration that must be merged.
- categorized.dmarc: Records beginning with v=DMARC1. DMARC is published at _dmarc.example.com, so query that name to see it; the apex should not hold one.
- categorized.dkim: Values containing the text DKIM, typically v=DKIM1 keys. Query selector._domainkey.example.com to see a key, because selectors are not discoverable from the apex.
- categorized.verification: Strings containing verify or verification, such as google-site-verification=... or facebook-domain-verification=.... Tokens with other formats (for example MS=ms12345678) land in other.
- allRecords and status info: allRecords lists every value as returned. An info status means the name exists without TXT data or does not exist.
Technical Background
TXT is one of the original record types from RFC 1035 (type 16). Its RDATA is not a single string but a sequence of one or more character-strings, each prefixed by a length byte, which caps every individual string at 255 bytes. A record can contain many such strings, so long values such as 2048-bit DKIM public keys are written in the zone as several quoted chunks: selector1._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..." "...IDAQAB". Consumers decide how to reassemble them. SPF (RFC 7208, section 3.3) and DKIM (RFC 6376) concatenate the strings with no separator, so a stray space added by a web form at a chunk boundary silently corrupts the key or mechanism.
Because TXT accepts arbitrary text, it became the home for most domain-level policy. SPF moved from its own short-lived record type to TXT only (RFC 7208 deprecated type 99). DKIM keys, DMARC policies (RFC 7489, published at _dmarc), MTA-STS policy pointers (RFC 8461, at _mta-sts), TLS-RPT reporting addresses (RFC 8460, at _smtp._tls) and BIMI assertions (default._bimi) all use TXT at well-known underscore names. RFC 8552 created an IANA registry for these underscored labels so that services do not collide. The general lesson is that a TXT lookup is name-specific: the apex shows SPF and verification tokens, but each other policy must be queried at its own label.
Domain verification tokens are the other big consumer. A provider generates a random value, you publish it as a TXT record, and the provider queries for it to prove you control the zone. ACME DNS-01 challenges for TLS certificates (RFC 8555) work the same way at _acme-challenge.example.com. These tokens can usually be removed after verification unless the provider re-checks periodically, which several SaaS platforms do; keep a note of which vendor each token belongs to before cleaning up.
Size is the practical limit. Every TXT record at a name is returned in the same RRset, so dozens of tokens at the apex make the response large. Since the DNS Flag Day 2020 recommendations, resolvers advertise an EDNS buffer of about 1232 bytes; larger answers are truncated (TC bit) and must be retried over TCP. Firewalls that block TCP port 53 then cause intermittent SPF temperrors. Keep the apex lean, move vendor tokens to sub-labels when the vendor allows it, and stay within SPF's ten DNS-lookup limit when combining include mechanisms.
Common Errors and How to Fix Them
- ProblemTwo v=spf1 records appear under categorized.spf.
- FixMerge them into one record, e.g. v=spf1 include:_spf.google.com include:sendgrid.net -all, and delete the second. RFC 7208 returns permerror whenever more than one SPF record exists.
- ProblemDKIM key fails validation with a body hash or key syntax error after copying it into the dashboard.
- FixThe panel inserted spaces or quotes at the 255-byte split. Paste the key as one continuous value without quotes and let the provider split it, then re-query and compare the joined string with the original.
- ProblemDMARC record published at the root domain instead of _dmarc.
- FixReceivers only look at _dmarc.example.com. Move the v=DMARC1; p=none; rua=mailto:[email protected] record to that name and remove it from the apex.
- ProblemLiteral quote characters show up inside the record value.
- FixSome UIs add quotes automatically and you typed another pair. Edit the record so the stored value starts with v=spf1 (or the token) and contains no escaped quotes.
- ProblemVerification keeps failing although the token is correct.
- FixThe record was created at the wrong host (example.com.example.com because the panel appends the zone name). Enter @ or leave the host field blank for the apex, and wait for the old negative cache to expire.
- ProblemSPF intermittently returns temperror at large receivers.
- FixThe TXT RRset is too big for UDP and TCP 53 is blocked somewhere. Remove obsolete verification tokens and confirm your authoritative servers answer over TCP.
Frequently Asked Questions
How long does a TXT record change take to propagate?
Authoritative servers usually serve the new value within seconds to a few minutes. Resolvers that cached the old record keep it until its TTL expires, commonly 300 to 3600 seconds. If the name previously did not exist, resolvers may cache that negative answer for the SOA minimum value, so a brand-new verification token can take longer than an edited one.
Can a domain have multiple TXT records?
Yes. A name can hold any number of TXT records, and it is normal to see SPF next to several verification tokens. The restriction is per purpose: only one SPF record and only one DMARC record are allowed at their respective names, otherwise evaluators return an error.
Why is my DKIM record not showing at my domain?
DKIM keys are published at selector._domainkey.yourdomain, not at the apex. Find the selector in the s= tag of a DKIM-Signature header from a message you sent, then query that full name. A lookup of the bare domain will never show the key.
What is the maximum length of a TXT record?
Each character-string inside a TXT record is limited to 255 bytes, but a record can contain several strings. The practical ceiling is the DNS message size: keep the whole response under about 1232 bytes so it fits in a single UDP packet without falling back to TCP.
Is it safe to delete old verification TXT records?
Usually yes once the service has verified you, but some platforms re-check ownership periodically and suspend access if the token disappears. Confirm in each vendor's documentation or account settings before removing tokens, and delete only those belonging to services you no longer use.
Academic Documentation
Protocol context and primary references
REST API Documentation
v1.0GET /api/tools/txt-lookup
curl -X POST https://epcybertools.com/api/tools/txt-lookup \
-H "Content-Type: application/json" \
-d '{"domain":"google.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# All TXT records at the apex
dig TXT example.com +short
# DMARC policy lives at its own label
dig TXT _dmarc.example.com +short
# DKIM key for selector s1
dig TXT s1._domainkey.example.com +short