A TXT record carries one or more character strings. DNS defines the
container; the protocol querying a particular owner name defines what the text
means.
Purpose and type code
IANA registers TXT as type code 16
[1]. RFC 1035
defines its RDATA as one or more character-string values and says the
semantics depend on the domain where the record is found
[2].
TXT is used by SPF, DKIM, DMARC, service verification, and other protocols. Those uses are independent and often query different owner names.
Presentation format
example.com. 3600 IN TXT "v=spf1 -all"
_service.example.com. 300 IN TXT "verification-token"One character-string can hold at most 255 data octets because its wire format uses a one-octet length. Long logical values may be represented by multiple quoted strings in one TXT RDATA. Confirm how the consuming protocol joins or interprets them; do not confuse multiple strings in one record with multiple records in an RRset.
Owner-name and coexistence rules
TXT can coexist with most ordinary data and with other TXT records at the same owner. It cannot coexist at a CNAME alias owner. Multiple TXT records are not automatically alternatives or fragments of one policy.
For example, SPF is specifically published in TXT type 16, and an SPF consumer must distinguish SPF content from unrelated TXT records [3]. DKIM selectors and DMARC use their own defined owner names.
Caching and changes
Resolvers cache the TXT RRset by TTL. Deleting a verification token or changing a policy does not remove cached copies immediately. Coordinate policy changes with the service that consumes the record and retain rollback evidence.
Security and operational limits
TXT is not a secret store. Anyone able to query public DNS can read the value. Do not publish passwords, API keys, private keys, or personal data. A token proves control only according to the external service’s verification process; stale tokens should be reviewed and removed.
Large or numerous TXT records can increase DNS response size. A syntactically valid TXT answer is not proof that SPF, DKIM, DMARC, or another application policy is valid.
Verify
Query TXT at the protocol’s exact owner name, not only the zone apex. Inspect the complete RRset and string boundaries, then use a protocol-specific checker to validate meaning. Record the owner, TTL, answer source, and observation time.
Next step
Continue to the CAA record reference for certificate-issuance authorization, or use the safe DNS-change checklist before replacing production policy and verification records.