KNOWLEDGE ARTICLE
What Is TXT Records?
DNS text records
Publishes text-based verification, mail policies and service configuration in DNS.
At a glance
TXT can hold arbitrary text, including SPF, DKIM public keys, DMARC policy and third-party ownership verification. Multiple TXT records may exist at one name.
One record type, many verification purposes
TXT began as a DNS resource record for human-readable text and now widely carries machine-readable policies and ownership checks. SPF, DKIM, DMARC, search-platform verification, cloud bindings and certificate issuance use distinct owner names, prefixes and syntax to distinguish their purposes.
One TXT record may contain several string fragments, displayed either joined or separately by DNS tools. Several independent TXT records may also share a name. Parsing only the first visible string or record can therefore miss data.
Keeping TXT-based protocols separate
- An apex v=spf1 record expresses SPF. DMARC uses _dmarc, while DKIM public keys live at selector._domainkey names.
- Third-party verification commonly uses a provider prefix or random token. It establishes that someone demonstrated DNS control at a particular time.
- ACME DNS-01 places temporary tokens under _acme-challenge. Automation may remove or replace them after validation.
- String-length and DNS-message limits can split long keys or policies into fragments. Reassemble logical content according to the protocol's rules.
Managing obsolete verification records
Tokens left behind after a platform is retired can imply historical relationships and create inventory noise. Some providers treat DNS verification as ongoing control evidence; potential reuse depends on their binding rules. Review records when staff or suppliers leave and during domain migrations.
Before deleting a record, check dependencies from certificate automation, email and production services. Recording its purpose, owner and review date is safer than deciding usefulness from the token's appearance alone.
Practical use and interpretation
Owner names and TXT values can be displayed directly. Known prefixes often identify a protocol or possible service connection, but a verification token alone cannot establish that the service remains in use.
If a lookup returns no expected TXT record, verify the owner name and DNS response first. Unknown DKIM selectors, delegated subdomains and temporary tokens limit discovery. No apex result does not mean the domain never uses the relevant feature.
Points to consider
A verification token suggests a service relationship at some point, but stale records do not establish current use.
Frequently asked questions
Can one domain have several TXT records?
Yes. Different protocols and services can coexist. Some protocols, such as SPF, impose their own record-count restrictions at a name.
Does a verification TXT prove current platform use?
It generally shows that a domain controller completed verification. Current DNS aliases, page resources and service responses can help distinguish active use from leftovers.
Why does a long TXT appear as several quoted strings?
A single TXT record can contain multiple string fragments. Tools may display them separately; protocol parsers combine them under the applicable rules.