What is a DNS TXT record?

A DNS TXT record is a resource record type that stores arbitrary text strings associated with a domain name. Originally designed in 1987 for loosely structured information, TXT records have become the workhorse of modern internet infrastructure — hosting SPF, DKIM, DMARC, MTA-STS, BIMI, domain verification tokens, and countless application-specific metadata. Almost every non-trivial domain today has multiple TXT records, and misconfiguring them breaks email, site verification, and security posture.

The specification, briefly

RFC 1035 defined TXT in 1987 as "zero or more character-strings". Each character-string is up to 255 octets. A single TXT record can contain multiple strings, which are concatenated by the consumer. RFC 7208 (SPF), RFC 6376 (DKIM), and RFC 7489 (DMARC) all ride on TXT semantics.

Wire format: a TXT RR carries RDATA of one or more length-prefixed strings. On the presentation side (zone files), you quote each string:

example.com. IN TXT "v=spf1 include:_spf.google.com ~all"

Or for longer data:

foo._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjAN..."
                                      "...continued base64..." )

The parentheses are a zone-file readability feature and do not change the on-wire data.

Canonical uses in 2026

SPF — at the domain apex:

example.com. IN TXT "v=spf1 include:_spf.google.com ~all"

DKIM — at selector._domainkey:

s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."

DMARC — at _dmarc:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

MTA-STS — at _mta-sts:

_mta-sts.example.com. IN TXT "v=STSv1; id=20260101"

TLS-RPT — at _smtp._tls:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

BIMI — at default._bimi:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg"

Domain verification — many platforms publish a token:

example.com. IN TXT "google-site-verification=abc123def456..."
example.com. IN TXT "MS=ms1234567"
example.com. IN TXT "stripe-verification=..."

CAA alternatives — not real, but some providers publish _acme-challenge TXT records temporarily during Let's Encrypt DNS-01 validation.

Multiple TXT records on one name

Unlike some record types, a single DNS name can have multiple TXT records. Each is returned as a separate answer. This is how you can have a Google verification, a Microsoft verification, and an SPF record all at the apex:

example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. IN TXT "google-site-verification=abc123"
example.com. IN TXT "MS=ms12345"

But note the RFC 7208 constraint for SPF: only one TXT record at a given name can start with v=spf1. Duplicate SPF records cause PermError.

Similarly, a DKIM selector must have exactly one TXT record. DMARC must have exactly one TXT record at _dmarc. BIMI must have exactly one at each selector._bimi.

Size and length constraints

A single character-string is 255 octets maximum. If your value exceeds 255 characters, split it:

"first 255 characters..." "next 255 characters..." "tail..."

Most DNS provider UIs handle the split automatically. Hand-edited zone files must use explicit quoting.

DNS responses over UDP traditionally max at 512 bytes. EDNS0 extends this to whatever the client advertises, often 1232 or 4096 bytes. For large TXT records (BIMI with public keys, long DKIM keys, aggregated SPF), EDNS0 is essential. Any modern resolver negotiates this, but an old corporate DNS appliance sometimes does not.

Query behavior

dig +short TXT example.com returns each TXT record on its own line, with the character-strings re-joined into quoted segments. Parse carefully if you automate this.

In programming:

• Bash: dig +short TXT domain | tr -d '"'
• Python: dnspython returns each TXT record as a list of byte strings.
• Go: net.LookupTXT returns a slice of strings; multiple TXT records flatten.

Most DNS libraries pre-join the strings into one logical value per record. A few legacy libraries do not, which is where bugs come from.

Propagation and TTL

TXT records behave like any DNS record for caching purposes. TTL controls how long resolvers cache. For SPF and DKIM, typical TTL is 3600 (1 hour) to 86400 (1 day). For records you expect to rotate frequently (like ACME challenges), use 60 to 300.

Before a known change, lower TTL ahead of time to avoid long caching during the cutover.

Pitfalls

Copy-paste whitespace. Pasting from a provider's UI sometimes includes invisible characters or line breaks that break parsing. Always test with dig +short TXT.

Mixing HTML entities with DKIM keys. If you copy a DKIM key from a web page, sometimes & or Unicode quotes sneak in. Base64 keys contain only A-Za-z0-9+/= — nothing else.

Wrong record type. Some DNS UIs label a text record as "SPF" and actually create an SPF record type (type 99). SPF is deprecated as a record type — always use TXT.

