What are DNS TXT records used for?

Understanding DNS TXT Records

A DNS TXT record stores free-form text at a domain name so that other systems can read a machine-readable policy or proof of ownership — and in practice that text does four jobs: it authenticates email (SPF, DKIM, DMARC), it proves you control a domain to services like Google or Microsoft 365, it advertises brand and reporting policies (BIMI, TLSRPT), and it configures service discovery. Despite the generic name, the meaning of any TXT record comes entirely from a prefix the reader looks for — v=spf1, v=DMARC1, google-site-verification= — and the same domain can hold many unrelated TXT records at once.

That is the summary an AI Overview would give you. What it can't show you is where each record actually lives (the root domain vs. the _dmarc and _domainkey subdomains is where most people go wrong), how the pieces map to a real resolver query, and how to read the raw strings back for a specific domain. The anatomy diagram, the at-a-glance comparison table, and the live lookup below cover exactly that.

TXT record types at a glance

Record	Published at	Prefix to look for	What it does	Reach for it when
SPF	root (example.com)	v=spf1	Lists which servers may send mail for the domain	You send email from any domain — this is the baseline
DKIM	selector._domainkey	v=DKIM1	Publishes the public key that verifies signed mail	Your mail provider gives you a selector + key to add
DMARC	_dmarc subdomain	v=DMARC1	Tells receivers what to do when SPF/DKIM fail, and where to report	You have SPF and DKIM working and want to stop spoofing
Verification	usually root	google-site-verification=, MS=	Proves you control the domain to a third party	A service (Search Console, M365, Stripe) asks you to verify
BIMI	default._bimi	v=BIMI1	Points to your brand logo for supporting inboxes	DMARC is at p=quarantine/p=reject and you want your logo shown
TLSRPT	_smtp._tls / _tlsrpt	v=TLSRPTv1	Requests reports about failed TLS for inbound mail	You run MTA-STS and want visibility into TLS failures

If you only do one thing from this table: publish SPF at the root, DKIM at the selector subdomain, and DMARC at _dmarc. That trio is what mailbox providers now require from bulk senders.

Check a domain's TXT records right now

Enter any domain to pull its live TXT records — root, _dmarc, and DKIM selectors — straight from authoritative DNS servers, without opening a terminal:

Primary Uses of TXT Records

1. SPF Records (Sender Policy Framework)

Purpose: Specifies which mail servers can send email for your domain

Format:

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

Components:

• v=spf1: SPF version
• include:: Include another domain's SPF record
• ip4:: Specific IPv4 address allowed
• ip6:: Specific IPv6 address allowed
• ~all: Soft fail (accept if SPF fails)
• -all: Hard fail (reject if SPF fails)

Examples:

# Google Workspace
v=spf1 include:_spf.google.com ~all

# Office 365
v=spf1 include:outlook.com ~all

# SendGrid
v=spf1 include:sendgrid.net ~all

# Multiple services
v=spf1 include:_spf.google.com include:sendgrid.net include:example.com ~all

Importance:

• Prevents domain spoofing
• Improves email deliverability
• Required for DMARC compliance
• Part of email authentication trio (SPF, DKIM, DMARC)

2. DKIM Records (DomainKeys Identified Mail)

Purpose: Cryptographic signature for email authentication

Format:

selector._domainkey.example.com    TXT    "v=DKIM1; k=rsa; p=[PUBLIC_KEY]"

Components:

• v=DKIM1: DKIM version
• k=rsa: Key type (RSA)
• p=: Public key (very long)

Full Example:

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

Importance:

• Proves message came from your domain
• Prevents message tampering
• Required for DMARC compliance
• Widely supported by email providers

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

Purpose: Email authentication policy and reporting

Format:

_dmarc.example.com    TXT    "v=DMARC1; p=reject; rua=mailto:admin@example.com"

Components:

• v=DMARC1: DMARC version
• p=none/quarantine/reject: Policy
• rua=: Aggregate report destination
• ruf=: Forensic report destination
• fo=: Forensic report options
• pct=: Percentage of messages subject to policy
• adkim=: DKIM alignment (strict/relaxed)
• aspf=: SPF alignment (strict/relaxed)

Full Example:

_dmarc.example.com    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1; adkim=s; aspf=s"

Importance:

• Prevents business email compromise
• Protects brand from spoofing
• Provides insight into mail authentication
• Enables subdomain protection

Domain Verification Uses

4. Domain Ownership Verification

Many services require proving domain ownership:

Google Search Console:

example.com    TXT    "google-site-verification=abcdefghijklmnopqrstuvwxyz123456"

Microsoft/Office 365:

example.com    TXT    "MS=ms12345678"

Acme/Let's Encrypt SSL:

_acme-challenge.example.com    TXT    "verification-token"

Facebook:

example.com    TXT    "facebook-domain-verification=..."

Stripe:

example.com    TXT    "stripe-verification=..."

Process:

1. Service provides verification string
2. You add as TXT record
3. Service verifies TXT record exists
4. Ownership confirmed

5. Email Provider Verification

