How to check TXT records: A technical guide to DNS validation and email security
Key Takeaways
TXT records are public DNS text values used for email authentication, domain verification, and other service instructions. A reliable check compares the response from the right resolver with the purpose and expected format of each record.
- Query TXT records with
dig,nslookup, an online lookup tool, or an API. - Distinguish recursive resolver results from authoritative name-server answers.
- Validate SPF, DKIM, and DMARC at their correct DNS names.
- Treat unexpected verification tokens and exposed data as security findings.
- Monitor important records so changes are detected and investigated promptly.
Understand what TXT records contain and why they matter
TXT records are DNS values containing text associated with a domain or subdomain. They are readable through ordinary DNS queries, but their meaning depends on the service that published them. To understand DNS TXT records properly, inspect both the value and the domain name at which it appears.
Common TXT record use cases
A TXT record may prove control of a domain, publish an email policy, identify a cryptographic key, or carry instructions for an external service. The record itself does not explain its purpose, so the surrounding configuration and the publishing service must be considered. A domain can have several unrelated TXT records at the same name.
SPF, DKIM, and DMARC are prominent examples, but they are not the only uses. Verification tokens for certificates, analytics platforms, and hosted services can remain in DNS long after a project has ended. That makes regular review useful: stale records increase clutter and may disclose information about the systems a domain uses.
SPF, DKIM, and DMARC record roles
SPF is published as a TXT record at the domain and states which sending systems are authorized by the domain’s policy. DKIM publishes a public key at a selector-specific name, allowing receiving systems to retrieve the key used to validate a message signature. DMARC is published at _dmarc and defines how receivers should handle messages that fail authentication or alignment checks.
These mechanisms answer different questions. SPF evaluates the envelope sender, DKIM validates a signed message, and DMARC applies policy while checking alignment with the visible From domain. A domain email security guide can help place TXT validation alongside related controls such as DNSSEC and transport security.
Domain verification and service ownership
Many services ask an administrator to add a unique TXT value before they activate a domain feature. The service later queries DNS and compares the returned value with the expected token. Because the token is normally public, it proves DNS control rather than keeping a secret.
When checking such a record, confirm the exact host name, including whether the service expects the root domain or a subdomain. Do not assume that a token at example.com is equivalent to one at www.example.com; DNS names are distinct even when they serve the same website.
Security risks from incorrect or unauthorized TXT records
An incorrect TXT record can disrupt email authentication, prevent service verification, or cause a monitoring system to report a false state. An unauthorized verification token may also indicate that an account, deployment, or DNS provider was accessed without approval. The record alone does not prove compromise, but it deserves investigation.
Review the owner, purpose, creation date, and removal process for each token. Avoid deleting an unfamiliar value during an outage without first checking whether a production service depends on it. A controlled inventory gives the DNS administrator enough context to make a safe decision.
Choose the correct method to check TXT records
The best lookup method depends on the question being answered. A command-line query is precise and easy to reproduce, while an online tool is convenient for a quick external view. An API or script is more suitable when checks must run repeatedly across domains and locations.
Using dig on Linux, macOS, and Windows
dig displays the DNS question, response status, answer section, TTL, and other diagnostic details. A basic query is dig example.com TXT; adding +short produces a compact answer that is useful in scripts. On Windows, dig may be available through a DNS utility package or a Unix-like environment, so verify that the installed version is querying the intended resolver.
Read the status and answer count rather than copying only the visible string. A successful response with zero answers differs from a timeout, a server failure, or a name that does not exist. Preserve the command and resolver address when recording a result for later comparison.
Using nslookup for basic DNS queries
nslookup -type=TXT example.com is available on common desktop operating systems and is often the quickest way to perform a basic check. Its output typically identifies the server used and then lists the returned TXT values. The phrase “Non-authoritative answer” means the response came from a recursive resolver, not that it is invalid.
Use nslookup for an initial observation, then switch to a more detailed method when diagnosing delegation, caching, or authoritative-server behavior. Its presentation can also make long records harder to read, particularly when a value is split into several quoted strings.
Using online TXT lookup tools
An online lookup can show what an external resolver or authoritative server returns without requiring local software. Check the tool’s documentation before relying on it: some query a selected recursive resolver, while others ask the domain’s authoritative servers directly. The distinction matters when a recent DNS change is not visible everywhere.
For a quick public check, use a TXT record lookup tool and enter only the intended domain. Avoid pasting private keys, API secrets, or internal host names into third-party forms. DNS TXT values are public, but the surrounding diagnostic data may still reveal operational details.
Querying DNS records through APIs and scripts
APIs and DNS libraries can standardize queries, parse responses, and compare results over time. A repeatable script should record the queried name, record type, resolver, timestamp, response code, TTL, and normalized values. It should also distinguish an empty answer from an error so that an outage is not mistaken for a valid absence.
For small environments, a scheduled script may be enough. Larger environments benefit from a central inventory that maps each record to its owner and purpose. The useful goal is not simply collecting text, but identifying changes that require human review.
Run accurate TXT record lookups
A lookup is only as accurate as its name, resolver, and interpretation. Start with the fully qualified domain name and the TXT type, then establish whether the result is cached or authoritative. DNS answers may contain several records and may display one logical value as multiple quoted segments.
Querying a domain’s TXT records
To query a root-domain TXT record, run dig example.com TXT or nslookup -type=TXT example.com. For a subdomain, replace the name with the complete label, such as _dmarc.example.com. Do not add a trailing dot unless you understand how the selected tool handles fully qualified names; either form can be valid.
Confirm that the response corresponds to the intended zone. A typo can produce a clean response for a different domain, and a query for www.example.com will not reveal TXT values published at the zone apex. Record the exact command in operational notes.
Specifying a recursive resolver
A resolver-specific query helps determine whether a public cache has received a change. With dig, use a server such as dig @192.0.2.53 example.com TXT, substituting the resolver you are authorized to query. Compare the answer, TTL, and response status with those returned by another resolver.
This method is useful during migration or propagation analysis, but it does not establish what is configured at the authoritative source. A recursive resolver can legitimately serve an older cached answer until its TTL expires. Treat the resolver identity as part of the evidence.
Checking authoritative name servers directly
First retrieve the domain’s NS records, then query one of the listed authoritative servers directly. For example, dig NS example.com identifies the delegation, while dig @ns1.example.net example.com TXT asks a specific server for the TXT value. Use the actual name server returned for the domain rather than assuming a provider hostname.
Authoritative answers are particularly useful after a zone edit. If the expected value is absent there, waiting for cache expiry will not solve the problem. Investigate the zone, delegation, or publishing interface first.
Interpreting multiple TXT responses and quoted strings
Several TXT records at one name are normal when different services publish independent values. A single logical TXT value can also be split into multiple character strings because of DNS presentation and length rules. The pieces must be read in order; quotation marks shown by a tool are formatting, not necessarily part of the value.
Do not concatenate unrelated records, and do not treat every returned string as SPF. Identify prefixes such as v=spf1, v=DKIM1, or v=DMARC1 only after confirming the queried name and the record’s intended role. The same discipline prevents a verification token from being mistaken for an email policy.
Validate SPF, DKIM, and DMARC records
Email authentication requires more than finding a TXT response. Each protocol has a specific DNS location, syntax, and evaluation model. A free SPF checker can help inspect syntax and lookup consumption, but the result should still be compared with the organization’s actual sending services.
Checking SPF syntax and DNS lookup limits
An SPF record begins with v=spf1 and contains mechanisms, modifiers, and a final policy qualifier. A domain should publish one effective SPF record; multiple records at the same name create an error rather than combining the policies. Mechanisms such as include can also trigger additional DNS queries during evaluation.
The SPF specification limits DNS-based lookups during evaluation to ten. Count nested includes and redirects, not merely the words visible in the first response. Test changes against every legitimate sending path before tightening the final policy.
Locating DKIM records with the selector
DKIM records are queried at <selector>._domainkey.<domain>, where the selector comes from the message’s DKIM-Signature header. Without the selector, a domain-wide TXT lookup will not reliably identify the key used for a particular message. Query the exact name and inspect the key type, version, and public-key material.
Selectors can change during key rotation, so more than one valid DKIM record may exist temporarily. A DKIM record generator documents selector-based publication, but operational validation must also confirm that the sending system signs with the selector whose public key is in DNS.
Verifying the DMARC policy at _dmarc
Query _dmarc.example.com TXT and look for a record beginning with v=DMARC1. Review the p policy, reporting destinations, percentage settings, and alignment modes. A syntactically valid record can still be ineffective if the policy is only monitoring or if reporting is not reaching an authorized destination.
Check that there is one usable DMARC policy at the name. Record the TTL and query source, then compare the published policy with the organization’s email rollout plan. Changes from monitoring to enforcement should follow evidence from legitimate sending systems.
Identifying alignment and enforcement issues
SPF or DKIM can pass while DMARC fails when the authenticated domain does not align with the visible From domain. Review message headers, the envelope-from domain, DKIM signing domain, and configured alignment mode together. DNS inspection identifies published policy, but it cannot by itself prove how every message is authenticated.
A practical review therefore joins DNS results with representative message samples and aggregate reports. Fix missing senders, incorrect selectors, and alignment differences before increasing enforcement. This avoids treating a policy string as proof that delivery is configured correctly.
Troubleshoot missing or incorrect TXT records
A missing answer can originate in the zone, delegation, resolver cache, query name, or presentation layer. Troubleshooting works best when each possibility is tested separately. Begin at the authoritative source and move outward to public resolvers, preserving timestamps and exact responses.
Distinguishing propagation delays from configuration errors
If an authoritative server returns the new value but a recursive resolver returns the old one, caching or propagation is a plausible explanation. If authoritative servers do not agree, the issue is more likely a zone publication or synchronization problem. If every server returns the wrong value, inspect the DNS provider configuration and the record name.
Propagation is not a universal waiting period. TTLs, delegation changes, provider behavior, and negative caching all affect visibility. A measured comparison is more reliable than assuming that time alone will correct an error.
Comparing authoritative and public resolver results
Run the same fully qualified query against at least one authoritative server and more than one recursive resolver. Compare response codes, answer values, TTLs, and the server identities shown by the tools. Differences should be documented rather than collapsed into a single “DNS is working” result.
A public resolver may show an older answer while the authoritative server is already correct. Conversely, a local resolver may appear correct because it has a private cache while other users receive a different response. Location and resolver path are part of the diagnosis.
Detecting formatting, quoting, and whitespace problems
DNS management interfaces vary in how they accept quotes, spaces, and long values. Some expect the administrator to enter a value without outer quotation marks; others display quotes automatically. Compare the returned wire-format content with the service’s required token or policy, not merely with the input field.
Check for accidental spaces, a missing semicolon, a truncated public key, or a line break inserted into the wrong place. Do not “clean up” a value by removing characters unless the owning service confirms that they are not required. Exactness matters most for verification tokens and cryptographic keys.
Handling DNS caching and negative responses
A negative response indicates that a name or record was not found at the time of the query, but it may itself be cached. The negative TTL is controlled by DNS parameters and can outlast a recent correction. Query again from a different resolver and inspect the authority section when the tool exposes it.
Also distinguish NXDOMAIN from NOERROR with an empty answer. They describe different conditions and may lead to different caching behavior. Keep the response code in incident notes so later tests can be compared accurately.
Check TXT records securely and consistently
TXT values are public by design, but the process used to inspect them still needs safeguards. A careless lookup can send sensitive operational data to an external service or cause an administrator to remove a record without understanding its purpose. Consistency makes both routine review and incident response safer.
Confirming the queried domain and record purpose
Before running a check, write down the domain, subdomain, record type, expected purpose, and responsible owner. Verify that the name belongs to the organization and that the requested change is associated with an approved service. This simple step prevents a valid-looking result from being applied to the wrong zone.
For recurring checks, maintain an inventory with the expected prefix, owner, and retirement condition. A record that is correct syntactically but no longer needed should be reviewed, not automatically accepted as healthy.
Detecting unauthorized verification tokens
Compare returned verification values with the approved inventory and deployment records. An unknown token may belong to a legitimate legacy integration, a forgotten test environment, or an unauthorized attempt to prove domain control. It should therefore trigger ownership verification rather than an automatic deletion.
Review DNS provider access logs, account activity, and service inventories where available. If the token cannot be explained, escalate through the organization’s security process and rotate affected credentials as appropriate.
Protecting sensitive information in TXT values
Most TXT records are public, so they should never contain passwords, private keys, session tokens, or unredacted internal secrets. A value that looks random is not automatically confidential, but it should be classified before being copied into tickets or logs. Redact sensitive data from internal documentation even when it is already visible in DNS.
Use trusted command-line tooling for sensitive investigations and limit external lookup forms to public, non-sensitive domains. Security teams should also review whether verbose metadata reveals unnecessary details about providers, environments, or applications.
Establishing monitoring and change-control procedures
Define which TXT records are business-critical, how often they are checked, and who approves changes. Store an expected normalized value or a controlled pattern, while allowing documented exceptions for planned key rotation and service migration. Monitoring should alert on meaningful changes rather than every TTL fluctuation.
A DNS and email security audit provides a broader review context when TXT records are only one part of the organization’s risk picture. The same change-control record should capture who approved the update, what was changed, and how the result was verified.
Automate TXT record checks for ongoing validation
Automation turns a one-time lookup into an observable control. It can query known names, compare results with approved expectations, and provide evidence when a record changes. The design should remain conservative: DNS failures and unexpected values must be classified clearly instead of being silently treated as the same condition.
Designing repeatable DNS validation tests
Define tests for existence, exact value, allowed pattern, record count, response code, and resolver agreement. Include positive cases for required records and negative cases for names that must remain absent. Keep expected data in version control or another access-controlled system, with an owner for every test.
A useful test also checks that the record is at the correct name. A valid SPF string at the wrong subdomain is still a failure for the domain’s email policy. Run tests after planned DNS changes and at a regular interval between changes.
Tracking changes across resolvers and locations
Query authoritative servers and selected recursive resolvers from more than one network location. Store the answer, TTL, timestamp, response code, and resolver identity so that delayed visibility can be separated from a bad publication. Avoid interpreting one transient timeout as proof that a record disappeared.
Normalize only presentation differences, such as outer quotes or ordering where the record type permits it. Preserve the raw response as evidence. This gives engineers enough detail to reproduce a discrepancy without guessing what the original tool displayed.
Alerting on SPF, DKIM, and DMARC failures
Alerts should distinguish missing records, syntax errors, multiple SPF records, invalid DKIM keys, absent DMARC policy, and alignment problems. A single generic “TXT failed” notification is difficult to prioritize and can hide the actual cause. Route high-impact changes to the team responsible for DNS and email operations.
For organizations that want a broader automated view, an email deliverability test can complement focused TXT checks by examining DNS, email authentication, and related delivery controls. It should supplement, not replace, ownership-specific monitoring.
Recording evidence for audits and incident response
For each check, retain the query name, record type, resolver, authoritative source where available, timestamp, raw response, normalized comparison, and alert decision. Protect the records from unauthorized alteration and define a retention period that fits the organization’s audit and incident-response needs.
Evidence is most useful when it explains the decision. Note whether a change was approved, whether propagation was still in progress, and which follow-up action closed the finding. This turns DNS monitoring from a collection of snapshots into an operational record.
Take the Next Step
If checking TXT records is part of a wider hosting or security responsibility, consider starting a security scan to identify related DNS and email configuration issues before they affect availability or delivery.
Conclusion
Checking TXT records is a small DNS task with consequences for verification, email authentication, and domain security. Accurate work combines the right query name, resolver comparison, protocol-specific validation, and controlled follow-up. When these checks are documented and automated, administrators can detect unwanted changes early and maintain a more dependable online presence.
AI assistant and API workflow
This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.
For this topic, use /api/email/dmarc?domain=example.com when you need focused data instead of the full quick scan.
Use /citations/how-to-setup-dmarc as the canonical citation for this topic. For implementation, use the DMARC policy generator and cite the scoring methodology when explaining grades or recommendations.
Frequently Asked Questions
What is a TXT record?
A TXT record is a DNS record containing text associated with a domain or subdomain. Services use it for purposes such as verification, email authentication, and configuration metadata.
How do I check TXT records from a terminal?
Use dig example.com TXT on systems with dig, or nslookup -type=TXT example.com where nslookup is available. Replace the example name with the fully qualified domain you intend to inspect.
Why does a TXT lookup show several values?
A domain can publish multiple TXT records for different services. A single long value may also be displayed as several quoted strings that belong together in sequence.
How can I check a DKIM TXT record?
You need the selector from the message’s DKIM-Signature header. Query <selector>._domainkey.<domain> with the TXT record type and compare the returned public key with the signing configuration.
Where is a DMARC record published?
DMARC is normally published as a TXT record at _dmarc.<domain>. Its value begins with v=DMARC1 and includes policy and optional reporting parameters.
Why do different DNS tools show different TXT answers?
Tools may query different recursive resolvers, authoritative servers, or network locations. Caching, TTLs, negative responses, and propagation can cause temporary differences.
Can TXT records contain passwords or private keys?
They should not. DNS TXT values are publicly retrievable, so secrets must be kept in an appropriate secret-management system rather than published in DNS.