BRev TXT record — text, and everything built on it
TXT was designed to hold arbitrary text about a name, and that openness made it the place every later convention landed. SPF, DKIM, DMARC, MTA-STS, BIMI, domain-ownership verification for Google, Microsoft, Atlassian and hundreds of others, and ACME’s DNS-01 challenge all live in TXT records, distinguished only by a prefix in the value or by the name they sit on.
The formatting rule that trips people is the 255-character string limit. A single TXT character-string cannot exceed 255 bytes, so longer values — DKIM public keys especially — are stored as several quoted strings that the resolver concatenates with nothing between them. A DKIM key that is broken because the chunks were joined with a space, or split at the wrong point, is a standard failure, and the resulting signature check fails without any obvious clue.
The SPF rules deserve their own note because they are enforced. A domain must publish exactly one SPF record — two v=spf1 records is a permanent error, and senders may fail the check entirely rather than picking one. And SPF evaluation is capped at ten DNS-querying mechanisms (include, a, mx, ptr, exists, redirect); exceeding it produces a permerror that many receivers treat as a failure, which is why chaining several vendors’ includes quietly breaks mail.
What a TXT record looks like
Type 16 · Text — SPF, verifications, DKIM, arbitrary data. Zone-file form below — owner name, TTL, then the record and its RDATA.
| Name | TTL | Record | What it means |
|---|---|---|---|
| example.com. | 3600 | "v=spf1 include:_spf.google.com include:sendgrid.net -all" | One SPF record only. Each include counts toward the ten-lookup limit; -all is a hard fail. |
| _dmarc.example.com. | 3600 | "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100" | DMARC always lives on the _dmarc subdomain, never at the apex. |
| sel1._domainkey.example.com. | 3600 | "v=DKIM1; k=rsa; p=MIIBIjANBg…" "…kqhkiG9w0BAQEFAAOC" | A DKIM key split into two quoted strings; the resolver concatenates them with nothing in between. |
| _acme-challenge.example.com. | 60 | "gfj9Xq...Rg85nM" | An ACME DNS-01 challenge — a very short TTL, because it exists for minutes. |
The mistakes that break production
Two SPF records on one domain
Adding a vendor’s SPF as a second record rather than merging its include into the existing one. Exactly one v=spf1 record is permitted; two is a permanent error and the check may fail outright. Merge the mechanisms into a single record instead.
A DKIM key that fails to verify with no obvious reason
Usually the 255-byte split. The key must be stored as adjacent quoted strings that concatenate with nothing between them — a space inserted at the join, or a control panel that mangles the quoting, corrupts the key. Query the record and compare the reassembled value byte for byte against what the signer published.
Query a TXT record now
The box below is seeded with example.com. Choose TXT as the type and press Look up — the query goes from your browser straight to Cloudflare or Google over DNS-over-HTTPS, with no server of ours in the path.
DNS is the internet's address book: it turns a name like example.com into the addresses and service endpoints machines actually connect to. Every record has a type (what kind of fact it states) and a TTL (how long resolvers may cache it).
Record types
| Type | What it stores |
|---|---|
| A | IPv4 address |
| AAAA | IPv6 address |
| CNAME | Canonical name (alias) |
| MX | Mail exchanger (priority target) |
| TXT | Text — SPF, verifications, DKIM, arbitrary data |
| NS | Authoritative nameservers |
| SOA | Start of authority (serial, refresh, retry, expire, minimum) |
| SRV | Service locator (priority weight port target) |
| CAA | Which CAs may issue certificates |
| PTR | Reverse DNS (IP → name) |
| DNSKEY | DNSSEC public key |
| DS | Delegation signer (DNSSEC chain of trust) |
| HTTPS | HTTPS service binding (ALPN, ECH, hints) |
| SVCB | General service binding |
| TLSA | DANE — pin certificates in DNS |
| NAPTR | Name authority pointer (SIP/ENUM) |
TTL & “propagation”
DNS changes don't “push” anywhere — resolvers simply keep the old answer until its TTL runs out, then fetch the new one. So a change “propagates” in at most the old record's TTL. Planning a change? Lower the TTL (e.g. to 300s) a day in advance, make the change, then raise it back. The compare card above shows whether major public caches have picked your change up yet.
FAQ
How long can a TXT record be?
Each character-string is capped at 255 bytes, but a record may hold several strings and the resolver joins them with nothing between. The practical limit is the DNS response size, not 255.
Can I have more than one TXT record on a name?
Yes, and it is normal — verification tokens from several vendors sit side by side. The exception is SPF: exactly one v=spf1 record per domain, or the check errors.
Why is SPF stored in a TXT record?
A dedicated SPF record type (type 99) was defined and then deprecated in RFC 7208, because deployment of a new type across the internet proved harder than reusing TXT. TXT is now the only correct place for it.