What Is a TXT Record, and What Is It Used For?

Open the DNS settings for almost any domain that sends email or uses a SaaS product, and you'll find a cluster of TXT records with strange-looking values: v=spf1 ..., google-site-verification=..., long base64 blobs, and random tokens nobody remembers adding. TXT records started as a place to leave human-readable notes in DNS. Today they're one of the most heavily used record types on the internet, because they give any service a simple way to publish or check a piece of information tied to a domain.

This article explains what a TXT record is, how its data is actually structured (including the 255-character limit that trips people up), what TXT records are used for, and how to add, check, and clean them up safely. For the wider context of record types, see what DNS records are.

What Is a TXT Record?

A TXT record (text record) is a DNS record that holds one or more strings of arbitrary text attached to a domain name. It was defined in RFC 1035 back in 1987, with the intention of letting administrators publish descriptive information about a host.

DNS itself doesn't care what's inside a TXT record. It doesn't validate the content, interpret it, or enforce any format. That flexibility is exactly why TXT records became so popular: any protocol or service that needed to store something in DNS — without waiting years for a new record type to be standardized and supported — could simply agree on a text format and use TXT.

A basic TXT record in a zone file looks like this:

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

The name is example.com, the TTL is 3600 seconds, and the value is a single quoted string.

How TXT Record Data Is Structured

This is the part most guides skip, and it's the cause of many broken records.

Character strings and the 255-byte limit

The data in a TXT record isn't one long string. It's a sequence of one or more character strings, each of which can be at most 255 bytes long. Each string is stored with a single length byte in front of it, and one byte can only count up to 255.

So when you need a value longer than 255 characters — a 2048-bit DKIM public key is a common example — it must be split into multiple strings within the same record:

selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx1"
    "q2pZr8N...remaining-key-data...IDAQAB" )

The parentheses let the record span multiple lines in a zone file. Protocols like SPF and DKIM specify that the strings are concatenated with no separator when the record is read, so the two pieces above join into one continuous value.

Most DNS provider dashboards handle this split for you — you paste the long value and they chunk it. Some don't, and some show the chunks with quotes in the UI. If a long record isn't validating, splitting is the first thing to check.

Multiple TXT records vs. multiple strings

These are two different things:

1. One record with multiple strings — concatenated into a single value by consumers like SPF and DKIM.
2. Multiple separate TXT records on the same name — returned as a set, each read independently.

A single name can carry many separate TXT records, and that's normal. Your root domain might have an SPF record, a Google verification token, and a Microsoft verification token side by side:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com -all"
example.com.  3600  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"
example.com.  3600  IN  TXT  "MS=ms12345678"

Each consumer looks for the record that starts with its own prefix and ignores the rest.

Overall size

There's no fixed limit on the number of strings, but the whole response has to fit in a DNS message. Large TXT sets on one name push responses past what UDP can carry, which forces truncation and a retry over TCP. It still works, but it's slower and some poorly configured networks block DNS over TCP. Keeping your root TXT records tidy is good hygiene.

What Are TXT Records Used For?

Almost every modern use of TXT records falls into one of two categories: proving you control a domain, or publishing a policy that other servers check.

1. Domain ownership verification

When you sign up for Google Search Console, Microsoft 365, a certificate authority, or a SaaS tool, it often asks you to add a TXT record containing a unique token. The service then queries your domain for that token. Since only someone with access to your DNS could have published it, its presence proves ownership. The full process is covered in how to verify domain ownership with a TXT record.

2. Email authentication

This is the biggest use today. Three email standards live in TXT records:

Standard	Where the record lives	What it does
SPF	example.com	Lists the servers allowed to send mail for the domain
DKIM	selector._domainkey.example.com	Publishes the public key used to verify message signatures
DMARC	_dmarc.example.com	Tells receivers what to do when SPF and DKIM fail, and where to send reports

Each has its own detailed guide: SPF records, DKIM records, and DMARC records. SPF once had its own record type (type 99), but RFC 7208 deprecated it — SPF must now be published as TXT.

Related email standards also use TXT: BIMI (brand logos in inboxes), MTA-STS (_mta-sts.example.com), and SMTP TLS Reporting (_smtp._tls.example.com).

3. Certificate issuance challenges

Let's Encrypt and other ACME-based certificate authorities can validate a domain with the DNS-01 challenge, which asks you to publish a temporary TXT record at _acme-challenge.example.com. It's the only ACME method that supports wildcard certificates. See how the DNS-01 challenge works.

4. Service configuration and discovery

Some protocols use TXT records to carry configuration. DNS-based Service Discovery (DNS-SD, used by Bonjour/mDNS) pairs SRV records with TXT records holding key/value metadata about a service. Various tools also publish settings or public keys in TXT records under well-known names.

5. Human-readable notes

The original purpose still works. Some admins publish contact details or a note about who manages the zone, though in practice this is rare now because anything in DNS is public.

Underscore Names: Keeping TXT Records Organized

You'll notice many TXT records live on names that start with an underscore — _dmarc, _domainkey, _acme-challenge, _mta-sts. This convention, formalized in RFC 8552, scopes each record to a specific purpose. It keeps your root domain from accumulating dozens of unrelated TXT records and means a DMARC lookup only ever retrieves DMARC data.

