DNS TXT Record Explained — Verification, SPF, and More

The TXT record is one of the most versatile record types in DNS. Originally designed to attach human-readable notes to a domain name, TXT records now carry machine-readable data that powers email authentication, domain ownership verification, and a growing list of security protocols. If you manage a domain, you almost certainly have at least one TXT record already — and probably need more.

This guide covers everything you need to know: the wire format, major use cases, character-limit rules, practical dig examples, and the mistakes that catch people most often.

What Is a TXT Record?

A TXT record stores one or more character strings associated with a DNS name. The DNS specification (RFC 1035) defines the record loosely — it can hold any text — which is exactly why so many protocols have adopted it as their data-publishing mechanism.

In a zone file, a TXT record looks like this:

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

The value between the quotes is the record's payload. The TTL of 3600 tells resolvers to cache it for one hour.

Tip: You can place multiple TXT records on the same name. A domain commonly has separate TXT records for SPF, domain verification, and other purposes — all coexisting on the apex.

Syntax and Format Rules

Quoted Strings

Every TXT record value is enclosed in double quotes in zone-file representation. If you need a literal double-quote character inside the value, escape it with a backslash (\").

example.com.    3600    IN    TXT    "This is a \"quoted\" value"

The 255-Character String Limit

A single DNS character string can be at most 255 bytes. This is a wire-format constraint inherited from RFC 1035, where each string is length-prefixed with a single byte. If your value is longer — and DKIM public keys routinely exceed 255 characters — you must split it into multiple strings within the same record:

selector._domainkey.example.com.  3600  IN  TXT  (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
    "2vMFoVMhg8PkKjVehMbGnYkjwVOSKfHal7mBXyXkLwEHa9FL3Rt3F9yqqHi0YP8k"
    "pJGsR1jtf6XNhR7WHwADAQAB" )

Resolvers concatenate these strings into a single value before handing them to the application. Most DNS providers — including DNScale — handle the splitting automatically when you enter a long value.

Multiple TXT Records on the Same Name

Nothing prevents you from having several TXT records on the same domain name. This is expected and normal. For instance, example.com might carry:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  3600  IN  TXT  "google-site-verification=abc123def456"
example.com.  3600  IN  TXT  "MS=ms98765432"
example.com.  3600  IN  TXT  "facebook-domain-verification=xyz789"

All four records are returned together in a single DNS response when a client queries TXT example.com. Applications pick out the record they care about by inspecting the value prefix (e.g., v=spf1).

Major Use Cases

1. Domain Verification

Cloud platforms need to confirm you own a domain before enabling services. They give you a unique token and ask you to publish it as a TXT record.

Google Search Console / Google Workspace:

example.com.  3600  IN  TXT  "google-site-verification=dFt3o9GnM7P4Qm1kL5WrV..."

Microsoft 365:

example.com.  3600  IN  TXT  "MS=ms12345678"

Stripe, Facebook, Atlassian, and others follow the same pattern — a unique string at the apex or a specific subdomain.

Tip: After verification succeeds, keep the TXT record in place. Some services re-check periodically, and deleting the record can cause your verification to lapse.

2. SPF Records

SPF (Sender Policy Framework) declares which mail servers are authorized to send email for your domain. It is published as a TXT record at the domain apex.

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

The v=spf1 prefix tells receivers this is an SPF policy. The mechanisms (include, ip4, mx, a) list allowed senders, and the trailing all qualifier defines what happens to everything else: -all (hard fail), ~all (soft fail), or ?all (neutral).

Tip: You must have exactly one SPF record per domain name. Publishing two v=spf1 records causes a permanent error (PermError) and mail delivery problems. If you use multiple sending services, combine them into a single record.

3. DKIM Public Keys

DKIM (DomainKeys Identified Mail) lets a receiving mail server verify that an email was cryptographically signed by an authorized sender. The public key is published as a TXT record under selector._domainkey.yourdomain.com:

google._domainkey.example.com.  3600  IN  TXT  (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
    "2vMFoVMhg8PkKjVehMbGnYkjwVOSKfHal7mBXyXkLwEHa9FL3Rt3F9yqqHi0YP8k"
    "pJGsR1jtf6XNhR7WHwADAQAB" )

DKIM keys are typically long enough to require the 255-byte string splitting described earlier. The selector portion (e.g., google, selector1, s1) is chosen by the mail provider and lets you rotate keys or run multiple providers simultaneously.

4. DMARC Policies

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy that tells receivers what to do when authentication fails. It is published as a TXT record at _dmarc.yourdomain.com:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Start with p=none to collect data, then tighten to quarantine and finally reject once you are confident all legitimate mail passes.

5. DANE / TLSA Pointers

DANE (DNS-Based Authentication of Named Entities) uses TLSA records to bind TLS certificates to DNS names. While TLSA is its own record type, DANE deployments often coexist with TXT-based MTA-STS records for mail transport security:

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

MTA-STS tells sending servers to require TLS when delivering mail to your domain, preventing downgrade attacks.

6. CAA-Adjacent Security

CAA records control which Certificate Authorities may issue certificates for your domain. While CAA has its own record type, related protocols like BIMI (Brand Indicators for Message Identification) are published via TXT:

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

7. Let's Encrypt DNS-01 Challenges

When you request a TLS certificate from Let's Encrypt (or any ACME-compatible CA) using the DNS-01 challenge method, the CA asks you to place a specific token at _acme-challenge.yourdomain.com:

_acme-challenge.example.com.  300  IN  TXT  "gfj9Xq5B7hbRvNzLpCd_kW3mZ..."

The short TTL (300 seconds) is deliberate — the token is temporary, and you want it to propagate quickly and expire quickly. DNS-01 is the only ACME challenge type that works for wildcard certificates, making TXT records essential for automated certificate issuance on *.yourdomain.com.

Tip: If you automate Let's Encrypt renewals with DNS-01, use the DNScale API to create and delete the _acme-challenge TXT record programmatically. This avoids manual intervention every 60–90 days.

Querying TXT Records with dig

The dig command is the standard tool for inspecting DNS records from the command line.

Query All TXT Records for a Domain

dig TXT example.com

This returns every TXT record on example.com, including SPF, verification tokens, and anything else.

Short Output

dig TXT example.com +short

Strips the response down to just the record values — useful for scripting:

"v=spf1 include:_spf.google.com ~all"
"google-site-verification=dFt3o9GnM7P4Qm1kL5WrV..."

Query a Specific Subdomain

# DMARC policy
dig TXT _dmarc.example.com +short
 
# DKIM key (replace 'google' with your selector)
dig TXT google._domainkey.example.com +short
 
# Let's Encrypt challenge
dig TXT _acme-challenge.example.com +short

Query a Specific Nameserver

To check what the authoritative server is returning (bypassing resolver caches):

dig TXT example.com @ns1.dnscale.eu +short

Check from Multiple Resolvers

To verify DNS propagation across different networks:

for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo "$ns: $(dig TXT example.com @$ns +short)"
done

Google Site Verification — Step by Step

One of the most common reasons people create a TXT record is to verify domain ownership with Google. Here is the full workflow:

1. Open Google Search Console and add your domain property
2. Google displays a verification token, e.g., google-site-verification=dFt3o9GnM7P4Qm1kL5WrV...
3. In DNScale, navigate to your zone and click Add Record
4. Set Name to @ (apex), Type to TXT, and paste the full token as the Value
5. Set TTL to 3600 (or use the default)
6. Click Create Record
7. Wait a few minutes for propagation, then click Verify in Google Search Console

Confirm the record is live:

dig TXT example.com +short | grep google-site-verification

Common Mistakes

1. Multiple SPF Records

Publishing two records that both start with v=spf1 causes an SPF PermError. Combine all mechanisms into a single record:

# Wrong — two SPF records
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"
 
# Correct — one combined SPF record
example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

2. Forgetting the Quotes

In zone-file syntax, TXT record values must be enclosed in double quotes. Some DNS interfaces add them automatically, but if you are editing a zone file by hand, omitting quotes will cause a parse error.

3. Exceeding the SPF 10-Lookup Limit

SPF evaluations are capped at 10 DNS lookups (each include, a, mx, and redirect counts). Exceeding this limit produces a PermError. Use ip4/ip6 mechanisms for static IPs to stay under the limit, or use an SPF-flattening service.

4. Not Splitting Long Values

If you paste a DKIM key longer than 255 characters as a single string into a raw zone file, the record will be malformed. Most dashboard interfaces handle splitting automatically, but API and zone-file users need to be aware of the limit.

5. Deleting Verification Records Too Early

Some services (Google Workspace, Microsoft 365) periodically re-verify domain ownership. Deleting the verification TXT record can revoke your access.

6. Wrong Subdomain for DKIM or DMARC

DKIM records must be at selector._domainkey.yourdomain.com — not at the apex. DMARC records must be at _dmarc.yourdomain.com. Placing them at the wrong name means they will never be found by receivers.

TXT Records and Email Deliverability

TXT records are the backbone of modern email authentication. Without them, your emails are far more likely to land in spam or be rejected entirely. Here is the minimum set of TXT records every domain that sends email should have:

For a complete walkthrough, see the Email Security with SPF, DKIM, and DMARC guide.

If your domain does not send email, you should still publish records that explicitly declare this:

example.com.      3600  IN  TXT  "v=spf1 -all"
_dmarc.example.com. 3600  IN  TXT  "v=DMARC1; p=reject"

This prevents attackers from spoofing your domain for phishing.

TXT Records and MX Records

MX records define where incoming mail is delivered. TXT records (SPF, DKIM, DMARC) define who is allowed to send mail and what happens when authentication fails. Together, they form a complete email configuration. When setting up mail, always configure both:

1. MX records for inbound delivery
2. SPF TXT record listing authorized outbound senders
3. DKIM TXT records with public keys from your mail provider
4. DMARC TXT record with your enforcement policy

Related Record Types

• A and AAAA — map domain names to IP addresses
• MX — directs incoming email to mail servers
• CAA — controls which CAs can issue TLS certificates
• TLSA — DANE certificate association for TLS
• CNAME — canonical name aliases
• SRV — service discovery with port and priority
• NS — delegates DNS authority to nameservers

For a complete overview of all record types, see the DNS Record Types guide.

Conclusion

TXT records are the Swiss Army knife of DNS. They power email authentication (SPF, DKIM, DMARC), domain verification for cloud services, automated certificate issuance via Let's Encrypt DNS-01, and security policies like MTA-STS and BIMI. Understanding the 255-byte string limit, the one-SPF-record rule, and proper subdomain naming for DKIM and DMARC will save you from the most common configuration errors. Use dig TXT to inspect your records, and keep verification tokens in place even after initial setup.