Free TXT record lookup – check TXT DNS records
TXT Record Lookup
Free, no sign-up. We only fetch the public URL you enter.
Short answer
Enter a domain or a full hostname above – for example example.com, _dmarc.example.com or _acme-challenge.example.com – and the lookup returns every TXT record published under that name with its TTL. Long values split into several quoted strings belong together and are read as one. If the record you just added is missing, check the hostname, the active nameservers and the TTL of the old answer. monitordefend does not monitor DNS records, but its uptime check emails you when your website goes down.
- Free, no sign-up: all TXT values of a name, each with its TTL.
- Works for the root domain and for hostnames like _dmarc or _acme-challenge.
- Most “record not found” cases: wrong hostname, wrong DNS provider or caching.
"v=spf1 include:_spf.mailprovider.example ~all" TTL 3600 "google-site-verification=3fQx…9aK" TTL 3600 "MS=ms12345678" TTL 3600 "stripe-verification=7c1e…b20" TTL 300
With this free TXT record lookup you see every TXT record a domain or hostname publishes in DNS. TXT records are small text values with a big job: they prove domain ownership to Google, Microsoft or GitHub, carry email authentication policies such as SPF, DKIM and DMARC, and connect third-party services without changing where your website is hosted. When a service reports “verification failed”, this lookup shows what DNS actually answers.
How does the TXT record lookup work?
Type a domain name or hostname into the field and start the check. The tool sends a DNS query for the record type TXT under exactly that name and lists every value it receives, together with the TTL – the time-to-live that tells resolvers how long they may keep the answer in their cache.
Because TXT records are attached to a specific name, the hostname matters. example.com, www.example.com and _dmarc.example.com are three different names with three independent sets of TXT records. Look up the name the service asked you to configure, not just the domain.
What is a TXT record?
A TXT record stores free-form text in DNS. It was originally meant for human-readable notes, but today it is mostly read by machines. Because any service can ask you to publish a specific string and then look it up, TXT has become the standard way to prove control over a domain and to publish policies that other servers should follow.
The big advantage is that TXT records do not change anything about where your website or email is hosted. Adding a verification string or an email policy leaves your A, CNAME and MX records untouched, which makes it a safe way to connect new tools to an existing domain.
When should you check a TXT record?
A TXT lookup is usually the first step when a service refuses to accept your domain or when email security checks fail.
- When verifying your domain with a service such as Google Search Console, Microsoft 365, GitHub or a payment provider.
- When setting up SPF, DKIM or DMARC for email security.
- When an integration says “verification failed” although you added the record.
- After DNS edits or a nameserver migration, to confirm nothing was lost.
- Before issuing an SSL certificate through a DNS challenge.
TXT record vs. SPF, DKIM and DMARC
TXT is the record type; SPF, DKIM and DMARC are email security standards that happen to be published as TXT records. They are often mentioned together, which causes confusion about what to look up and where.
- TXT: the DNS record type that stores text values.
- SPF: a TXT record on the domain itself, starting with v=spf1, listing the servers allowed to send mail.
- DKIM: a TXT record on selector._domainkey.domain, holding the public key that verifies mail signatures.
- DMARC: a TXT record on _dmarc.domain, starting with v=DMARC1, defining the policy for failing mail.
Should the TXT record go on @, www or a subdomain?
It depends on what you are verifying. Most domain-ownership checks and SPF expect the record on the root domain, which DNS panels usually write as @ or leave as an empty host field. DMARC always lives on _dmarc, DKIM on the selector name under _domainkey, and certificate challenges on _acme-challenge.
example.com v=spf1 … / verification strings _dmarc.example.com v=DMARC1; p=quarantine; … s1._domainkey.example.com v=DKIM1; k=rsa; p=MIIB… _acme-challenge.example.com token for certificate issuance
A frequent mistake is typing the full name into a panel that appends the domain automatically. Entering _dmarc.example.com in such a field creates _dmarc.example.com.example.com, which no one will ever query. When in doubt, enter only the part before your domain and confirm the result with a lookup.
Why can’t I see the TXT record I just added?
Almost every missing TXT record comes down to one of three causes. The first is caching: if the name was looked up before, resolvers keep the old answer until its TTL expires, which can take an hour or more. The second is the wrong DNS provider: the record was added at a registrar or old host while the domain’s active nameservers point elsewhere. The third is the wrong hostname, as described above.
Check the domain’s NS records to see which provider is really answering, then look up the exact hostname again. If the record appears here but the service still fails, wait for the TTL to pass and trigger the verification once more.
Multiple TXT records and split strings
A name may carry many TXT records at once, and it is completely normal for a root domain to hold an SPF policy and half a dozen verification strings side by side. Each service only looks for the value it issued. The one hard rule concerns SPF: there must be exactly one record starting with v=spf1, otherwise receivers treat SPF as broken.
- Add record In the active DNS provider
- Wait for TTL Old cached answers expire
- Look up Check the exact hostname
- Verify Click “verify” at the service
A single TXT string is limited to 255 characters. Longer values – typically 2048-bit DKIM keys – are published as several quoted strings in one record. They are concatenated without spaces when read, so treat “part one” “part two” as one continuous value. Several separate records, by contrast, are independent values and are never joined.
Checking an _acme-challenge record for SSL validation
Certificate authorities such as Let’s Encrypt can prove domain control through a DNS-01 challenge: your ACME client publishes a token as a TXT record on _acme-challenge.example.com, and the authority looks it up before issuing the certificate. Wildcard certificates require this method.
If issuance fails, run a TXT lookup for the full _acme-challenge hostname. A missing value means the client could not write to DNS; an old value means a previous token is still cached or was never removed. Keep the TTL of this name low so new tokens become visible quickly.
Keeping TXT records tidy
Over the years, TXT records pile up: verification strings for tools nobody uses anymore, an SPF include for a newsletter service you cancelled, a test DMARC record from a long-finished project. They do no direct harm, but they make every audit harder and can leak which vendors you work with.
Review the lookup result once or twice a year and match every value to a service you still use. Most verification strings can be removed once the service shows the domain as verified permanently – check its documentation first, because some services re-check ownership regularly and will drop the domain if the record disappears.
- Keep exactly one SPF record and remove includes of providers you no longer send through.
- Delete expired _acme-challenge tokens left behind by failed certificate runs.
- Write down which team or tool owns each verification string.
TXT records and monitordefend
monitordefend is a hosted website monitoring service and does not watch TXT or other DNS records for changes. Use this free lookup whenever you add a verification string or change an email policy. For the website itself, monitordefend checks the homepage every five minutes and emails you when it stops responding.
Frequently asked questions
What is a TXT record used for?
TXT records store text values in DNS, most commonly for domain verification and for email authentication policies such as SPF, DKIM and DMARC.
How do I find the TXT records for my domain?
Enter your domain above and start the check. The lookup returns every TXT record currently published under that name, each with its TTL.
Why can’t I see the TXT record I just added?
Usually because of DNS caching and the old TTL, because the record was added at a DNS provider that is not active for the domain, or because it was placed on the wrong hostname.
Should the TXT record be added to @, www or a subdomain?
It depends on the service. Most verifications and SPF use the root domain (@); DMARC uses _dmarc, DKIM a selector under _domainkey and SSL challenges _acme-challenge.
Can I have multiple TXT records on the same domain?
Yes. Domains commonly publish several TXT records for different services. Only SPF is limited to a single v=spf1 record per name.
Why is my TXT record split into multiple quoted parts?
Each TXT string is limited to 255 characters, so long values such as DKIM keys are stored as several strings in one record. Read them as one combined value.
How do I check an _acme-challenge TXT record for SSL validation?
Look up the full hostname, for example _acme-challenge.example.com. If the token is missing or outdated, certificate validation fails.
How do I look up TXT records on the command line?
Run “dig example.com TXT” on macOS or Linux, or “nslookup -type=txt example.com” on Windows.