Services need to verify domain ownership:

Mailchimp:

example.com    TXT    "mailchimp-verification=..."

HubSpot:

example.com    TXT    "hubspot-verification=..."

SendGrid:

example.com    TXT    "sendgrid-domain-verification=..."

Advanced Authentication Records

6. BIMI Records (Brand Indicator for Message Identification)

Purpose: Display company logo in email clients

Format:

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

Requirements:

• DMARC policy set to p=reject
• Valid SVG logo
• Logo must be under 32KB
• HTTPS-hosted logo

Benefit: Brand protection and recognition in email

7. DANE Records (DNS-based Authentication of Named Entities)

Purpose: Enhanced TLS certificate verification

Format:

_25._tcp.example.com    TLSA    3 1 1 [certificate_hash]
_443._tcp.example.com   TLSA    3 1 1 [certificate_hash]

Benefits:

• Certificate pinning via DNS
• Protection against rogue CAs
• Enhanced security for email and HTTPS

Service Configuration Records

8. Service Discovery

Purpose: Locate specific services

Format:

_service._protocol.example.com    TXT    "key1=value1 key2=value2"

Examples:

Autodiscover (Exchange):

_autodiscover._tcp.example.com    TXT    "product=Exchange"

SIP (VoIP):

_sip._tls.example.com    TXT    "version=1"

CalDAV/CardDAV:

example.com    TXT    ".well-known/carddavserver"

Security and Policy Records

9. CAA Policy (Certificate Authority Authorization)

While CAA is technically a different record type, often stored alongside TXT:

example.com    CAA    0 issue "letsencrypt.org"
example.com    CAA    0 issuewild "letsencrypt.org"

Purpose: Control who can issue SSL certificates

10. TLSRPT Records (TLS Report)

Purpose: Report TLS failures for email

Format:

_tlsrpt.example.com    TXT    "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

DNS TXT Record Best Practices

Managing Multiple TXT Records

Single Record (Preferred):

example.com    TXT    "v=spf1 include:_spf.google.com ~all"
example.com    TXT    "v=DMARC1; p=reject; rua=mailto:admin@example.com"

Multiple records with same name are allowed and common.

Record Length Limits

TXT records are limited to 255 characters per string, but multiple strings possible:

example.com    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..." "...CONTINUED..."

DNS tools automatically split long records.

Organization Tips

1. Document all TXT records and their purposes
2. Maintain version control of TXT record changes
3. Test before deployment (especially email records)
4. Monitor for changes by others
5. Keep records organized with comments in DNS provider

Viewing TXT Records

Command Line

# View TXT records
dig example.com TXT

# View specific subdomain
dig _dmarc.example.com TXT

# View all records
dig example.com ANY

# Pretty print
dig example.com TXT +short

Online Tools

• Inventive HQ DNS Lookup Tool
• MXToolbox TXT Record Checker
• Google Public DNS (dns.google)
• Online DNS query tools

Common TXT Record Issues

Issue 1: Character Limit Exceeded

Problem: SPF record with too many includes:

v=spf1 include:service1.com include:service2.com include:service3.com include:service4.com include:service5.com include:service6.com include:service7.com include:service8.com include:service9.com include:service10.com ~all
# Exceeds DNS limit!

Solution: Use SPF flattening or consolidation

# Create intermediate SPF record
_spf.example.com        TXT    "v=spf1 include:service1.com include:service2.com ~all"
example.com            TXT    "v=spf1 include:_spf.example.com ~all"

Issue 2: DKIM Key Too Long

Problem: Very long DKIM public key won't fit in one TXT record

Solution: DNS provider handles splitting automatically, but verify it's stored correctly

dig selector._domainkey.example.com TXT
# Should show complete key

Issue 3: Conflicting Records

Problem: Multiple verification records from different services

Solution: Multiple TXT records allowed; add all needed records

example.com    TXT    "v=spf1 ..."
example.com    TXT    "v=DMARC1; ..."
example.com    TXT    "google-site-verification=..."
example.com    TXT    "microsoft-domain-verification=..."
# All can coexist

Complete TXT Record Setup Example

Comprehensive email security setup:

# SPF (email authentication)
example.com    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

# DKIM (message signing)
selector1._domainkey.example.com    TXT    "v=DKIM1; k=rsa; p=[PUBLIC_KEY]"

# DMARC (policy enforcement)
_dmarc.example.com    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1"

# Domain verification (Google)
example.com    TXT    "google-site-verification=abcd1234"

# BIMI (logo display)
default._bimi.example.com    TXT    "v=BIMI1; l=https://example.com/logo.svg"

Conclusion

DNS TXT records serve diverse purposes from email authentication to domain verification. Understanding these uses enables you to:

• Implement robust email security (SPF, DKIM, DMARC)
• Verify domain ownership for multiple services
• Configure service discovery
• Implement advanced security features (BIMI, DANE)
• Troubleshoot email and service issues

Proper TXT record configuration is foundational to modern email security and domain management. Whether you're implementing email authentication or verifying domain ownership, TXT records are the tool for the job.