TXT Record Checker

Enter a domain to pull every TXT record at the apex plus the usual prefixed locations: _dmarc, _mta-sts, _smtp._tls, BIMI and the ownership-verification tokens.

Try an example: google.com · github.com · stripe.com

Frequently Asked Questions

Common questions about TXT records.

The format is free-form text, but the real-world contents are machine-readable. The big four at the apex are SPF policy, the M=MS ownership token for Microsoft 365, Google's site-verification string, and various SaaS verification tokens (Atlassian, Stripe, Zoom, and so on).

One DNS name can hold several TXT records side by side. Receivers pick the one they care about by matching a known prefix and ignore the rest. Stacking is fine, and it's the only way most setups work.

The email-authentication records each have their own underscore-prefixed name:

_dmarc.example.com           TXT  v=DMARC1; ...
_mta-sts.example.com         TXT  v=STSv1; id=...
_smtp._tls.example.com       TXT  v=TLSRPTv1; rua=...
default._bimi.example.com    TXT  v=BIMI1; l=...

This checker queries the apex and all of those known locations so you see them in one place. SPF is the exception, it sits at the apex with the verification tokens.

Not at scale. DKIM public keys are TXT records, but they sit under per-sender selectors like google._domainkey.example.com, and one domain can publish hundreds across different providers.

Use the DKIM checker for that. It probes over 500 known selectors and reports the provider and key strength for each.

DNS allows many. Two of them must be unique by spec: SPF (v=spf1, per RFC 7208) and DMARC at _dmarc. A second SPF record at the apex produces a permerror and the SPF check fails, which usually pulls DMARC down with it.

Verification tokens are safe to stack. The risk there is the opposite, leaving an old token in place for a service you no longer use. Audit the apex once a quarter and delete the stragglers.

How this TXT record checker works

A TXT record (RFC 1035) holds free-form text in DNS. The format is open, but most of what sits in a real-world TXT record is machine-readable: SPF policy, ownership tokens for SaaS platforms, and ACME challenges for certificate issuance.

Enter a domain above and the tool reads every TXT record at the apex in one query, then sorts each one by purpose. We also probe the well-known names that sit below the apex: _dmarc, _mta-sts, _smtp._tls, default._bimi, _acme-challenge, and tokens like _amazonses. Lookups go over DNS-over-HTTPS, with fallback across several resolvers when one is blocked.

What can a TXT record actually hold?

Any printable string up to 255 characters per chunk. Longer values are split into multiple quoted strings concatenated at lookup time. A single DNS name can publish several TXT records side by side: 

example.com  TXT  "v=spf1 include:_spf.google.com ~all"
example.com  TXT  "google-site-verification=abc123..."
example.com  TXT  "MS=ms12345678"
example.com  TXT  "stripe-verification=def456..."

That stack is normal. The receiver picks the one it cares about by matching a known prefix (v=spf1, google-site-verification=, and so on) and ignores the rest.

Why does this matter for deliverability?

SPF lives in a TXT record at the apex. So does the ownership token that proves you control the domain to Google Workspace, Microsoft 365 and most marketing platforms. If the TXT layer is wrong, mail authentication breaks before DMARC even gets a chance to evaluate.

The two failure modes we see most often: a second v=spf1 record published by accident (RFC 7208 says exactly one, anything else is a permerror), and an old verification token left behind after a SaaS subscription lapses. Neither breaks loudly. Both quietly cost you inbox placement.

Why this matters

Google and Yahoo require a working SPF record for any sender pushing more than 5,000 messages a day. Microsoft turned the same rule on for Outlook.com, Hotmail and Live in May 2025. A duplicate SPF record, or a malformed one, breaks the SPF check and trips DMARC alignment on top of it.

Our take: audit the apex TXT records once a quarter. Delete tokens for services you no longer use. Confirm there is exactly one v=spf1 record.

What to do: if a duplicate SPF shows up below, fold the includes into one record. The SPF builder validates the result.

Where to go next

DKIM keys are TXT records too, but they sit under per-sender selectors (selector._domainkey) and a single domain can publish hundreds. We don't enumerate those here. Use the dedicated DKIM checker, which probes over 500 known selectors and reports key strength for each. For the rest of the authentication stack, see the DMARC checker and the SPF checker.