TXT record
A DNS record that stores arbitrary text. Used for domain ownership verification, SPF email policies, DKIM signatures, and ACME certificate validation.
A TXT record holds free-form text strings on a hostname. It's the catch-all of DNS: any time a system needs to associate metadata with a domain (without inventing a new record type), it uses TXT.
example.com. TXT "v=spf1 include:_spf.acme.com ~all"
acme._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
_acme-challenge.example.com. TXT "abc123-acme-token"
Common uses
| Use case | Pattern | Why TXT |
|---|---|---|
| Domain ownership verification | "yourapp-verification=abc123" | Easy to check programmatically |
| SPF (email auth) | "v=spf1 …" | Standard since RFC 4408 |
| DKIM (email auth) | "v=DKIM1; …" | Standard since RFC 6376 |
| DMARC (email auth) | "v=DMARC1; …" | Standard since RFC 7489 |
| ACME DNS-01 challenge | random token | Required by ACME for wildcard certs |
Verification flow for custom domains
When a customer adds a custom domain to your SaaS, you typically issue them a unique token like yourapp-verification=k4j8sd9f and tell them to set:
_yourapp.acme.com. TXT "yourapp-verification=k4j8sd9f"
Your background worker periodically resolves that record and matches the token. When it matches, you flip the domain to "verified" and proceed with cert issuance.
This is more reliable than CNAME-based verification (which can fail mid-setup if the customer overrides their apex by mistake) and works even when the customer hasn't yet pointed the actual hostname at your edge.
Limits
Each TXT record's value is technically a series of 255-byte chunks. Most DNS providers handle the chunking automatically when you paste a long string, but very long DKIM public keys can hit the 255-byte limit and need explicit chunking.