When a service asks you to create a record on a name like _acme-challenge, enter just that label in your provider's "name" or "host" field. Most dashboards append your domain automatically. Entering _acme-challenge.example.com in a field that already appends the domain often produces _acme-challenge.example.com.example.com — a very common mistake.

How to Look Up TXT Records

To see every TXT record on a name, use dig:

dig TXT example.com +short

This prints each TXT record on its own line, with each character string in quotes. A long record split into multiple strings appears as several quoted pieces on the same line.

To check a subdomain-scoped record such as DMARC:

dig TXT _dmarc.example.com +short

With nslookup:

nslookup -type=TXT example.com

With PowerShell:

Resolve-DnsName -Name example.com -Type TXT | Select-Object -ExpandProperty Strings

Resolve-DnsName returns each record's strings as an array, and Select-Object -ExpandProperty Strings prints just the text.

Checking TXT records from code

In Python, the dnspython library returns each record's strings as bytes, which you can join:

import dns.resolver

answers = dns.resolver.resolve("example.com", "TXT")
for rdata in answers:
    value = b"".join(rdata.strings).decode()
    print(value)

Joining the strings with an empty separator reproduces how SPF and DKIM read multi-string records. Install the library with pip install dnspython.

In Node.js:

import { resolveTxt } from "node:dns/promises";

const records = await resolveTxt("example.com");
for (const chunks of records) {
  console.log(chunks.join(""));
}

resolveTxt() returns an array of records, where each record is an array of its string chunks, so join("") gives you the full value.

A handy pattern is to filter for a specific prefix — for example, confirming exactly one SPF record exists:

dig TXT example.com +short | grep -c '"v=spf1'

This counts the TXT records that start with v=spf1. Anything other than 1 means you have a problem: zero means no SPF record, and two or more makes SPF fail with a permanent error.

How to Add a TXT Record

In most DNS dashboards (see how to access DNS settings if you're not sure where they are):

1. Choose TXT as the record type.
2. Enter the name: @ for the root domain, or a label like _dmarc or _acme-challenge.
3. Paste the value exactly as given. Most dashboards add the surrounding quotes for you; adding your own can result in literal quote characters inside the value.
4. Set the TTL. The default (often 3600 seconds) is fine for most records. Use a shorter TTL for records you expect to change soon.
5. Save, then verify with dig.

On AWS Route 53 the value must include the quotes, and long values must be split into separate quoted strings within the same value:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_dmarc.example.com",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{ "Value": "\"v=DMARC1; p=none; rua=mailto:dmarc@example.com\"" }]
      }
    }]
  }'

The escaped quotes (\") are part of the value Route 53 expects for TXT records. If you need several TXT records on the same name in Route 53, list them all in ResourceRecords of a single record set — an UPSERT with one value would replace the others.

Common Mistakes and Best Practices

1. Creating two SPF records. If two services each tell you to add a v=spf1 record, merge them into one. Two SPF records on the same name cause a permanent error and SPF fails for all your mail.
2. Breaking long values incorrectly. A DKIM key pasted into a provider that doesn't auto-split, or split with spaces at the joins, fails verification. Verify the reassembled value against what your email provider gave you.
3. Doubled domain names. Entering a full name in a field that appends the zone produces a record at the wrong name.
4. Extra or missing quotes. Depending on the provider, quotes are either added for you or required. Check the result with dig instead of trusting the dashboard.
5. Leaving stale verification tokens. Tokens for services you no longer use add clutter and reveal which vendors you've worked with. Periodically remove ones you don't need, but confirm the service doesn't require the token to remain — some, like Google, recheck periodically.
6. Putting secrets in TXT records. Every TXT record is public and trivially queried. Never store API keys, passwords, or internal details in DNS.
7. Removing records during a migration. When you move DNS providers, TXT records are the easiest to forget, and losing SPF, DKIM, or DMARC can quietly break email. Export and compare your zone before switching — see how DNS changes affect email services.

---

TXT Record FAQ

Conclusion

The TXT record is DNS's general-purpose storage slot. It has no built-in meaning, which is precisely why it became the foundation for domain verification, SPF, DKIM, DMARC, ACME challenges, and a long list of other standards. Understanding a few details — the 255-byte string limit, the difference between multiple strings and multiple records, and the underscore naming convention — will save you from most of the errors that make these records fail.

Treat your TXT records as part of your infrastructure rather than a pile of tokens. Keep one SPF record, verify long values after you save them, remove what you no longer need, and include them in every migration checklist. When something email-related or verification-related breaks, a quick dig TXT is usually the fastest way to find out why.

Here are some useful references for going deeper on TXT records:

1. RFC 1035: Domain Names - Implementation and Specification — the original definition of the TXT record and character strings.
2. RFC 7208: Sender Policy Framework (SPF) — specifies SPF's use of TXT records and deprecates the SPF record type.
3. RFC 8552: Scoped Interpretation of DNS Resource Records through Underscored Naming — the underscore naming convention for attribute records.
4. Cloudflare Learning Center: What is a DNS TXT record? — an overview of TXT records and common uses.
5. MXToolbox: TXT Lookup — a free tool for checking the TXT records on a domain.