Skip to content

TXT Record Lookup

A TXT record holds arbitrary text at a DNS name. In practice it carries the machine-readable policies that run modern email and service verification: SPF, DKIM, DMARC, MTA-STS, BIMI, and vendor ownership tokens. This tool returns every TXT record at a name, with multi-string records joined as receivers see them.

What lives in TXT records

TXT was designed as a place to put human-readable notes. It became the universal extension point of DNS instead, because adding a new record type requires software updates everywhere while adding a TXT record requires nothing. Almost everything you will find at a domain apex falls into one of these categories:

Name queriedPurposeStarts with
example.comSPF — which hosts may send mail as this domainv=spf1
_dmarc.example.comDMARC — alignment policy and reporting addressesv=DMARC1
selector._domainkey.example.comDKIM — the public key for a signing selectorv=DKIM1
_mta-sts.example.comMTA-STS policy version pointerv=STSv1
_smtp._tls.example.comTLS-RPT reporting addressv=TLSRPTv1
default._bimi.example.comBIMI logo and certificate locationv=BIMI1
example.comVendor domain-ownership tokensgoogle-site-verification=, MS=, stripe-verification=, …
dig +noall +answer github.com TXT
github.com.	135 IN TXT "v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com ..." "...~all"
github.com.	135 IN TXT "adobe-idp-site-verification=b92c9e999aef825edc36e0a3d847d2db..."
github.com.	135 IN TXT "stripe-verification=f88ef17321660a01bab1660454192e014de..."
Real output, abridged. Note the SPF record arrives as two quoted strings that must be concatenated.

The 255-byte rule that trips everyone up

A single character-string inside a TXT record cannot exceed 255 bytes. Longer values are split into several strings within one record, and receivers concatenate them with no separator. That is why the SPF record above appears as two quoted chunks: it is one record, not two.

Read the full explanation of txt record lookup results ↓

This matters most for DKIM, where 2048-bit keys always exceed 255 bytes. If your provider's interface makes you paste a long key, it must split it correctly — and if it inserts a space or a newline at the split point, the key silently fails verification while looking perfectly fine in the panel. This tool joins the chunks exactly as a receiver does, so what you see here is the effective value.

Publishing two SPF records is a hard failure, not a warning: RFC 7208 requires receivers to return PermError when more than one v=spf1 record exists, which means your SPF stops working entirely. Merge them into a single record and verify with the SPF checker.

Where to look for each record

TXT records do not inherit down the tree, so you must query the exact name. Looking up example.com will never show you the DMARC record — that lives at _dmarc.example.com. Underscore-prefixed names are valid DNS names even though they are not valid hostnames, and this tool accepts them.

  • SPF: query the domain itself, and also each subdomain that sends mail — SPF is not inherited.
  • DMARC: query _dmarc. plus the organisational domain. A subdomain with no DMARC record inherits the organisational policy, unless sp= says otherwise. Detailed parsing in the DMARC checker.
  • DKIM: you must know the selector. Find it in the s= tag of a DKIM-Signature header on a real message, then query <selector>._domainkey.example.com. The DKIM checker does the parsing.
  • MTA-STS: the TXT record at _mta-sts. only carries a policy ID; the policy itself is fetched over HTTPS. See the MTA-STS checker.

Common failures and fixes

  1. Verification token not detected by the vendor. Usually the record was added at the wrong name — example.com.example.com from a missing trailing dot, or @ typed literally. Query the exact name the vendor gave you and confirm the value matches character for character.
  2. Quotes stored literally. Some panels add the surrounding quotes for you; pasting "v=spf1 ..." into those panels produces a record whose value begins with a quote character. It will look right in a screenshot and fail every check.
  3. Multiple SPF records. Merge them. Two include: mechanisms in one record are fine; two records are not.
  4. More than 10 DNS-querying mechanisms in SPF. include, a, mx, ptr, exists, and redirect each count against a hard limit of 10 lookups. Exceed it and receivers return PermError, treating your mail as unauthenticated.
  5. DKIM key with a stray space or line break. The record parses but the signature fails. Compare the joined value here against the key your provider issued.
  6. Old records left behind after a migration. Stale SPF includes and dead verification tokens are not harmless — they widen your authorised sending surface and count against the SPF lookup limit. Remove what you no longer use.

Reading TXT records from the command line

# Every TXT record at a name
dig +short example.com TXT

# DMARC policy
dig +short _dmarc.example.com TXT

# DKIM key for a known selector
dig +short selector1._domainkey.example.com TXT

# Just the SPF record, with the multi-string chunks joined
dig +short example.com TXT | grep 'v=spf1' | tr -d '"'

# Ask the authoritative server, bypassing caches after an edit
dig +short @$(dig +short example.com NS | head -1) example.com TXT
The tr -d step is what receivers do implicitly when they concatenate character-strings.
TXT records are public. Never put internal hostnames, ticket numbers, or anything you would not publish on your website into one — every DNS record is world-readable by design.

Frequently asked questions

Why is my TXT record split into two parts?
Because a single character-string in a TXT record is limited to 255 bytes, so anything longer is stored as several strings inside one record. Receivers concatenate them with no separator, which is exactly what this tool shows you. It is normal for SPF records with many includes and for all 2048-bit DKIM keys.
Can I have more than one TXT record on a domain?
Yes, and most domains do — verification tokens from several vendors sit alongside SPF quite happily. The exception is SPF itself: exactly one record starting v=spf1 is permitted, and publishing two causes a PermError that disables SPF entirely.
Why can I not find my DMARC record?
DMARC lives at _dmarc.example.com, not at the domain apex, and TXT records do not inherit. Query the underscore name directly. If it still returns nothing, the record was never published or was added at the wrong name — a very common mistake is entering _dmarc.example.com in a panel that already appends the domain.
How long do TXT record changes take to appear?
The same as any other record: up to the TTL, counted from when each resolver last cached it. Negative answers are cached too, governed by the SOA minimum field, so if you check *before* publishing, that NXDOMAIN or empty answer can stick for the negative-cache period. Check the value with the SOA lookup.
What is the maximum size of a TXT record?
Each string is capped at 255 bytes, and a record may contain multiple strings. The practical ceiling is the DNS response size: beyond roughly 4096 bytes with EDNS0, responses get truncated and retried over TCP, which some poorly configured firewalls block. Keeping the whole TXT set well under 1500 bytes avoids trouble.
Do I need quotes around my TXT value?
In a zone file, yes — the value is a quoted character-string. In most web control panels, no: the panel adds them. Pasting quotes into a panel that also adds them produces a value containing literal quote characters, which breaks SPF and DKIM parsing while looking correct at a glance.
Can TXT records be used for something other than email?
Frequently. Domain-ownership verification for cloud consoles, CI/CD providers, and certificate authorities all use TXT records, and ACME DNS-01 certificate challenges publish a short-lived TXT at _acme-challenge.example.com. If a certificate issuance is failing, check that name here first.