A TXT record holds free-form text in DNS. That sounds trivial, but TXT records do a lot of important work: proving you own a domain, telling mail servers who may send for you, publishing DKIM keys, and answering Let’s Encrypt challenges. Here’s what they’re used for and how to get the formatting right.
For other record types, see DNS records explained.
Anatomy
example.com. 3600 IN TXT "google-site-verification=abc123…"- Name: the domain or subdomain the record belongs to (
@for the root in most panels). - Value: one or more quoted strings.
Several TXT records can exist at the same name, and that’s normal. The root domain often has an SPF record plus several verification records.
Common uses
Domain ownership verification
Services ask you to publish a token to prove control of a domain:
| Service | Typical record |
|---|---|
| Google Search Console / Workspace | google-site-verification=… |
| Microsoft 365 | MS=ms12345678 |
| Facebook / Meta | facebook-domain-verification=… |
| Many SaaS tools | <service>-verification=… on the root or a subdomain |
Once verified, some services want the record left in place for ongoing verification. Check before deleting.
SPF
example.com. TXT "v=spf1 ip4:203.0.113.25 include:_spf.google.com -all"Only one SPF record per name. Multiple v=spf1 TXT records break SPF. See SPF, DKIM and DMARC.
DKIM and DMARC
mail2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq…"
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"These live on special subdomains (selector._domainkey, _dmarc), not on the root.
Let’s Encrypt DNS-01 challenges
For wildcard certificates, or servers not reachable on port 80, ACME clients prove control with a TXT record:
_acme-challenge.example.com. TXT "gfdkjg8…"Certbot’s DNS plugins and acme.sh create and remove these automatically through your DNS provider’s API. See wildcard certificates and acme.sh.
Others
_mta-stsand_smtp._tlsfor mail TLS policies. See SMTP security._github-challenge-…and similar for platform verifications.- Keybase, BIMI and other protocol records.
Formatting long values
A single DNS string can hold at most 255 characters. Longer values (like 2048-bit DKIM keys) are split into several strings, which receivers join without spaces:
selector._domainkey.example.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"
"…remaining part of the key…" )Most web DNS panels split long values for you. Paste the whole value. If a panel adds its own quotes, don’t add extra quotes, or the record will contain literal quote characters.
Check TXT records
dig +short example.com TXT
dig +short _dmarc.example.com TXT
dig +short selector._domainkey.example.com TXT
dig +short _acme-challenge.example.com TXT @1.1.1.1Query the authoritative nameserver to skip caches: dig +short example.com TXT @ns1.your-provider.com. See dig.
Common mistakes
- Record on the wrong name: the panel’s name field already appends the domain, so
_dmarc.example.comtyped into the name field becomes_dmarc.example.com.example.com. Enter just_dmarc. - Two SPF records after adding a new email service. Merge them into one.
- Extra quotes or spaces in long values, especially DKIM keys copied from emails or PDFs.
- Deleting verification records that services still check periodically.
- TXT where a CNAME was required: some providers want DKIM published as CNAME records pointing to their keys. Follow each provider’s instructions exactly.
TTL and propagation
TXT changes follow the record’s TTL like any other DNS change. Verification tools may cache results too. If a check fails right after you add a record, confirm the authoritative answer with dig, then wait and retry. See DNS propagation.
Quick reference
| Purpose | Name | Starts with |
|---|---|---|
| SPF | @ |
v=spf1 |
| DKIM | selector._domainkey |
v=DKIM1 |
| DMARC | _dmarc |
v=DMARC1 |
| ACME DNS challenge | _acme-challenge |
random token |
| Google verification | @ |
google-site-verification= |
Related: MX records and CAA records.