TXT records hold arbitrary text in DNS, and email authentication uses them for almost everything: SPF at the domain apex, DMARC at _dmarc, DKIM public keys at selector._domainkey, plus MTA-STS and TLS reporting. This lookup dumps every TXT record at a name, including duplicates that break things.

How to read your result

Every TXT record published at the name you entered, with a label identifying what each one is where the checker can tell. Unrecognised records are shown as-is rather than hidden — domain verification strings and vendor tokens are legitimate and often numerous.

The count matters as much as the contents. Two records of the same kind at one name is a failure mode for SPF and DMARC, and it is invisible unless you look at the whole set.

The names worth checking

The domain itself — SPF lives here, at the apex, along with most verification strings.
_dmarc plus the domain — the DMARC policy. A record at the apex instead does nothing.
selector._domainkey plus the domain — a DKIM public key. You need the selector from a message's DKIM-Signature header to know which to check.
_mta-sts plus the domain — the MTA-STS version marker, which points at a policy file served over HTTPS.
_smtp._tls plus the domain — where TLS reports are sent.

The four most common failures

Two SPF records at the apex

Two records beginning v=spf1 is a permanent error, not a merge — the whole SPF evaluation fails. It happens when a second vendor's setup guide is followed literally after the first. This lookup is the fastest way to see it, because the SPF checker may only report the symptom.

The 255-character split

A single TXT string cannot exceed 255 characters. Longer values, notably 2048-bit DKIM keys, must be published as several quoted strings that the resolver joins back together. Some DNS panels handle it, some need you to split manually, and a few truncate silently — producing a value that looks present and never works.

Quoting that ends up inside the value

Depending on the panel, quotes you type may be stored literally rather than treated as delimiters, leaving a value that begins with a quote character. It reads correctly to a human and fails to parse. If a record looks right but nothing honours it, check for stray quotes.

Verification records that outlived their purpose

Domain-verification strings accumulate for years after the service is gone. They are mostly harmless, but they are clutter that makes real problems harder to see, and each one is a small statement about which vendors have or had access to your domain. Removing dead ones is good hygiene.

A worked example

A healthy apex, with one SPF record and two verification strings:

"v=spf1 include:_spf.google.com -all"
"google-site-verification=abc123..."
"stripe-verification=def456..."

Exactly one v=spf1 record. This is the thing to confirm.
Verification strings are unrelated to mail and can coexist freely.
No DMARC here — it belongs at _dmarc, and its absence at the apex is correct.

Related checks

SPF checker — parses the record and counts its DNS lookups.
DMARC checker — reads the policy at the right name for you.
DKIM checker — probes common selectors when you do not know one.
MX lookup — MX records are not TXT and will not appear here.
Full domain check — all of the above in one pass.

Look up TXT records