What is TXT Record?
Definition
A TXT record is a DNS record that attaches arbitrary text to a domain name. Originally meant for human-readable notes, it now serves two main purposes: proving domain ownership to services such as Google Search Console, and publishing email authentication policies for SPF, DKIM and DMARC. Its contents are public to anyone who queries DNS, so it must never carry secrets.
Also known as: DNS TXT record, text record, TXT, verification record
A text field that machines read
RFC 1035 defines TXT as descriptive text attached to a name. The record holds one or more character-strings, each limited to 255 bytes. Longer values, such as a 2048-bit DKIM public key, are split into several quoted chunks that the consuming software joins back together:
example.com. 3600 IN TXT "google-site-verification=Xk3f9...Qp"
example.com. 3600 IN TXT "v=spf1 include:_spf.mail-example.net -all"
s1._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
"...IDAQAB" )Most DNS dashboards handle the splitting for you. In hand-edited zone files, a badly split key is one of the most common reasons DKIM fails.
Proving you control a domain
Ownership checks work by having a service hand you a random token and asking you to publish it in DNS. Only someone who can edit the domain's zone can do that, which makes it strong evidence. A Domain property in Google Search Console, covering every subdomain and protocol, is verified this way, and Google's documentation says to leave the record in place after verification succeeds or the property will eventually become unverified. Email platforms, certificate authorities and many SaaS tools use the same pattern.
Where email authentication lives
All three anti-spoofing mechanisms publish their policies as TXT records, each at a different name and with its own prefix:
| Mechanism | Record name | Value starts with |
|---|---|---|
| SPF | example.com | v=spf1 |
| DKIM | <selector>._domainkey.example.com | v=DKIM1 |
| DMARC | _dmarc.example.com | v=DMARC1 |
A dedicated SPF record type once existed, but RFC 7208 deprecated it: SPF must now be published as TXT only.
Several TXT records on one name
A name can carry any number of TXT records. Seeing a Google token, a Microsoft token and an SPF policy side by side on the apex is perfectly normal, because each consumer looks only for the record with its own prefix. Trouble starts when one prefix appears twice. Two separate v=spf1 records make SPF evaluation fail outright, so adding a new mail service means adding an include to the existing policy, not creating a second one.
Keeping the zone tidy
- TXT data is public: anyone running
dig example.com TXTcan see which services you use. API keys, passwords and other secrets never belong here. - Remove verification tokens and SPF includes for services you have left. A former vendor that is still authorised to send mail as your domain is risk with no upside.
- Before deleting a token that looks stale, find out which account it belongs to; removing a live one can silently drop a verification.