How to Check TXT Records: SPF, DKIM, and DMARC

TXT records are the most versatile record type in DNS. They store arbitrary text data and serve as the backbone of email authentication, domain verification, and security policies. If your SPF is misconfigured, your emails land in spam. If your DKIM is broken, recipients cannot verify your messages are authentic. If your DMARC is missing, attackers can spoof your domain freely.

This guide covers how to look up TXT records, how to interpret what you find, and how to verify that SPF, DKIM, and DMARC are configured correctly.

What TXT Records Are Used For

TXT records were originally designed for human-readable notes, but they have become essential infrastructure for several critical functions:

SPF (Sender Policy Framework)

Declares which mail servers are authorized to send email on behalf of your domain. Receiving servers check SPF to determine if an email is legitimate.

DKIM (DomainKeys Identified Mail)

Publishes public keys used to verify cryptographic signatures on outgoing email. Proves that an email was actually sent by an authorized server and was not modified in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Defines what happens when an email fails SPF or DKIM checks. Specifies whether to quarantine, reject, or do nothing, and where to send reports.

Domain Verification

Services like Google, Microsoft, and various SaaS platforms use TXT records to verify domain ownership. You add a unique token as a TXT record to prove you control the domain.

Other Protocols

TXT records also support DANE (DNS-Based Authentication), MTA-STS policies, and various other standards that encode configuration data in DNS.

How to Look Up TXT Records

Using dig

# All TXT records for the domain root
dig example.com TXT

# Short output
dig example.com TXT +short

# DKIM record (selector-specific)
dig selector1._domainkey.example.com TXT +short

# DMARC record
dig _dmarc.example.com TXT +short

# Query a specific resolver
dig @8.8.8.8 example.com TXT +short

Using nslookup

# TXT records for the domain
nslookup -type=TXT example.com

# DKIM record
nslookup -type=TXT selector1._domainkey.example.com

# DMARC record
nslookup -type=TXT _dmarc.example.com

Using Web-Based Tools

MXToolbox, DNSChecker, and Google Admin Toolbox all support TXT record lookups. MXToolbox in particular has dedicated SPF, DKIM, and DMARC checkers that not only look up the records but validate their syntax.

TXT records can appear at any name

Unlike A or MX records which typically live at the domain root, TXT records are spread across multiple names. SPF lives at the root, DKIM lives at selector._domainkey.yourdomain.com, and DMARC lives at _dmarc.yourdomain.com. You need to query each location separately.

Checking SPF Records

An SPF record is a TXT record at the domain root that starts with v=spf1. It lists the servers and IP ranges authorized to send email for your domain.

Example SPF Record

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all

This record authorizes Google Workspace servers, SendGrid servers, and the IP range 203.0.113.0/24 to send email. The -all at the end means all other sources should be rejected.

How to Verify SPF

Query the TXT records at the domain root

Run dig example.com TXT +short and look for the record starting with v=spf1. There should be exactly one SPF record.

Check that all authorized senders are included

Each include: mechanism should reference a domain that resolves to the IP ranges of your email-sending services. Each ip4: or ip6: mechanism should match servers you actually use.

Verify the policy qualifier

The record should end with -all (hard fail) or ~all (soft fail). Using +all or no qualifier effectively disables SPF. Hard fail (-all) is recommended.

Check the DNS lookup count

SPF allows a maximum of 10 DNS lookups. Each include:, a:, mx:, and redirect= mechanism counts as one lookup. Exceeding this limit causes SPF to fail permanently for your domain.

The 10-lookup limit is strict

Every include: triggers additional DNS queries, and nested includes count toward the total. If your SPF record exceeds 10 lookups, receiving servers will return a permanent error (PermError) and your SPF check will always fail. Use an SPF flattening tool if you are close to the limit.

Checking DKIM Records

DKIM records are TXT records published at selector._domainkey.yourdomain.com. The selector is a label chosen by your email provider (common selectors include google, selector1, selector2, s1, k1, default).

