TXT record
CNAME and MX both point somewhere — another name, another mail server. A TXT record points nowhere. It just holds text, and DNS was never picky about what that text meant, which turned out to be exactly the loophole a whole generation of anti-spam and domain-verification systems needed.
What it stores
A TXT record's RDATA is one or more character strings, each up to 255 bytes, quoted in the zone file:
dig shows it the same way it appears on disk:
"v=spf1 include:_spf.google.com ~all"
"google-site-verification=6P08Vd3fk2QwzGzo7Y5CvY1sT9m2N4jK3aB1cE7fXyz"
A single name can hold several TXT records at once — one domain commonly carries an SPF policy, a site-verification token for Google Search Console, and a Microsoft 365 verification string all at the same name, side by side, with no conflict between them. Nothing in the record format ties a TXT string to a single purpose; the content is what a particular service chooses to look for, and the DNS server itself has no idea what any of it means.
A single string longer than 255 bytes gets split across multiple quoted segments that a resolver reassembles transparently:
example.com. IN TXT ( "first-part-of-a-very-long-string-that-needed-"
"splitting-because-one-string-hit-the-255-byte-limit" )
That 255-byte ceiling is a hard limit from RFC 1035's character-string encoding — a single length byte prefixes each string — not something a zone-file author chooses. DKIM's public keys, covered below, are long enough to run into this regularly.
SPF: naming which servers may send mail for a domain
SMTP has no built-in way to stop anyone from claiming MAIL FROM: [email protected] and sending it from an unrelated server — the protocol accepts whatever the connecting client says. SPF (Sender Policy Framework, RFC 7208) closes that gap by publishing, as a TXT record, the exact list of servers a domain considers legitimate senders:
ip4:198.51.100.0/24 authorizes a specific network, include:_spf.google.com pulls in Google Workspace's own published sender list, and -all is the qualifier that matters most: it tells a receiving mail server to hard-fail anything not matched by the earlier mechanisms — reject it outright, rather than merely flag it. A softer ~all ("softfail") asks receivers to accept the message but mark it as suspicious, which is why a domain moving from ~all to -all should first confirm every legitimate sending source is actually listed; skipping that step gets real mail rejected the moment enforcement tightens.
DKIM: proving a message wasn't altered in transit
SPF authorizes a sending server; it says nothing about whether the message itself was tampered with along the way. DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to each outgoing message, and the corresponding public key is published — again — as a TXT record, at a name built from a selector:
The sending server signs each message's headers and body hash with its private key; the receiving server looks up this exact record, gets the matching public key, and verifies the signature. A domain can run several selectors at once — useful when rotating keys — because each selector gets its own distinct DNS name, selector1._domainkey and selector2._domainkey coexisting without conflict.
DMARC: telling receivers what to do when SPF or DKIM fails
SPF and DKIM each answer a narrow question, but neither one tells a receiving server what to actually do with a message that fails. DMARC (RFC 7489) is the TXT record that closes that loop, published at _dmarc.example.com:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
p=reject tells receivers to drop anything that fails both SPF and DKIM alignment; rua gives an address where receivers send aggregate reports back, which is how a domain owner finds out about spoofing attempts — and about their own misconfigured senders — without watching mail logs directly. Most domains start with p=none (report only, change nothing) specifically to review those reports before committing to reject and risking legitimate mail getting dropped.
Practical scenario: a marketing tool's mail starts getting rejected
A company adds a new email-marketing platform, points it at their domain, and campaigns go out fine for weeks. Then, after tightening _all from soft to hard fail as part of an unrelated security review, the marketing platform's messages start bouncing — while transactional mail sent from the company's own mail server keeps working.
The marketing platform sends from its own infrastructure, an IP range never added to this record. It was never covered by ~all either, technically, but a softfail was quiet enough that nobody noticed the gap — receiving servers accepted the mail anyway and just marked it as slightly suspicious. -all removed that tolerance. The fix is adding the platform's documented sending range (or its own include: mechanism, if it publishes one) to the SPF record — not loosening enforcement back to ~all, which would just hide the same gap again for the next unlisted sender.
Practice exercises
- Run
dig <a-real-company-domain> TXT +shortand identify which strings are SPF, which (if any) look like DKIM or site-verification tokens, and which you can't classify from the content alone. - Using this article's scenario, explain why a softfail (
~all) can mask a missing sender for a long time before a hard fail (-all) exposes it. - Explain why DKIM's public key has to live in DNS rather than, say, being hard-coded into the receiving mail server's software.
- A teammate proposes publishing a second, separate SPF-type TXT record so two teams can each manage their own list of authorized senders independently. Explain, using RFC 7208, why that plan doesn't work, and what to do instead.
TXT records carry data, but nothing about them says who is authoritative to answer for a zone in the first place — that's a separate, structural question DNS answers with its own dedicated record type: NS record.