The TXT record is the most overloaded resource record in DNS. RFC 1035 defined it in 1987 as a way to attach "descriptive text" to a domain name, with no prescribed structure and no particular machine purpose. Nearly four decades later, that blank canvas carries the data that determines whether an email reaches an inbox or lands in spam, whether Google believes you own a domain, and whether a receiving mail server will reject a forged message on your behalf. The gap between the record's humble origin and its current operational weight is the source of most TXT-related confusion.
Understanding TXT records matters because they are now the enforcement layer for email authentication (SPF, DKIM, DMARC), the proof mechanism for domain verification (Google, Microsoft, Facebook, Stripe), and the publication channel for security policies like MTA-STS and BIMI. A single missing or malformed TXT record can silently degrade email deliverability for weeks before anyone notices. This guide walks through how TXT records actually work at the wire level, what each major use case requires, and how to keep a growing collection of them from becoming a liability.
How TXT Records Work
A TXT record stores one or more character strings in the DNS zone for a given name and TTL. The DNS wire format limits each individual string to 255 bytes. When a TXT record needs to carry more data than that, which happens frequently with SPF records that include many providers and with DKIM keys using 2048-bit RSA, the value is split into multiple concatenated strings within a single record. The receiving application is responsible for joining those strings back together in order. Most DNS providers handle this splitting transparently, but hand-editing zone files or using APIs that treat the value as a single field can introduce breakage at the 255-byte boundary.
Unlike CNAME records, which must be the only record at a given name, multiple TXT records can coexist at the same DNS name. A domain's apex commonly holds an SPF record, a DMARC policy (at a subdomain), one or more domain-verification tokens, and sometimes a BIMI record or a custom key-value pair, all as separate TXT records. DNS returns all TXT records for a queried name in a single response, and the consuming application is expected to identify which record it cares about by inspecting the content, typically by looking for a version prefix like `v=spf1` or `v=DMARC1`.
This design means that adding a new TXT record never overwrites an existing one, but it also means that stale records accumulate silently. A verification token published three years ago for a service you no longer use still occupies space in every DNS response. At scale, that clutter contributes to larger UDP responses that may require TCP fallback or EDNS, and it makes the zone harder to audit when something breaks.
Email Authentication TXT Records
The three pillars of modern email authentication, SPF, DKIM, and DMARC, are all published as TXT records, each at a specific DNS name and with a specific syntax. Getting any one of them wrong does not always produce an immediate, visible error. Instead, it degrades authentication results quietly, and the effects surface weeks later as declining inbox placement or as aggregate DMARC reports that nobody reads.
SPF: Sender Policy Framework
SPF is published as a single TXT record at the domain's apex (or at the envelope-sender domain, for subdomains). It declares which IP addresses and hostnames are authorized to send email on behalf of the domain. The record always begins with `v=spf1` and ends with an `all` qualifier that defines the default policy for senders not explicitly listed.
example.com. 300 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"The critical constraint is the 10-lookup limit defined in RFC 7208. Every `include`, `a`, `mx`, `redirect`, and `exists` mechanism in the record costs one DNS lookup during evaluation. Nested includes count toward the same budget. When the total exceeds 10, the SPF check returns `permerror`, which most receivers treat as a failure. This is the single most common SPF problem in production, and it tends to appear after the third or fourth SaaS provider is added to the record. Use the SPF Builder to check your lookup count before publishing.
DKIM: DomainKeys Identified Mail
DKIM works differently from SPF. The sending mail server signs each outbound message with a private key, and the corresponding public key is published as a TXT record at `selector._domainkey.example.com`, where the selector is a label chosen by the signing system. A domain typically has multiple DKIM selectors, one per sending service.
google._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNA..."The public key in the `p=` tag is Base64-encoded and often exceeds 255 bytes for 2048-bit keys, which means the TXT record will be split into multiple concatenated strings at the wire level. Misconfigured splitting is a common cause of DKIM verification failures that appear as `body hash did not verify` errors in message headers. The DKIM Discovery tool can probe common selectors and validate that the published key parses correctly.
DMARC: Domain-based Message Authentication
DMARC ties SPF and DKIM together by telling receivers what to do when neither mechanism passes with alignment, and where to send aggregate reports about authentication results. It is published as a TXT record at `_dmarc.example.com`.
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"The `p=` tag defines the policy: `none` (monitor only), `quarantine` (flag suspicious messages), or `reject` (drop failures outright). Starting at `none` and moving to `reject` after reviewing reports is the standard deployment path. The `rua=` tag specifies where aggregate XML reports are sent, and reviewing those reports is the only reliable way to find unauthorized senders or misconfigured legitimate ones before tightening the policy. The DMARC Builder generates correctly formatted records and helps you choose alignment settings.
Domain Verification TXT Records
Beyond email, TXT records are the standard mechanism for proving domain ownership to third-party services. The pattern is always the same: the service gives you a unique token, you publish it as a TXT record at your domain's apex (or at a specified subdomain), and the service queries DNS to confirm you control the zone. Once verification succeeds, some services no longer check the record, while others require it to remain published indefinitely.
- Google Search Console: publish a TXT record like `google-site-verification=dENr...xyz` at the domain apex. Required to stay published for ongoing verification.
- Microsoft 365: publish `MS=ms12345678` at the apex during initial tenant setup. Microsoft also uses this to verify custom domains added to Entra ID.
- Facebook domain verification: publish a token at the apex to claim the domain in Business Manager, required for link editing permissions and branded content.
- Stripe: publish a verification string to prove ownership before activating custom domains for payment links or hosted checkout.
- Atlassian: publish an organization-specific token to verify domain ownership for managed Atlassian accounts and SSO enforcement.
The operational risk is accumulation. Each verification adds another TXT record at the apex. Over time, domains that integrate with many services can end up with a dozen or more TXT records, most of which nobody remembers the purpose of. Documenting which record belongs to which service, and removing records that are no longer needed, prevents the zone from becoming an archaeology project during the next incident.
Security Policy TXT Records
TXT records also carry security policies that go beyond basic email authentication. These are less widely deployed but increasingly important for organizations that want defense in depth.
MTA-STS: Mail Transfer Agent Strict Transport Security
MTA-STS tells sending mail servers that your domain requires TLS for SMTP connections and will not accept plaintext fallback. It uses a TXT record at `_mta-sts.example.com` to signal that a policy file exists at `https://mta-sts.example.com/.well-known/mta-sts.txt`. The TXT record contains a version identifier and a unique ID that changes whenever the policy is updated, prompting senders to re-fetch the policy file.
_mta-sts.example.com. 300 IN TXT "v=STSv1; id=20260601T010000"BIMI: Brand Indicators for Message Identification
BIMI allows a domain to specify a brand logo that participating mail clients (Gmail, Apple Mail, Yahoo) display next to authenticated messages. It is published as a TXT record at `default._bimi.example.com` and points to an SVG logo file and optionally a Verified Mark Certificate (VMC).
default._bimi.example.com. 300 IN TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"BIMI only works when DMARC is set to `quarantine` or `reject` with passing alignment, which makes it an incentive to complete your email authentication deployment rather than a standalone feature.
CAA: Certificate Authority Authorization
CAA is technically its own record type (not a TXT record), but it belongs in this discussion because it serves the same function: publishing a machine-readable security policy in DNS. A CAA record declares which certificate authorities are permitted to issue certificates for the domain. CAs are required to check CAA before issuance, making it an effective control against unauthorized certificate issuance from CAs you did not choose.
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issuewild ";"TXT Record Best Practices
TXT records are easy to add and easy to forget. The following practices prevent the gradual accumulation of undocumented records from becoming a liability.
- Document every TXT record with a comment or internal note explaining which service it belongs to and when it was added. DNS providers do not enforce this, so the discipline must come from the team.
- Remove verification records promptly once the service no longer requires them. Stale tokens from decommissioned services add response size and audit confusion for no benefit.
- Monitor the SPF 10-lookup limit actively. Every new SaaS integration that requires an `include:` mechanism pushes you closer to permerror. The SPF Builder counts lookups before you publish.
- Be aware of DNS response size limits. Classic DNS over UDP caps responses at 512 bytes. EDNS extends this to typically 4096 bytes, but excessively large TXT record sets can still cause truncation and TCP fallback, adding latency to every lookup.
- Never publish more than one SPF record at the same name. RFC 7208 is explicit: multiple SPF TXT records at a single name produce permerror. If you need to consolidate, merge the mechanisms into one record.
- Audit TXT records quarterly on domains that integrate with many services. A quick `dig TXT example.com` reveals what is actually published, and comparing that to your documentation surfaces drift.
Inspecting TXT Records in Practice
The fastest way to see what TXT records a domain actually publishes is a direct DNS query. Here is what a moderately busy domain's TXT record set looks like in practice:
$ dig TXT example.com +short
"v=spf1 include:_spf.google.com include:sendgrid.net -all"
"google-site-verification=dENr2xV8okKMBwQn7mN3w4x_rq0a6WHbmGN_do8e6Ks"
"MS=ms98765432"
"facebook-domain-verification=abc123def456ghi789"
"atlassian-domain-verification=jkl012mno345pqr678"
$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
$ dig TXT google._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNA..."This output immediately tells you the domain uses Google Workspace and SendGrid for email, has verified ownership with Google, Microsoft, Facebook, and Atlassian, enforces a strict DMARC reject policy, and publishes a DKIM key for Google's selector. If you could not explain what each line is for, that is the signal to audit and document. The DNS Lookup Tool runs this query for you and parses the results into a structured view.
Where DomScan Helps
DomScan surfaces TXT records alongside the context needed to interpret them. The DNS Lookup Tool returns parsed TXT data for any domain. The SPF Builder validates syntax and counts lookups before you publish a change. The DMARC Builder generates correctly structured policies with reporting URIs. And the DKIM Discovery tool probes selectors across common providers to find published keys and flag parsing errors. Together, they turn TXT record management from a manual `dig` exercise into a repeatable workflow with validation built in.
Independent references: RFC 1035 defines the TXT record type and wire format. RFC 7208 specifies SPF syntax, evaluation rules, and the 10-lookup processing limit.
TXT records are the most quietly consequential part of a domain's DNS configuration. They do not affect whether a website loads, but they determine whether email is trusted, whether services believe you own the domain, and whether your security policies are actually enforced. Treating them as infrastructure rather than as one-time setup tokens is the difference between a domain that works and one that works reliably.