TXT Record Lookup
Look up every TXT record at a domain or hostname, with SPF, DMARC, DKIM, BIMI and verification tokens identified and checked: free, no signup.
What is a TXT record lookup?
This TXT record lookup queries public DNS for one hostname and returns every TXT string published there, labelled by the protocol or service that reads it. Email authentication runs on those strings: SPF is a TXT record on the sending domain, DKIM keys are TXT records under a selector, DMARC is a TXT record at _dmarc, and BIMI, MTA-STS and TLS-RPT each have a hostname of their own. So do the verification strings that Google, Microsoft, Apple and dozens of other services ask you to publish. A raw lookup shows the strings; this one also tells you which protocol reads each string, whether it is at the host that protocol actually queries, and whether two of them are fighting.
How to read your result
| Result | What it means | What to do |
|---|---|---|
| SPF record | A string starting v=spf1: the list of hosts allowed to send mail as this domain, and what receivers should do with everyone else. | Confirm it ends in ~all or -all and lists every service you send with. The SPF checker counts its DNS lookups against the limit of ten. |
| DMARC record | A v=DMARC1 string. Only meaningful at _dmarc.yourdomain.com; anywhere else it is ignored. | Read the p= tag. none reports only; quarantine and reject actually protect the domain. |
| DKIM public key | A v=DKIM1 or p= string at selector._domainkey.yourdomain.com. An empty p= means the key is revoked. | Verify the key with the DKIM checker, which also probes common selectors when you do not know yours. |
| BIMI, MTA-STS, TLS-RPT | Policy indicators at default._bimi, _mta-sts and _smtp._tls respectively. | Each has a dedicated checker that validates the parts a DNS string alone cannot: the logo file, the HTTPS policy, the report address. |
| Verification token | A proof-of-ownership string for a third-party service. The tool names the service when the prefix is a known one. | Nothing, unless a token names a service you no longer use. Removing it does not break anything already verified. |
| Two SPF or two DMARC records | More than one v=spf1 at a name, or more than one v=DMARC1 at _dmarc. Receivers treat this as an error, not a choice. | Merge them into one record. Until you do, SPF returns permerror and DMARC is treated as absent. |
| No TXT records | The name resolves but publishes no text records, or does not resolve at all. | Check the spelling. For a root domain that sends mail, publish SPF; for a subdomain that does not, this is normal. |
Where each email record actually lives
The most common misreading of a TXT lookup is running it on the root domain and concluding DMARC is missing. It is not there because receivers never look for it there. Each protocol queries a specific hostname, and a lookup shows only the one you asked for:
- SPF:
yourdomain.com, the domain in the envelope sender. - DMARC:
_dmarc.yourdomain.com. - DKIM:
selector._domainkey.yourdomain.com, one per signing key. - BIMI:
default._bimi.yourdomain.com. - MTA-STS:
_mta-sts.yourdomain.com, and TLS-RPT:_smtp._tls.yourdomain.com.
Every result here ends with one-click lookups of the other hosts for the same domain, so the full picture is five clicks rather than five typed hostnames.
What this lookup can prove
It proves what public DNS returns for the name you entered, and it catches the structural errors visible in the strings themselves: a second SPF record, a DMARC record published on the wrong host, a DKIM key with an empty p= tag, an SPF ending in +all. It does not evaluate a record against real mail. An SPF record can be perfectly formed and still omit the service that sends your invoices, and a DKIM key in DNS does not prove the server is signing with it. The SPF checker, DKIM checker and DMARC checker each validate their record tag by tag once you know it is published.
From reading records to keeping them right
A lookup is a snapshot of one hostname. The records that decide whether your mail is trusted drift: a team adopts a new sending tool and the SPF record no longer covers it, a provider rotates a DKIM selector, a DMARC policy sits at p=none for a year because nobody read the reports. Palisade turns DMARC aggregate reports into a prioritized workflow so operators can identify every source sending as the domain, see which records each one needs, and move the domain to enforcement with evidence rather than guesswork.
For MSPs it's built multi-tenant: every client domain's SPF, DKIM and DMARC records checked, corrected and enforced from one console, with portfolio-based per-client-domain pricing whose rate improves as you scale.
Related checks and terms
DMARC software that does the work
Palisade organizes DMARC report evidence into prioritized sender and record work, so every SPF, DKIM and DMARC string a lookup shows is the one that should be there.
1 domain free up to 1,000 emails/month
Email authentication knowledge base
What is a TXT record lookup?
This TXT record lookup queries public DNS for one hostname and returns every TXT string published there, labelled by the protocol or service that reads it. TXT records carry SPF policies, DKIM public keys, DMARC policies, BIMI pointers, and the verification tokens services like Google Workspace and Microsoft 365 use to prove you control a domain. This tool runs that query and then labels each string by which system reads it.
Why does my DMARC record not show up when I look up my domain?
Because DMARC is not published on the domain itself. Receivers read it from the hostname _dmarc.yourdomain.com, so a lookup of yourdomain.com never returns it. Enter _dmarc.yourdomain.com here, or use the related-hosts links under any result. The same applies to DKIM, which lives at selector._domainkey.yourdomain.com, and BIMI at default._bimi.yourdomain.com.
How do I check a TXT record with dig or nslookup?
On macOS or Linux run dig TXT example.com, and add +short to print only the values. On Windows run nslookup -type=TXT example.com, or Resolve-DnsName -Name example.com -Type TXT in PowerShell. Replace example.com with the exact hostname you need, such as _dmarc.example.com. The output is the same raw strings this tool shows, without the classification. The full command reference, including resolver flags and PowerShell variants, is in the dig and nslookup guide linked below.
How many TXT records can a domain have?
DNS places no limit on the number of TXT records at a name, but the protocols that use them do. SPF allows exactly one record starting v=spf1 (RFC 7208), and DMARC allows exactly one v=DMARC1 record at _dmarc (RFC 9989, which replaced RFC 7489). Two SPF records return permerror, which DMARC counts as an SPF failure; two DMARC records make receivers discard the lookup and treat the domain as having no policy. Verification tokens have no such limit; a busy domain often carries ten or more.
Why is my TXT record split into several quoted strings?
A single TXT character-string is capped at 255 octets by RFC 1035. Anything longer has to be published as multiple strings inside one record, which resolvers and mail receivers join back together. Long SPF records and 2048-bit DKIM keys routinely need this. Most DNS providers split a long value automatically; this tool shows how many strings each record was published as, so you can tell a correctly split record from a truncated one.
Which DNS resolvers does this lookup use?
Queries go through Google's public resolver at 8.8.8.8, falling back to Cloudflare's 1.1.1.1. That shows you roughly what an independent third party sees, rather than what your office resolver has cached. It also means a change you made moments ago may not appear until the record's TTL expires on those resolvers.
What are all these verification tokens in my TXT records?
Strings like google-site-verification=..., MS=ms..., or apple-domain-verification=... are proof-of-ownership tokens. A service asks you to publish one, then reads it to confirm you control the domain. They are harmless to leave in place and this tool names the service behind the common ones. They are also a quiet inventory of the services you connected to this domain at some point.
Can a TXT lookup tell me whether my email is authenticated?
It tells you what is published, which is necessary but not sufficient. A perfect SPF record does nothing for a message sent from a server it does not list, and a DKIM key in DNS does not prove the mail server is signing with it. The findings here flag structural problems in the records themselves. Whether your real mail passes is settled by DMARC aggregate reports, which is what Palisade reads.
Why do I see no TXT records at all?
Either the hostname is misspelled, the domain is not registered, its name servers are not answering, or it genuinely publishes none. A root domain with no TXT records has no SPF, which matters if it sends mail. A subdomain with none is normal unless that subdomain sends mail in its own name. Check the spelling first: a missing underscore in _dmarc is the most common cause.
Every tag and mechanism across DMARC, SPF, and DKIM, explained in one place.
DMARC
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.
SPF
- v
- The version tag must exclusively be “spf1”. Incorrect or missing versions result in the SPF record being disregarded.
- ip4
- This tag lists IPv4 addresses authorized to send emails for the domain.
- ip6
- This tag specifies IPv6 addresses permitted to email on the domain’s behalf.
- a
- The A record tag permits sender validation via the domain’s IP address, defaulting to the current domain if unspecified.
- mx
- The MX record tag validates the mail server’s MX record, defaulting to the current domain if not specified.
- ptr
- The PTR tag initiates a PTR check for client IP hostnames, advised against in RFC 7208 due to excessive DNS lookups.
- exists
- The exists tag verifies the presence of an A record on the specified domain.
- include
- The include tag is crucial for accurate SPF records, confirming all listed domains/subdomains as legitimate sending sources to recipients.
- all
- The all tag is mandatory, positioned at the SPF record’s end, guiding recipients on handling emails from unauthorized sources based on its qualifiers (~, +, -, ?).
DKIM
- v
- The version tag specifies DKIM’s version, consistently required to be 1.
- p
- The public key tag, a character string created in DKIM setup, must not be left empty to remain valid.
- t
- This tag enumerates flags as a colon-separated sequence, with “y” and “s” as defined flags; any undefined flags should be disregarded.
- s
- This tag details service types relevant to the record. Absent or unrecognized service types must be overlooked by receiving servers.
- h
- This tag specifies permitted hash algorithms, defaulting to allow all. Receivers should ignore unknown algorithms, with the sender determining the list’s entries.
- n
- This tag serves as an optional note field for administrators, recommended for use only when needed.