TXT Records: SPF, DKIM, and Domain Verification

TXT records are DNS's junk drawer—a field that stores arbitrary text, originally meant for human-readable notes like "This server maintained by Bob." Then someone realized: if you can publish text that any machine on Earth can read and verify, you can make public claims about your domain. Who can send your email. Whether you own this domain. What security policies you enforce.

That hack became critical infrastructure. TXT records now authenticate billions of emails daily, prove domain ownership to Google and Microsoft, and publish security policies that protect users from phishing. A field designed for sticky notes became the foundation of email trust.

What TXT Records Are

TXT records store arbitrary text in DNS. Unlike A records (which hold IP addresses) or MX records (which point to mail servers), TXT records can contain any string up to 255 characters. This flexibility made them the default choice for bolting new functionality onto DNS without changing the protocol.

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

This says: "Anyone querying TXT records for example.com should receive this string." What the string means depends entirely on the application reading it. DNS just stores and serves the text—it doesn't interpret it.

Here's the key insight: TXT records solve a fundamental problem. How do you make a public, verifiable claim about your domain that any machine on Earth can check? You publish it in DNS.

SPF: Declaring Who Can Send Your Email

Sender Policy Framework (SPF) uses TXT records to answer a simple question: "Is this server allowed to send email from this domain?"

Without SPF, anyone can forge the "From" address on an email. The protocol doesn't care. An attacker sends email claiming to be from your-bank.com, and nothing in the email system says otherwise.

SPF changes this. You publish a TXT record listing every server authorized to send email on your behalf:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

This breaks down:

• v=spf1 — This is an SPF record
• ip4:192.0.2.0/24 — This IP range can send our email
• include:_spf.google.com — Google's servers can send our email (for Workspace users)
• -all — Reject email from anyone else

When a mail server receives a message claiming to be from your domain, it checks your SPF record. If the sending server isn't on the list, the message fails authentication.

The final directive controls enforcement:

• -all (hard fail): Reject unauthorized email
• ~all (soft fail): Mark it suspicious but deliver it
• ?all (neutral): No enforcement

SPF doesn't verify message content or prove the sender is who they claim to be. It only confirms the sending server is authorized. But it eliminates the easiest form of email forgery: making up a "From" address.

DKIM: Proving the Message Wasn't Altered

DomainKeys Identified Mail (DKIM) goes further. It cryptographically signs outgoing email so receiving servers can verify the message wasn't tampered with in transit.

1. Your mail server signs each outgoing message with a private key
2. The signature is added to the email headers
3. The receiving server retrieves your public key from a TXT record
4. It uses the public key to verify the signature matches the message

DKIM public keys live on a subdomain called a "selector," allowing you to rotate keys without affecting all your email:

default._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

The structure:

• v=DKIM1 — This is a DKIM record
• k=rsa — Key type (RSA encryption)
• p= — The base64-encoded public key

Public keys are long—often several hundred characters. Since individual TXT strings are limited to 255 characters, DNS splits them into multiple quoted segments:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC" "3yBhP6aF7x9E2NvLmR8qT5uWz1jK4pQ6sD8cF9nV2hL" "remainder-of-key-here"

DNS concatenates these when returning the value. Most email providers generate the keys and give you the exact TXT record to add—you don't need to understand the cryptography.

DKIM complements SPF. SPF validates the sending server. DKIM proves the message content is intact. Together with DMARC (another TXT-record-based policy), they form modern email authentication.

Domain Verification: Proving Ownership

When you sign up for Google Workspace, Microsoft 365, or most SaaS platforms, they need to verify you actually control the domain before granting access.

The mechanism is elegant:

1. The service generates a unique random token
2. You add that token as a TXT record on your domain
3. The service queries DNS for the token
4. If it's there, you've proven control

Google's verification records look like this:

example.com.  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"

Microsoft uses:

example.com.  IN  TXT  "MS=ms12345678"

This works because only someone with DNS control can add records. Publishing the verification token proves ownership.

Think about why this is clever. Email verification can be intercepted. Web verification requires an existing website. But DNS verification works for any domain—even one you registered five minutes ago with nothing configured. You prove you own something by demonstrating you can speak for it.

Handling Long Records

The 255-character limit comes from DNS packet structure: each TXT string is prefixed with a length byte, and a byte can hold values 0-255.

For longer data, you have two options:

String concatenation (single record, multiple strings):

example.com.  IN  TXT  "first-255-characters" "next-portion" "final-portion"

Multiple separate TXT records:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z..."
example.com.  IN  TXT  "MS=ms12345678"

Both work. When querying TXT records, you receive all matching records and process each independently. A domain can publish SPF policies, DKIM keys, and verification tokens simultaneously without conflict.

Why This Architecture Matters

TXT records became fundamental to Internet security because DNS solves the hard problem: publishing machine-readable policies in a decentralized, globally accessible system.

DNS provides:

• Universal access — Any server can query without credentials
• Authority — Only the domain owner controls the records
• Caching — Performance without compromising security
• Flexibility — Text format accommodates new mechanisms without protocol changes

Before SPF and DKIM, email had no sender verification. Anyone could claim to send from any domain. By leveraging TXT records, the email ecosystem added authentication without redesigning SMTP. The infrastructure already existed—they just used it.

This pattern repeats across Internet infrastructure. Need to prove domain ownership? TXT record. Want to publish CAA policies controlling which certificate authorities can issue certificates for your domain? TXT record. Building a new verification system? Probably TXT records.

No new DNS features required. No complex protocols. Just text strings that any organization can publish and any server can read.