Missing leading underscore. dmarc.example.com is wrong; _dmarc.example.com is correct. Same for _domainkey, _mta-sts, _smtp._tls.

Publishing at the wrong zone. Adding _dmarc.example.com when your zone is mail.example.com puts the record at _dmarc.mail.example.com. Check the displayed record name in your provider's UI.

Root vs. subdomain. Some providers use @ for apex, others require empty name, others want the full FQDN. Test with dig after creation.

CNAME conflict. If a name has a CNAME, it cannot have any other record type. Some providers silently accept both and return whichever they feel like. DKIM selectors often use CNAMEs (Microsoft 365) — do not add a TXT at the same name.

Reading a TXT record well

Always re-read in the authoritative format to avoid UI-level confusion:

dig TXT example.com +noall +answer

You see exactly what the authoritative server returns. This sidesteps any provider-side UI quirks.

Non-standard uses worth knowing

• Ownership verification by CA during certificate issuance (Let's Encrypt DNS-01).
• Google/Microsoft/Facebook/Slack site verification tokens.
• Proof-of-control for open-source projects (GitHub Pages custom domains).
• SMTP-specific tokens for Amazon SES, SendGrid, Mailgun.
• Experimental standards — new mail and identity standards often debut as TXT records before getting their own type.

Historical note: SPF record type (type 99)

RFC 4408 defined a dedicated SPF record type. RFC 7208 deprecated it. Do not publish SPF records with type 99; some resolvers do not even query type 99 anymore. Always use TXT.

When to use IntoDNS.ai

IntoDNS.ai pulls every TXT record on your domain and classifies them: SPF, DMARC, DKIM selectors, verification tokens, MTA-STS, BIMI, and unclassified others. It flags duplicate SPF entries, misplaced records (like a DMARC record at the apex instead of _dmarc), and length/format issues that would cause PermError. For a quick audit of every TXT record on your domain, one scan is enough.

Security considerations for TXT records

TXT records are world-readable. Anything you publish in a TXT record is visible to anyone who queries your domain. This means:

• Do not put secrets in TXT records. Verification tokens are not secrets (they are proof of control at a moment in time), but do not publish API keys, internal server names, or other sensitive data.
• Acme DNS-01 challenges include a temporary token derived from a Let's Encrypt account. The token itself is not a secret, but the publication window should be short — remove the record after validation.
• Domain verification tokens are often long-lived and fine to keep published. Some platforms (Google, Microsoft, Facebook) keep verifying them periodically; removing them can un-verify your domain.

Record enumeration and privacy

A domain's full TXT record set is discoverable by anyone with dig. For a competitor doing recon on your tech stack:

• The set of verification tokens reveals which SaaS tools you use.
• SPF reveals your email infrastructure.
• DKIM selector presence reveals your mail sending platforms.

If this is a concern, consolidate. Keep only the verification tokens that are currently required. Rotate when you switch platforms. This does not prevent enumeration, but reduces the value.

The "SPF record type" deprecation (type 99)

RFC 4408 (2006) introduced a dedicated SPF resource record type, distinct from TXT. RFC 7208 (2014) deprecated it, requiring SPF to be published as TXT only. Some legacy DNS software and a few DNS control panels still show an "SPF" record type option — do not use it. Resolvers that query for type 99 will not find modern SPF records, and DNS providers that try to auto-publish as type 99 create confusion.

TXT and subdomain inheritance

TXT records do not inherit from parent to child. A TXT record at example.com does not apply to mail.example.com. This is different from some other records (like MX which applies to the exact name) and is occasionally confusing:

• SPF at example.com covers only example.com — mail sent from mail.example.com is unprotected unless that subdomain has its own SPF.
• DMARC at _dmarc.example.com covers the organizational domain, and sp= applies to subdomains. But if a subdomain publishes its own _dmarc. record, that overrides inheritance.
• DKIM selectors are always published at the exact selector._domainkey.subdomain.example.com for the subdomain that will sign.

Debugging TXT record issues

A diagnostic sequence for any TXT record problem:

1. Query authoritatively: dig +short TXT example.com @ns1.yourdnsprovider.com.
2. Query via public resolver: dig +short TXT example.com @1.1.1.1.
3. Query via another public resolver: dig +short TXT example.com @8.8.8.8.
4. Compare. Differences indicate caching or propagation lag.
5. If all three match but your application still does not see the record, the application's DNS library may be the problem.