What Is a TXT Record

A TXT (Text) record stores arbitrary text data in DNS. While originally designed for human-readable notes, TXT records are now essential for domain verification, email authentication (SPF, DKIM, DMARC), and various security protocols. They are one of the most versatile DNS record types and you will likely have more TXT records than any other type in a production zone.

How TXT Records Work

TXT records contain free-form text, typically enclosed in quotes:

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

Multiple TXT records can exist for the same name, and a single TXT record can contain multiple strings that are concatenated. Unlike A records or CNAME records which have strict format requirements, TXT records accept virtually any text content -- which is both their strength and a source of complexity.

The 255-Character Limit

A critical detail when working with TXT records: each individual string within a TXT record is limited to 255 characters by the DNS protocol (RFC 1035). For records that exceed this limit -- which is common with DKIM keys -- the value must be split into multiple quoted strings:

example.com.    3600    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A" "MIIBCgKCAQEA2K4PavXoNY8eGK2u..."

These multiple strings are automatically concatenated by DNS resolvers. DNScale handles the splitting automatically when you enter long values through the dashboard or API, so you don't need to worry about manually breaking strings at the 255-character boundary.

When using dig to inspect long TXT records, you may see the output broken into multiple quoted strings. This is normal -- the resolver reassembles them into a single value.

Common Use Cases

Domain Verification

Prove domain ownership to third-party services. Services generate a unique token, and you add it as a TXT record. The service then queries your DNS to confirm you control the domain.

# Google Search Console
example.com.    3600    TXT    "google-site-verification=abc123..."
 
# Microsoft 365
example.com.    3600    TXT    "MS=ms12345678"
 
# Let's Encrypt (DNS-01 challenge)
_acme-challenge.example.com.    300    TXT    "gfj9Xq...token..."

For Let's Encrypt DNS-01 challenges, use a short TTL (300 seconds) since the value changes with each certificate renewal. If you use automated certificate management, the TXT record is created and deleted programmatically. See SSL/TLS Certificates for more on certificate issuance, and consider CAA records to restrict which certificate authorities can issue certificates for your domain.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which servers are authorized to send email on behalf of your domain. It works alongside your MX records to form a complete email setup.

SPF Syntax Breakdown

An SPF record begins with v=spf1 and contains a series of mechanisms:

SPF Qualifiers

The qualifier before all determines what happens to non-matching senders:

# Allow Google Workspace to send
example.com.    3600    TXT    "v=spf1 include:_spf.google.com ~all"
 
# Allow your own mail server
example.com.    3600    TXT    "v=spf1 mx a:mail.example.com -all"
 
# Multiple includes
example.com.    3600    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Only one SPF record is allowed per domain name. If you need to authorize multiple email services, combine them into a single record using multiple include: mechanisms. Having two separate SPF TXT records will cause validation failures. See Email Security: SPF, DKIM, and DMARC for a complete setup guide.

SPF Lookup Limit

SPF has a maximum of 10 DNS lookups per evaluation. Each include:, a, mx, and redirect mechanism counts as one lookup. Nested includes count too. Exceeding this limit causes SPF to return a "permerror" result, which may cause email delivery failures. If you hit this limit, consider replacing include: mechanisms with direct ip4: and ip6: entries where possible.

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to outgoing emails. The public key is published as a TXT record at a specific subdomain:

google._domainkey.example.com.    3600    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
selector1._domainkey.example.com. 3600    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBg..."

The record name follows the pattern selector._domainkey.yourdomain.com, where the selector is provided by your email service. The p= field contains the public key in base64. Since DKIM keys are often long, the 255-character string limit means these records frequently need to be split across multiple strings.

To verify a DKIM record:

dig TXT google._domainkey.example.com +short

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails:

_dmarc.example.com.    3600    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
 
# Strict policy
_dmarc.example.com.    3600    TXT    "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com"

Key DMARC tags:

Security Policies

BIMI (Brand Indicators for Message Identification):

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

MTA-STS (Mail Transfer Agent Strict Transport Security):

_mta-sts.example.com.    3600    TXT    "v=STSv1; id=20231107"

MTA-STS works alongside TLSA records and SSL/TLS certificates to enforce encrypted email transport.

Custom Application Data

Store any text data needed by your applications:

example.com.    3600    TXT    "facebook-domain-verification=abc123"
example.com.    3600    TXT    "stripe-verification=xyz789"

Record Format

Querying TXT Records with dig

