📝 TXT Lookup

🔍 What Is a TXT Record?

A TXT record stores a piece of arbitrary text at a DNS name — nothing more structurally specific than that. Unlike an A record, which must hold a valid IPv4 address, or an MX record, which must reference a mail server hostname with a priority, a TXT record's value is just a string, and it's up to whatever's reading it to decide what that string means. That flexibility is exactly why TXT records ended up hosting so much unrelated infrastructure over the years: email authentication systems, domain-ownership verification, third-party integration tokens, and more, all reusing the same generic text-storage mechanism rather than each inventing a dedicated record type.

This tool exists because that flexibility also makes TXT records genuinely easy to misconfigure — a single typo in an SPF string, a duplicate record where there should be one, a verification string added to the wrong subdomain — and checking exactly what's published, right now, is often the fastest way to confirm or rule out a DNS-level cause during troubleshooting.

📋 Record Structure & Syntax

A TXT record's zone-file structure is minimal: a name, a TTL, a class, the record type, and the text value itself, wrapped in quotes:

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

Individual TXT record values are limited to 255 characters per quoted string at the protocol level, though DNS allows multiple quoted strings to be concatenated within a single TXT record for longer content — most consuming applications treat that concatenation transparently, but it's worth knowing about if a long value looks unexpectedly split when viewed in a raw zone file.

⚙️ How This Tool Queries TXT Records

When you click Lookup, the tool sends a live query for the TXT record type against a public DNS resolver and returns exactly what's currently published — not a cached snapshot. Every TXT record at that name is returned together, since a single hostname routinely holds several at once.

📧 Email Authentication: SPF, DKIM & DMARC

Three of the most operationally important TXT records in existence exist purely to fight email spoofing, and all three reuse the generic TXT mechanism rather than having their own dedicated record type:

SPF (Sender Policy Framework) lists which mail servers are authorized to send email on a domain's behalf, published as a TXT record starting with v=spf1. Receiving mail servers check the sending server's IP against this list to help decide whether a message is legitimate.

DKIM (DomainKeys Identified Mail) publishes a public cryptographic key as a TXT record at a selector-specific subdomain (like selector._domainkey.example.com), letting receiving servers verify a cryptographic signature attached to outbound mail, confirming the message wasn't altered in transit and genuinely originated from an authorized sender.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is published as a TXT record at _dmarc.example.com, and it tells receiving servers what to do when a message fails SPF or DKIM checks — quarantine it, reject it outright, or simply monitor and report on failures without taking action yet.

✅ Domain Ownership Verification

Beyond email, TXT records are the dominant method services use to confirm domain ownership before enabling a feature — connecting a custom domain, verifying a site in a search console, or activating a third-party integration. The logic is simple and effective: the service generates a unique string and asks you to publish it as a TXT record; since only someone with actual DNS management access could do that, successfully detecting the string proves control of the domain without requiring any other access or credentials.

📋 Multiple TXT Records at One Name

Unlike a CNAME, a TXT record has no coexistence restriction — a single name routinely holds several simultaneously: an SPF record, one or more verification strings from different services, and potentially others, all coexisting peacefully at the same hostname. The one major exception is SPF specifically: DNS rules require exactly one SPF-formatted TXT record per name, and multiple SPF records at the same name causes SPF evaluation to fail entirely for that domain, by design.

📋 Comparison Tables

SPF vs DKIM vs DMARC

TXT Verification vs HTML File Verification

🌐 Real-World Examples

🛡️ TXT Support Across DNS Providers

Every major managed DNS provider — Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS, and registrar panels — supports TXT records natively, with an identical add-record workflow to any other type: select TXT, enter the name, paste the value. Where providers differ slightly is value-length handling — some automatically split long values into multiple quoted strings behind the scenes, others require you to do that manually — worth checking if a very long DKIM key ever gets rejected or truncated unexpectedly.

🖥️ Command-Line Reference

⏳ Caching & TTL

TXT records cache the same way any other DNS record does — resolvers honor the TTL and continue serving a previously fetched value until it expires. This matters most for verification workflows: adding a TXT record and immediately re-checking from a resolver that already cached a "not found" answer for that name can show a false negative for a short window, entirely explained by caching rather than anything wrong with the record itself.

🔒 Security Considerations

Because TXT records are so often used for authentication and verification, misconfiguration has outsized consequences compared to most other record types. A DMARC policy set to "reject" before SPF and DKIM are both fully validated and reliable can cause legitimate mail to bounce. An overly permissive SPF record (or one that includes far more third-party senders than actually needed) widens the pool of infrastructure that can plausibly send mail as your domain. And stale verification TXT records left behind after decommissioning a service are, at minimum, unnecessary attack-surface clutter worth periodically cleaning up.

❌ Common Mistakes

✅ Best Practices

Keep exactly one SPF record per domain, using include mechanisms to combine multiple sending services rather than adding separate records. Roll out DMARC gradually — monitor, then quarantine, then reject — rather than jumping straight to the strictest policy. Periodically audit TXT records for stale verification strings tied to decommissioned services, and always verify a new record with a live lookup before assuming a verification workflow will succeed.

📊 Pros & Cons of TXT-Based Configuration

🔧 Troubleshooting

📚 Glossary

🎓 Expert Tips

🔗 More Ways to Investigate DNS

For the complete record picture beyond TXT, use DNS Lookup. Check mail routing directly with MX Lookup, or dig deeper into email authentication specifically with SPF Lookup and DKIM Lookup. To confirm whether a DNS change has propagated globally, use DNS Propagation Checker, and to trace an alias chain, try CNAME Lookup.