DNS TXT Records: SPF, DKIM, DMARC, and Why One Typo Breaks Everything

TXT records look harmless: “just a string in DNS.” But for most domains, TXT is doing the heaviest lifting in your entire DNS zone.

• SPF uses TXT to say which servers are allowed to send mail for your domain.
• DKIM uses TXT to publish your public key so recipients can verify signatures.
• DMARC uses TXT to publish your policy and reporting addresses.
• Domain verification (Google, Microsoft, Apple, and many others) often uses TXT tokens to prove ownership.

And here’s the part people only learn after a painful incident: one typo can silently break email deliverability or weaken anti-spoofing protections.

If you want to sanity-check what the world sees right now, start with our DNS lookup tool and search for your domain’s TXT records.

Why TXT Is So Fragile (Even for Experienced Teams)

TXT records are deceptively easy to misconfigure because:

1. They’re just strings — there’s no strict schema enforcement at the DNS layer.
2. Providers render them differently — what looks like one record in a UI may be split into multiple strings behind the scenes.
3. Whitespace and punctuation matter — semicolons, colons, quotes, and even invisible spaces can change meaning.
4. Names matter as much as values — _dmarc, selector._domainkey, and root (@) have very different semantics.

The TXT Record “Stack”: SPF, DKIM, DMARC, Verification

Think of TXT as a shared bulletin board. Multiple systems post messages there, and each system expects its message to be formatted exactly right.

If you’re newer to the DNS side of this, the DNS records guide and email security overview give the mental model.

SPF: Sender Authorization (and the “One Character” Failures)

SPF is a TXT record at the root of the domain:

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

SPF mistakes that look tiny but matter

1) Two SPF records at the root

A common migration failure is leaving an old SPF record in place and adding a new one. SPF evaluation expects one policy.

; ❌ WRONG - multiple SPF records
example.com. IN TXT "v=spf1 include:_spf.oldprovider.com -all"
example.com. IN TXT "v=spf1 include:_spf.newprovider.com -all"

Your receiver may treat this as a permanent error, which can hurt deliverability.

2) A missing quote or pasted “smart quotes”

TXT values should be plain quotes. Some UIs (or copy/paste from rich text) introduce curly quotes.

; ✅ CORRECT
example.com. IN TXT "v=spf1 include:_spf.example.com -all"

3) Exceeding the SPF DNS lookup limit

SPF can trigger DNS lookups via include, a, mx, ptr, and redirect. There’s a hard limit of 10 lookups during evaluation. (This is why SPF tends to get messy over time.)

How to check SPF quickly

• Use the SPF checker to validate syntax and spot common issues.
• For a broader view of your mail auth setup, use the Email Authentication Checker.

DKIM: Signatures + Public Keys (Selectors Matter)

DKIM publishes a public key in DNS so a recipient can verify the signature attached to the email.

The record is not at the root. It’s at a selector under _domainkey:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

DKIM mistakes that break verification

1) Wrong hostname (missing _domainkey or wrong selector)

If your provider tells you to publish selector1._domainkey, publishing at selector1.example.com won’t work.

2) Key pasted with whitespace or line breaks

Some DNS providers will accept it; some won’t. Many receivers will treat the record as invalid.

3) Record splitting confusion

Some DNS control panels split long TXT values into multiple quoted chunks behind the scenes. That’s usually okay (DNS concatenates them), but editing those chunks manually can introduce extra characters.

How to check DKIM quickly

• Use the DKIM checker for a selector-based lookup.
• If you’re also troubleshooting DMARC failures, read DMARC alignment explained.

DMARC: Policy, Reporting, and Alignment

DMARC is also TXT, but it lives at a fixed subdomain: _dmarc.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

That single line can:

• Tell receivers what to do with unauthenticated mail (p=none|quarantine|reject)
• Specify where to send aggregate reports (rua=)
• Control alignment strictness (adkim= and aspf=)

DMARC mistakes that cause “false confidence”

1) Publishing DMARC at the root instead of _dmarc

This is easy to do in a rushed change window.

; ❌ WRONG - DMARC must be at _dmarc
example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

; ✅ CORRECT
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

2) Typos in tags (DMARC is picky)

rua vs r u a, missing semicolons, or v=DMARC; instead of v=DMARC1; can invalidate the record.

3) Policy set, but alignment fails

DMARC enforcement depends on SPF and/or DKIM aligning with the visible From domain. If you’re seeing “DMARC fails even though SPF passes”, alignment is usually why.

How to check DMARC quickly

• Use the DMARC checker to validate the record.
• If you’re enforcing DMARC, consider monitoring with the DMARC Report Analyzer.

Domain Verification TXT Records (Google, Microsoft, and Friends)

Verification records are often the simplest TXT records… and still easy to break.

You’ll commonly see values like:

example.com. IN TXT "google-site-verification=abcdefghijklmnopqrstuvwxyz123456"
example.com. IN TXT "MS=ms12345678"
example.com. IN TXT "apple-domain-verification=abcdefghijklmnopqrstuvwxyz"

Verification pitfalls

• Placed on the wrong name: many services require the token on the root, not on www (or vice versa).
• Deleted “because it looks old”: tokens often remain required for ongoing services.
• Accidentally merged: a token should be its own TXT record; don’t paste it into SPF.

A Practical “One Typo Breaks Everything” Checklist

Before you hit Save in your DNS provider, run through this list.

Record name checks

• ✅ SPF is at the root (example.com / @)
• ✅ DMARC is exactly _dmarc.example.com
• ✅ DKIM is selector._domainkey.example.com (selector matches your mail provider)

Record value checks

• ✅ SPF starts with v=spf1 and ends with ~all or -all (intentionally)
• ✅ DMARC starts with v=DMARC1; and includes a valid p= policy
• ✅ DKIM starts with v=DKIM1; and p= has no spaces/newlines inserted
• ✅ Verification tokens are their own records (not inside SPF/DMARC)

Change safety checks

• ✅ Take a copy of the current record text before editing
• ✅ Make one change at a time (especially during provider migrations)
• ✅ Keep TTL reasonable during planned changes, then raise it again afterward

If you need to validate TTL behavior while you’re changing records, our TTL checker can help you confirm what resolvers will cache.

How to Inspect TXT Records the Same Way Receivers Do

Different DNS providers display TXT records differently, and some UIs hide important details (like the exact hostname a record is published on).

To see what receivers will see, use DNSLens to look up the exact names that matter:

1. All TXT records at the root: use our DNS lookup tool and search your domain (this shows the TXT set at example.com).
2. DMARC TXT record: look up _dmarc.yourdomain.com (or run the DMARC checker).
3. DKIM TXT record (selector-based): look up selector._domainkey.yourdomain.com (or use the DKIM checker and enter the selector your email provider gave you).

If the record content looks right but results still fail, the most common cause is the record being published on the wrong hostname (root vs _dmarc vs selector._domainkey).

Key Takeaways

• ✅ TXT records power SPF, DKIM, DMARC, and domain verification
• ✅ The smallest mistakes (wrong hostnames, punctuation, quotes, or extra spaces) can break authentication
• ✅ SPF, DKIM, and DMARC each live at different names—root vs _dmarc vs selector._domainkey
• ✅ Verification tokens should be separate TXT records, not merged into auth records
• ✅ Regular audits prevent “quiet failures” that only show up as deliverability problems later

If you’re auditing your email routing too, see MX record priorities explained.