# Check all TXT records for a domain
dig TXT example.com
 
# Get just the values (useful for scripting)
dig TXT example.com +short
 
# Check SPF specifically
dig TXT example.com +short | grep "v=spf1"
 
# Check DMARC
dig TXT _dmarc.example.com
 
# Check DKIM for a specific selector
dig TXT google._domainkey.example.com
 
# Query authoritative nameserver directly
dig TXT example.com @ns1.dnscale.eu
 
# Check ACME challenge record
dig TXT _acme-challenge.example.com +short

When troubleshooting email delivery issues, always check all three: SPF (dig TXT example.com), DKIM (dig TXT selector._domainkey.example.com), and DMARC (dig TXT _dmarc.example.com). All three must be correct for reliable delivery.

Adding a TXT Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Enter the subdomain or @ for apex
   • Type: Select TXT
   • Value: Enter the text content (quotes optional -- DNScale adds them automatically)
   • TTL: Set the cache duration (default: 3600)
4. Click Create Record

Using the API

Create an SPF record:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "TXT",
    "content": "v=spf1 include:_spf.google.com ~all",
    "ttl": 3600
  }'

Create a DMARC record:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_dmarc",
    "type": "TXT",
    "content": "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com",
    "ttl": 3600
  }'

Create a domain verification record:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "TXT",
    "content": "google-site-verification=abc123xyz...",
    "ttl": 3600
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "example.com.",
      "type": "TXT",
      "content": "\"v=spf1 include:_spf.google.com ~all\"",
      "ttl": 3600,
      "disabled": false
    }
  }
}

Email Authentication Setup Guide

Complete email authentication with SPF, DKIM, and DMARC. For a comprehensive walkthrough, see Email Security: SPF, DKIM, and DMARC.

Step 1: Add SPF Record

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

Step 2: Add DKIM Record

google._domainkey.example.com.    3600    TXT    "v=DKIM1; k=rsa; p=..."

Step 3: Add DMARC Record

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

Step 4: Monitor and Tighten

• Start with p=none to monitor without affecting delivery
• Move to p=quarantine after reviewing aggregate reports and confirming legitimate senders pass
• Finally use p=reject for full protection

This gradual rollout prevents accidentally blocking legitimate email. Each step should run for at least 2-4 weeks while you monitor DMARC reports.

Troubleshooting TXT Records

SPF validation failing?

1. Check you have exactly one SPF record: dig TXT example.com +short | grep "v=spf1"
2. Verify you haven't exceeded the 10-lookup limit
3. Ensure all include: targets are valid and resolvable

DKIM not passing?

1. Verify the record exists: dig TXT selector._domainkey.example.com +short
2. Check for line breaks or extra spaces in the public key
3. Confirm the selector matches what your mail server is using in signatures

Verification record not detected?

1. Some services check the apex (@), others check a specific subdomain -- verify the exact name required
2. Allow time for DNS propagation or flush your cache
3. Query the authoritative server directly: dig TXT example.com @ns1.dnscale.eu

Best Practices

1. Only one SPF record - Multiple SPF records cause delivery issues; combine into one

2. Use proper DMARC progression - Start with p=none, then p=quarantine, then p=reject

3. Keep verification records - Don't delete verification TXT records after initial setup -- many services re-check periodically

4. Quote special characters - Ensure quotes around values with spaces or special characters

5. Low TTL for challenges - Use short TTL (300s) for ACME/Let's Encrypt challenges that change frequently

6. Avoid TXT records at CNAME names - A CNAME cannot coexist with TXT records at the same name

Online tools for email authentication testing:

• MXToolbox
• DMARC Analyzer
• Mail-Tester

Related Record Types

• MX - Mail server configuration
• CAA - Certificate authority restrictions
• TLSA - DANE certificate authentication
• A - IP address records referenced in SPF
• AAAA - IPv6 addresses referenced in SPF
• CNAME - Used for DKIM selectors from email providers
• NS - Nameserver delegation
• SRV - Service discovery records

Conclusion

TXT records are versatile workhorses of modern DNS, essential for email security, domain verification, and custom application needs. Proper configuration of SPF, DKIM, and DMARC records is critical for email deliverability and security -- without them, your emails are far more likely to end up in spam folders or be rejected outright. Understanding the 255-character string limit, SPF lookup limits, and the relationship between TXT records and other record types like MX and CNAME helps you build a robust DNS configuration. DNScale makes it easy to manage all your TXT records through the dashboard or API, with automatic string splitting for long values.