DNS TXT record: what it stores and why email depends on it

A TXT record (Text record) is a DNS resource record type for storing arbitrary text. It was originally designed for human-readable notes attached to a domain. Over time it became the catch-all container for structured data that had nowhere else to live: SPF policies, DKIM public keys, DMARC rules, domain ownership proofs, and dozens of other values that never got their own dedicated record type in DNS.

Format and length limits

A TXT record holds one or more quoted text strings. DNS imposes a hard limit of 255 characters per string. If a value is longer, it splits across multiple strings that the DNS client concatenates when reading:

Long values, the typical case for a 2048-bit RSA DKIM key, need to be split:

The overall DNS response over UDP is capped at 512 bytes without EDNS. With EDNS0, which all modern resolvers support, the buffer grows to 4096 bytes. Responses that still exceed this fall back to TCP transparently, though very large TXT records do add measurable latency to DNS lookups.

SPF in a TXT record

SPF (Sender Policy Framework) declares which servers are allowed to send mail from a domain. Every SPF record starts with v=spf1:

This record permits mail from the 198.51.100.0/24 range and SendGrid's servers, and rejects everything else (-all). When a message arrives, the receiving MTA queries the sender domain's TXT record and checks whether the connecting IP appears in the authorized list.

There used to be a dedicated DNS record type for SPF (type 99), but RFC 7208 deprecated it. SPF lives exclusively in TXT records now.

DKIM in a TXT record

DKIM (DomainKeys Identified Mail) publishes the public key on a subdomain: selector._domainkey.domain.com. The sending server signs message headers with the matching private key. On receipt, the server reads the selector from the DKIM-Signature header, fetches the TXT record, and verifies the signature.

Key size directly determines record size. A 1024-bit RSA key fits in a single string (about 180 Base64 characters). A 2048-bit key needs two strings. Ed25519 keys (RFC 8463) are much shorter, but receiving-server support for Ed25519 is still incomplete at many providers.

DMARC in a TXT record

DMARC policy is published on the subdomain _dmarc.domain.com:

The p parameter tells receivers what to do with messages that fail both SPF and DKIM: pass them through (none), quarantine them, or reject outright. The rua parameter specifies where to send aggregate authentication reports.

Domain verification and other uses

• Ownership verification. Google Workspace, Microsoft 365, CDN providers, and mail services ask you to add a TXT record with a unique code (such as google-site-verification=... or MS=ms12345678) to prove you control the domain.
• BIMI. Brand Indicators for Message Identification stores a link to a brand's SVG logo in a TXT record on the _bimi subdomain. Supporting mail clients — Gmail, Apple Mail — display the logo next to the message in the inbox.
• MTA-STS. The mechanism for enforcing TLS on inbound mail uses a TXT record on _mta-sts to signal the policy version. The full policy lives on a web server, but the TXT record tells senders it exists and whether it has changed.
• TLSA/DANE. Pinning TLS certificates to DNS for SMTP connections technically uses the TLSA record type, but follows the same pattern of storing authentication data directly in DNS.

Common mistakes with TXT records

• Two SPF records on one domain. RFC 7208 permits exactly one SPF record. If you add a second TXT record starting with v=spf1 when connecting a new service, both records become invalid (PermError). Merge everything into a single record using include.
• Exceeding the DNS lookup limit. SPF allows a maximum of 10 DNS-querying mechanisms per evaluation: each include, a, mx, or redirect counts, including nested ones. Going over returns PermError.
• Truncated DKIM key. Copying a long key from a control panel is easy to get wrong: a missing character or an extra space breaks the signature entirely. DKIM verification fails, and if DMARC is set to reject, messages bounce.
• Stale records from old services. After switching ESPs, the previous provider's include often stays in the SPF record. It wastes lookup budget and authorizes servers you no longer control.

TXT records and email validation

When validating a single address, TXT records are not checked directly: they govern sender authentication, not whether a mailbox exists. But when auditing a domain before a send, TXT analysis is worth doing. The presence of SPF, a valid DKIM key, and a configured DMARC policy tell you whether your messages are likely to pass authentication at the receiving end, or land in spam.