Most people first encounter a TXT record when a vendor asks them to paste a long string of gibberish into their DNS zone to prove they own a domain. That verification step is legitimate and useful, but it barely scratches the surface of what TXT records can do. TXT records are, in effect, the Swiss Army knife of the DNS world: a free-form, human-readable data store that lives inside your DNS zone and can be read by any mail server, security scanner, browser, or API that knows to look for it. Once you understand the full range of applications, you will find yourself reaching for TXT records constantly.
What a TXT Record Actually Is
A TXT record is a DNS resource record of type 16. RFC 1035 defined it simply as a way to attach arbitrary text to a domain name. The maximum length of a single string inside a TXT record is 255 characters, but the record itself can contain multiple strings that resolvers concatenate, giving you effectively unlimited data. TTL values work exactly the same as with A or CNAME records, so you control how long resolvers cache the value.
Because TXT records have no enforced schema, every application that uses them has invented its own format. Some use key=value pairs. Some use semicolon-delimited policies. Some are just opaque base64 blobs. That flexibility is both the power and the occasional headache of TXT records.
1. SPF: Tell the World Which Servers Can Send Your Email
Sender Policy Framework (SPF) lives entirely inside a TXT record published at your bare domain. It lists the IP addresses, hostnames, and third-party senders that are authorised to send email on your behalf. Receiving mail servers perform a DNS lookup during the SMTP transaction and reject or flag messages from unlisted sources.
A typical SPF record looks like this:
The ~all softfail tells receivers to accept but flag mail from unknown sources. Change it to -all for a hard reject once you are confident you have listed every sending source. Keep in mind that you can only have one SPF TXT record per domain name; multiple records are invalid and cause immediate failures.
2. DKIM: Publish Your Public Signing Key
DomainKeys Identified Mail (DKIM) uses asymmetric cryptography to sign outgoing messages. Your mail server signs each message with a private key. The public key is published as a TXT record at a special subdomain following the format selector._domainkey.yourdomain.com. Receiving servers fetch that TXT record, verify the signature, and confirm the message body was not tampered with in transit.
You can publish multiple DKIM keys simultaneously by using different selectors, which makes rotating keys painless because you add the new record before retiring the old one.
3. DMARC: Set a Policy That Ties SPF and DKIM Together
Domain-based Message Authentication, Reporting and Conformance (DMARC) is itself a TXT record published at _dmarc.yourdomain.com. It tells receiving servers what to do when a message fails both SPF and DKIM alignment, and where to send aggregate and forensic reports so you can monitor your domain's email reputation.
Start with p=none to collect reports without affecting delivery, then graduate to quarantine and finally reject once your reporting shows clean alignment.
4. Domain Ownership Verification for Third-Party Services
Google Search Console, Microsoft 365, Cloudflare, HubSpot, Mailchimp, and dozens of other platforms ask you to prove you control a domain before granting access. They do this by generating a unique token and asking you to publish it as a TXT record at your root domain or a specific subdomain.
These records are harmless to leave in place after verification and will not interfere with anything else. However, if you accumulate dozens of them over the years, periodically cleaning up old vendor verifications is good DNS hygiene.
5. BIMI: Display Your Brand Logo in Email Clients
Brand Indicators for Message Identification (BIMI) is an emerging standard that allows your company logo to appear in the inbox of supporting email clients like Gmail and Apple Mail. BIMI requires a valid DMARC policy of at least p=quarantine and a TXT record pointing to an SVG version of your logo hosted over HTTPS.
The a= attribute is a Verified Mark Certificate (VMC), required by Gmail for the logo to actually display. BIMI without a VMC still works in some clients and is worth setting up as a forward-looking measure.
6. MTA-STS and TLS Reporting for Encrypted Email Delivery
MTA-STS (Mail Transfer Agent Strict Transport Security) forces mail servers sending to your domain to use TLS. The policy itself lives at a well-known HTTPS URL, but it is activated by a TXT record at _mta-sts.yourdomain.com:
A companion TXT record at _smtp._tls.yourdomain.com enables TLS-RPT, which sends you reports whenever a sending server has trouble establishing an encrypted connection to your mail infrastructure. Both records together give you visibility and enforcement over encrypted email transport.
7. DNSBL Allowlisting and Service Discovery
Some internal tools and federated services use TXT records for service discovery or capability advertisement. The XMPP federation protocol, for example, uses SRV records for endpoints but TXT records at _xmpp-client._tcp to advertise features. CalDAV and CardDAV autodiscovery similarly uses TXT records to point clients toward server URLs. If you run any self-hosted collaboration infrastructure, check whether TXT-based discovery reduces manual client configuration for your users.
8. Certificate Authority Authorization Supplementary Checks
While CAA records (type 257) handle the main restriction on which Certificate Authorities can issue certificates for your domain, some CA workflows look for TXT-based confirmation tokens during the DNS-01 challenge used by the ACME protocol (Let's Encrypt, ZeroSSL, etc.). When you automate certificate issuance with Certbot or acme.sh using DNS validation, the tooling automatically creates and removes TXT records like this:
Understanding this mechanism helps when debugging failed certificate renewals. If the record is not visible globally at the moment the CA checks, the challenge fails.
Use our DNS Lookup tool to query the _acme-challenge TXT record and confirm it is live before triggering your ACME client's validation step.
9. Storing Arbitrary Configuration and API Data
Because TXT records are globally readable and cached by resolvers, they make a surprisingly practical low-bandwidth configuration store. Some organisations publish internal metadata this way, such as a list of authorised office IP ranges or environment identifiers that deployment scripts can query without hitting a central config server.
A build pipeline, for example, might query a TXT record to determine which cloud region a service tier is deployed to, avoiding hard-coded environment files in source code. Keep values under 255 characters per string for maximum compatibility, and set a short TTL if the data changes frequently.
This pattern works well for data that is not sensitive (TXT records are publicly readable) and does not change more than a few times per day. For high-frequency updates, a proper key-value store is the better tool.
10. Keybase and Cryptographic Identity Proofs
Several identity and cryptographic platforms, including Keybase (now part of Zoom) and certain Mastodon/ActivityPub implementations, use TXT records to let you prove that the person who controls a domain also controls a particular cryptographic key or social account. Publishing a signed attestation in your DNS zone creates an unforgeable, third-party-verifiable identity link.
Even if you do not use Keybase specifically, the pattern is worth understanding because the same mechanism underpins decentralised identity systems that are gaining traction. Your DNS zone becomes part of your cryptographic identity infrastructure.
How to Add a TXT Record Step by Step
The exact process depends on your DNS host, but the fields are consistent across all major registrars and DNS providers:
- Log in to your DNS management console (Cloudflare, Route 53, GoDaddy, Namecheap, Google Domains, etc.).
- Navigate to the DNS records section for your domain.
- Click Add Record and select type TXT.
- In the Host or Name field, enter the subdomain prefix. Use @ for the root domain. Some panels auto-append the domain, so do not duplicate it.
- Paste the full record value in the Value or Content field. Do not add surrounding quotes unless the interface explicitly requires them; most modern panels handle quoting automatically.
- Set your TTL. For records that change rarely (SPF, DKIM), 3600 seconds (1 hour) is fine. For records used in ACME challenges or frequently rotated keys, use 300 seconds.
- Save and wait for propagation.
How to Verify a TXT Record from the Command Line
Never assume a record is live just because you saved it in the control panel. Query it directly:
The +short flag strips noise from the output so you see only the record value. Querying against a public resolver like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) rather than your local resolver gives you a more realistic view of what the internet sees.
Common Mistakes to Avoid
- Multiple SPF records: Only one TXT record at the root domain may contain v=spf1. If you have two, merge them into a single record immediately.
- Leaving test records live: ACME challenge records, old verification tokens, and deprecated DKIM selectors clutter your zone and can confuse diagnostic tools. Delete them when they are no longer needed.
- Wrong subdomain prefix: DMARC must be at _dmarc.yourdomain.com, not at the root. DKIM must be at selector._domainkey.yourdomain.com. A single character error renders the entire record useless.
- Forgetting propagation time: Even with a low TTL, some resolvers cache aggressively. Always verify with an external query tool before concluding that a platform is broken.
- Quoting issues: When editing zone files directly (BIND format), string values inside TXT records must be enclosed in double quotes. Most GUI panels handle this for you, but raw zone file edits do not.
Final Thoughts
TXT records are one of the most versatile primitives in the DNS ecosystem. From protecting your email reputation with SPF, DKIM, and DMARC to enabling encrypted delivery with MTA-STS, from proving domain ownership to publishing cryptographic identity proofs, TXT records punch well above their weight. The next time you are handed a string and told to add it to your DNS, you will know exactly what you are working with and why it matters.