Example DKIM Record

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

The p= field contains the public key. Sending servers sign outgoing messages with the corresponding private key, and recipients use this public key to verify the signature.

How to Verify DKIM

You need to know your DKIM selector. Check your email provider's documentation, or examine the headers of an email sent from your domain. Look for the DKIM-Signature header and find the s= value.

# Google Workspace typically uses 'google' as the selector
dig google._domainkey.example.com TXT +short

# Microsoft 365 uses 'selector1' and 'selector2'
dig selector1._domainkey.example.com TXT +short
dig selector2._domainkey.example.com TXT +short

A valid DKIM record should contain v=DKIM1 and a non-empty p= value. If p= is empty, the key has been revoked.

Monitor Your Email Authentication Records

DNS Monitor tracks your SPF, DKIM, and DMARC records and alerts you if they are modified or removed, protecting your email reputation.

Checking DMARC Records

DMARC records are TXT records at _dmarc.yourdomain.com. They specify how receiving servers should handle messages that fail SPF and DKIM checks.

Example DMARC Record

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100

Key DMARC Parameters

Parameter	Values	Meaning
p (policy)	none / quarantine / reject	Action for messages failing both SPF and DKIM
sp (subdomain policy)	none / quarantine / reject	Policy for subdomains (inherits p if absent)
rua	mailto: address	Where to send aggregate reports
ruf	mailto: address	Where to send forensic (failure) reports
pct	0-100	Percentage of messages to apply policy to
adkim	r (relaxed) / s (strict)	DKIM alignment mode
aspf	r (relaxed) / s (strict)	SPF alignment mode

How to Verify DMARC

dig _dmarc.example.com TXT +short

Check that:

The record starts with v=DMARC1
The p= policy is set to quarantine or reject (not none, which only monitors)
A rua= address is configured to receive aggregate reports
pct=100 so the policy applies to all messages, not just a subset

Common TXT Record Misconfigurations

Multiple SPF Records

A domain must have exactly one SPF TXT record. Having two or more SPF records causes a PermError, which means SPF fails for every message. If you need to authorize multiple services, combine them into a single record using multiple include: mechanisms.

Missing DKIM Selector

If the DKIM selector in your outgoing email headers does not match a published TXT record, DKIM verification fails. This commonly happens when changing email providers without updating the DKIM DNS records.

DMARC at the Wrong Name

DMARC records must be published at _dmarc.yourdomain.com, not at the domain root. Placing a DMARC record at the root has no effect.

Stale Verification TXT Records

Domain verification tokens from services you no longer use are harmless but clutter your zone. During audits, remove TXT records for services you have deprovisioned.

Syntax Errors

A single typo in an SPF or DMARC record can invalidate the entire record. Common errors include missing semicolons in DMARC, misspelled mechanisms in SPF, and truncated DKIM keys. Always use a syntax validation tool after creating or modifying these records.

Validate before publishing

Use dedicated SPF, DKIM, and DMARC validation tools before adding or modifying these records. Catching syntax errors before they go live prevents email deliverability issues.

Putting It All Together

A complete email authentication check covers three lookups:

# 1. SPF
dig example.com TXT +short | grep spf

# 2. DKIM (replace 'google' with your selector)
dig google._domainkey.example.com TXT +short

# 3. DMARC
dig _dmarc.example.com TXT +short

If all three return valid records with correct values, your email authentication is properly configured. If any are missing, misconfigured, or have been changed unexpectedly, your domain's email reputation and security are at risk.

TXT records carry your domain's email security policy. SPF, DKIM, and DMARC work together to prevent spoofing and ensure deliverability. Regular verification is essential because even a small misconfiguration can silently degrade your email security posture.

Keep Your Email Security Records Intact

DNS Monitor continuously verifies your SPF, DKIM, and DMARC records. Get alerted immediately if any email authentication record is changed or removed.