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 queried | Purpose | Starts with |
|---|---|---|
| example.com | SPF — which hosts may send mail as this domain | v=spf1 |
| _dmarc.example.com | DMARC — alignment policy and reporting addresses | v=DMARC1 |
| selector._domainkey.example.com | DKIM — the public key for a signing selector | v=DKIM1 |
| _mta-sts.example.com | MTA-STS policy version pointer | v=STSv1 |
| _smtp._tls.example.com | TLS-RPT reporting address | v=TLSRPTv1 |
| default._bimi.example.com | BIMI logo and certificate location | v=BIMI1 |
| example.com | Vendor domain-ownership tokens | google-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..."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 ↓Show less ↑
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.
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, unlesssp=says otherwise. Detailed parsing in the DMARC checker. - DKIM: you must know the selector. Find it in the
s=tag of aDKIM-Signatureheader 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
- Verification token not detected by the vendor. Usually the record was added at the wrong name —
example.com.example.comfrom a missing trailing dot, or@typed literally. Query the exact name the vendor gave you and confirm the value matches character for character. - 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. - Multiple SPF records. Merge them. Two
include:mechanisms in one record are fine; two records are not. - More than 10 DNS-querying mechanisms in SPF.
include,a,mx,ptr,exists, andredirecteach count against a hard limit of 10 lookups. Exceed it and receivers return PermError, treating your mail as unauthenticated. - 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.
- 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