DNS TXT Records Explained: Why Security Depends on Them

What is a DNS TXT record?

A DNS TXT record is a type of DNS record that holds free-form text data. Originally designed for human-readable notes, TXT records have become the backbone of email authentication, domain ownership verification, and various security policies.

Unlike A records (which map to IP addresses) or MX records (which route email), TXT records have no predefined format. Any string can be stored in a TXT record, which makes them incredibly flexible -- and occasionally messy.

Email authentication: The most critical use of TXT records

Three of the most important email security standards rely entirely on DNS TXT records. Without them, your domain is vulnerable to spoofing and phishing.

SPF (Sender Policy Framework)

An SPF record is a TXT record that lists which mail servers are allowed to send email on behalf of your domain:

yourcompany.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

This tells receiving mail servers: "Only Google Workspace and SendGrid are allowed to send email as yourcompany.com. Reject everything else."

For a complete setup walkthrough, see How to set up SPF records.

DKIM (DomainKeys Identified Mail)

DKIM uses TXT records to publish public keys that receiving servers use to verify email signatures. DKIM records are typically stored at a selector subdomain:

selector1._domainkey.yourcompany.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Each email service you use has its own selector and public key. See How to set up DKIM for implementation details.

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

DMARC is a TXT record published at _dmarc.yourdomain.com that ties SPF and DKIM together and defines what happens when emails fail authentication:

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

The p=reject policy tells receiving servers to reject any email that fails both SPF and DKIM alignment. See DMARC policy levels explained for the full breakdown.

Domain verification records

TXT records are used by many services to verify that you own a domain. When you sign up for a service that needs to know you control a domain, it asks you to add a specific TXT record:

yourcompany.com.  IN  TXT  "google-site-verification=abc123..."
yourcompany.com.  IN  TXT  "MS=ms12345678"
yourcompany.com.  IN  TXT  "atlassian-domain-verification=xyz..."
yourcompany.com.  IN  TXT  "facebook-domain-verification=abc..."
yourcompany.com.  IN  TXT  "apple-domain-verification=def..."

These records prove ownership at the time of verification. The problem is that they are often left in place long after they are needed.

Other TXT record uses

While CAA records have their own DNS type, they work alongside TXT records to control which certificate authorities can issue certificates for your domain.

BIMI (Brand Indicators for Message Identification)

BIMI uses a TXT record to specify a brand logo that email clients display next to authenticated messages:

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

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS uses a TXT record to signal that your domain supports encrypted email transport:

_mta-sts.yourcompany.com.  IN  TXT  "v=STSv1; id=20260527"

How to view TXT records

Using dig

# View all TXT records for a domain
dig TXT yourcompany.com +short

# View DMARC record
dig TXT _dmarc.yourcompany.com +short

# View DKIM record (replace 'selector1' with your actual selector)
dig TXT selector1._domainkey.yourcompany.com +short

# View all records (including subdomains if using AXFR)
dig ANY yourcompany.com

Using nslookup

nslookup -type=TXT yourcompany.com
nslookup -type=TXT _dmarc.yourcompany.com

Using online tools

MXToolbox TXT Lookup -- user-friendly web interface
Google Admin Toolbox Dig -- clean output
DNSChecker -- checks from multiple global locations

Common TXT record mistakes

Multiple SPF records

A domain must have only one SPF record. If you have two TXT records that both start with v=spf1, email authentication will break -- receiving servers may reject both or behave unpredictably.

# Check for multiple SPF records
dig TXT yourcompany.com +short | grep "v=spf1"
# If more than one line appears, you have a problem

The fix is to merge them into a single record:

# WRONG -- two separate SPF records
"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:sendgrid.net ~all"

# RIGHT -- one combined SPF record
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

SPF record exceeding 10 DNS lookups

SPF has a hard limit of 10 DNS lookups. Each include: and a: mechanism counts as a lookup. Exceeding this limit causes SPF to fail with a permerror, which means your legitimate email may be rejected.

# Check your SPF lookup count
# Use MXToolbox: https://mxtoolbox.com/spf.aspx

If you are over the limit, consider using SPF flattening services or reducing the number of include: mechanisms.

Stale verification records

Domain verification records for services you no longer use clutter your DNS and leak information about your vendor history. An attacker seeing heroku-domain-verification=... knows you used (or still use) Heroku, which informs their attack strategy.

Audit your TXT records quarterly and remove verification records for services you have decommissioned.

Syntax errors

A misplaced quote, missing space, or wrong prefix can silently break email authentication. Always verify after making changes:

# After updating SPF
dig TXT yourcompany.com +short

# After updating DMARC
dig TXT _dmarc.yourcompany.com +short

# Use MXToolbox to validate syntax
# https://mxtoolbox.com/SuperTool.aspx

TXT records split across multiple strings

DNS TXT records have a 255-character limit per string. Longer records (like SPF records with many includes) are split into multiple strings within the same record. Most DNS providers handle this automatically, but manual editing can break the splitting:

# This is one TXT record with two strings (correct)
"v=spf1 include:_spf.google.com include:sendgrid.net " "include:mailchimp.com include:amazonses.com ~all"

Make sure your DNS provider is joining them correctly.

Security implications of leftover TXT records

Leftover TXT records are a form of information leakage:

Vendor fingerprinting -- verification records reveal which services you use
Attack surface hints -- a Heroku or GitHub verification record suggests infrastructure worth investigating
Stale SPF includes -- if you include a service you no longer use, and that service reassigns your account identifier, someone else could potentially send email as your domain through that service

Keep your TXT records clean. Every record should have a purpose. If it does not, remove it.

For a broader look at how SPF, DKIM, and DMARC work together to protect your domain, see our email spoofing prevention guide.

How SurfaceScan helps

SurfaceScan inspects all DNS TXT records for every domain in your attack surface. It validates SPF syntax and lookup counts, verifies DKIM selectors, checks DMARC policy strength, and flags stale verification records that should be cleaned up. Findings appear in the DNS and Email Security sections with specific guidance on what to fix, so your TXT records stay clean and your email authentication stays solid.