DNS TXT Records: SPF, DKIM, and DMARC All Live Here

If you've spent any time setting up email for a domain, you've added TXT records. They show up in every email authentication guide: add this TXT record for SPF, add that TXT record for DKIM, add another for DMARC. But TXT records are also where Google asks you to prove you own your domain, where Microsoft adds their own verification codes, and where a half-dozen other services leave their fingerprints.

Understanding what TXT records actually are — and why so much important infrastructure ended up living inside them — makes all of that configuration make more sense.

What a TXT record actually is

A TXT record is exactly what it sounds like: a DNS record that holds arbitrary text. When DNS was designed, TXT records were intended for human-readable information about a domain — contact details, disclaimers, notes. They had no defined machine-readable format.

That turned out to be useful. When new standards needed a place to publish machine-readable data without waiting for new DNS record types to be standardized and supported everywhere, TXT records were the obvious choice. They work in every DNS implementation that already exists, and they accept any content.

The result is that TXT records have become the default home for almost anything a domain needs to publish that doesn't fit neatly into an A, MX, or CNAME record. Email authentication standards are the biggest category, but not the only one.

What lives in TXT records today

SPF — who can send email from your domain.

An SPF record lists the mail servers authorized to send email for your domain. Receiving servers check this when they get a message claiming to be from you.

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

Every domain should have one, and only one, SPF TXT record.

DKIM — a cryptographic signature per sending service.

DKIM records hold a public key that receiving servers use to verify that outgoing messages haven't been tampered with. Unlike SPF, DKIM records live on a subdomain — one per sending service:

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

If you send through Gmail, Postmark, and Mailchimp, you'll have three separate DKIM TXT records, each on its own subdomain with a different selector.

DMARC — the policy that governs both.

DMARC lives at a fixed location — _dmarc.example.com — and tells receiving servers what to do when SPF or DKIM fails:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

It also specifies where to send aggregate reports showing all traffic claiming to be from your domain. MyDMARC parses those reports and surfaces them as readable dashboards — the raw XML files that land in your inbox are not meant to be read directly.

Domain ownership verification.

When you connect a domain to Google Search Console, Microsoft 365, or dozens of other services, they ask you to add a TXT record containing a unique token. This proves you control the domain's DNS:

example.com.  TXT  "google-site-verification=abc123..."
example.com.  TXT  "MS=ms12345678"

These records accumulate over time. Domains that have been active for years often carry a dozen or more verification records from services connected and sometimes long forgotten.

BIMI — a brand logo in email clients.

BIMI is newer. It lets you attach a verified logo to authenticated email, displayed in supporting mail clients. It builds on DMARC — you need p=quarantine or p=reject before BIMI will work — and it's also a TXT record:

default._bimi.example.com.  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=..."

MTA-STS and TLS-RPT.

MTA-STS tells other mail servers to require TLS when delivering to your domain, and a corresponding TXT record signals that the policy is in place. TLS-RPT provides a reporting address for TLS failures, similar to how DMARC reports work for authentication failures.

Why so much ends up in TXT records

The pattern is consistent: a new standard needs to publish data per-domain, proposing a new DNS record type is a multi-year process, but a new TXT format can be deployed today. So TXT records accumulate.

This is not a design flaw — it works, and it works reliably. But it does mean that TXT records now carry infrastructure your domain genuinely depends on. A deleted SPF record can start rejecting legitimate email within hours. A removed DKIM record breaks signing for a specific sending service without any obvious error on your end.

Checking your TXT records

You can query TXT records directly from the command line:

dig TXT example.com               # SPF, ownership verification, DMARC policy hint
dig TXT _dmarc.example.com        # DMARC
dig TXT selector1._domainkey.example.com  # DKIM (replace selector1 with your selector)

For DKIM, you need to know the right selector — which is usually documented by your mail provider. Google Workspace uses google, Microsoft 365 uses selector1 and selector2, and transactional providers like Postmark or SendGrid each have their own.

If you want to see everything published on your domain at once, an online tool like dnschecker.org can query from multiple global locations at once.

How DNS monitoring fits in

TXT records are easy to overlook during DNS migrations and provider changes. An SPF or DKIM record that existed on your old nameservers doesn't automatically appear on your new ones — it has to be manually recreated. The record type most commonly forgotten during a DNS migration is a TXT record.

They're also easy to accidentally delete when editing a zone. Because TXT records are often added by third-party services through automated processes, it's not always obvious what each one does or which ones are safe to remove.

OneDollarDNS monitors every TXT record on your domain and alerts you when anything changes — a record added, a record removed, or a value modified. An SPF record that gets quietly removed during a migration shows up as a change the moment it's detected, before email deliverability starts dropping.

For the DMARC side specifically — monitoring that the DMARC record is present is one thing, but understanding what it's actually reporting is another. MyDMARC handles the reporting layer: parsing aggregate reports, identifying unauthorized senders, and telling you when it's safe to move from p=none to a stricter policy.