While DNS was originally designed for name-to-address resolution, its globally distributed, highly available, and cacheable infrastructure proved too valuable to limit to just IP addresses. Over the decades, DNS has evolved into a general-purpose data distribution system, serving verification tokens, security policies, service discovery, and arbitrary metadata.

The TXT record (Text record) is the most flexible of these extended record types—a simple container for human-readable text that has been repurposed for machine-readable data including SPF, DKIM, DMARC, domain verification, and more. Beyond TXT records, DNS hosts specialized record types for service location (SRV), certificate authority authorization (CAA), reverse lookups (PTR), and zone metadata (SOA).

This page provides exhaustive coverage of TXT records and other important DNS record types, exploring their structure, common use cases, security implications, and operational best practices.

The TXT record (Text record) is defined in RFC 1035 as a container for arbitrary text data. Originally intended for human-readable notes about a domain, TXT records have evolved into critical infrastructure for authentication and verification.

Formal Definition

A TXT record associates:

• Owner Name: The domain name
• Text Data: One or more character strings

The abstract representation:

<domain>  IN  TXT  "<text-string>"

For example:

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

TXT Record Wire Format

Character-string format: Each string in RDATA is length-prefixed:

• 1 byte: length (0-255)
• N bytes: character data

A TXT record can contain multiple character-strings, concatenated upon retrieval.

The 255-Byte Character String Limit

Each individual character-string in a TXT record is limited to 255 bytes (due to the 1-byte length prefix). This creates complications for longer values like DKIM keys.

Solution: Use multiple strings that are concatenated:

example.com.  300  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..." "...additional characters..."

Resolvers and applications concatenate these strings into a single value.

The most critical use of TXT records in modern infrastructure is email authentication. Three technologies—SPF, DKIM, and DMARC—use DNS TXT records to combat email spoofing and phishing.

SPF (Sender Policy Framework)

SPF (RFC 7208) allows domain owners to declare which mail servers are authorized to send email for their domain.

Location: TXT record at domain apex

Format:

example.com.  300  IN  TXT  "v=spf1 <mechanisms> <qualifier>"

Example with explanation:

example.com.  300  IN  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com mx -all"

Qualifiers:

• + (pass, default)
• - (hard fail)
• ~ (soft fail)
• ? (neutral)

How SPF Validation Works

1. Receiving mail server extracts sender domain from SMTP MAIL FROM
2. Looks up SPF TXT record for that domain
3. Evaluates sender IP against SPF mechanisms
4. Result: pass, fail, softfail, neutral, none, permerror, temperror

DKIM (DomainKeys Identified Mail)

DKIM (RFC 6376) adds a cryptographic signature to emails, proving they came from an authorized sender.

Location: TXT record at <selector>._domainkey.<domain>

Format:

selector1._domainkey.example.com.  300  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIj..."

How DKIM Works:

1. Sending server signs email headers/body with private key
2. Adds DKIM-Signature header with selector reference
3. Receiving server looks up public key via DNS TXT record
4. Verifies signature using public key
5. Result: pass or fail

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

DMARC (RFC 7489) builds on SPF and DKIM, specifying what to do when they fail and enabling reporting.

Location: TXT record at _dmarc.<domain>

Format:

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

TXT records serve as a universal mechanism for domain ownership verification. When you sign up for a service that needs to confirm you control a domain, TXT records are typically the verification method.

How Domain Verification Works

1. Service provides token: You receive a unique verification string
2. You create TXT record: Add the token to your DNS
3. Service queries DNS: Looks for the token at your domain
4. Verification confirmed: Token found = you control the domain

Common Verification Patterns

Pattern 1: Root Domain TXT

example.com.  300  IN  TXT  "google-site-verification=abc123..."
example.com.  300  IN  TXT  "ms=ms12345678"
example.com.  300  IN  TXT  "facebook-domain-verification=xyz789"

Pattern 2: Subdomain TXT

_acme-challenge.example.com.  300  IN  TXT  "gfj9Xq..." ; Let's Encrypt
_github-challenge-org.example.com.  300  IN  TXT  "abc123"
_dnslink.example.com.  300  IN  TXT  "/ipfs/QmX..."

Pattern 3: Labeled TXT (Namespaced)

_atproto.example.com.  300  IN  TXT  "did:plc:..."  ; Bluesky
_mta-sts.example.com.  300  IN  TXT  "v=STSv1; id=..."

Security Considerations for Verification Records

1. Remove Unneeded Verification Records Old verification TXT records for services you no longer use should be removed. They clutter your zone and could theoretically be exploited if the verification mechanism has weaknesses.

2. Understand What You're Verifying Verification proves domain control to the service. Ensure you trust the service before adding their verification token.

3. Use Short TTL for Temporary Verifications

; Use short TTL for verification, then remove
_acme-challenge.example.com.  60  IN  TXT  "challenge-token"

After verification succeeds, remove the record.

DNS-01 Challenge for TLS Certificates

Let's Encrypt and other CAs use the DNS-01 challenge for domain validation:

1. CA generates random token
2. You create: _acme-challenge.domain.com TXT "<token>"
3. CA queries DNS for the TXT record
4. If found, CA issues certificate

Advantages of DNS-01:

• Works for wildcard certificates
• Works for domains without web servers
• Works for internal/non-public domains

Automation: Use tools like certbot with DNS plugins or acme.sh to automate DNS-01 challenges.

SRV records (Service records, RFC 2782) enable DNS-based service discovery. They answer the question: "Where is the server for a particular service on this domain?"

Formal Definition

SRV records associate:

• Service: The service name (e.g., _http, _ldap)
• Protocol: Transport protocol (e.g., _tcp, _udp)
• Domain: The domain providing the service
• Priority: Lower = preferred (like MX)
• Weight: Load balancing within same priority
• Port: The port number
• Target: The server hostname

SRV Record Format

_<service>._<protocol>.<domain>  TTL  IN  SRV  <priority> <weight> <port> <target>

Example: XMPP (Jabber) SRV records

_xmpp-client._tcp.example.com.  300  IN  SRV  10 5 5222 chat.example.com.
_xmpp-server._tcp.example.com.  300  IN  SRV  10 5 5269 chat.example.com.

This tells XMPP clients: "To connect to example.com, contact chat.example.com on port 5222."

Example: Microsoft Active Directory

_ldap._tcp.dc._msdcs.corp.example.com.  300  IN  SRV  0 100 389 dc1.corp.example.com.
_kerberos._tcp.corp.example.com.  300  IN  SRV  0 100 88 dc1.corp.example.com.

SRV Fields Explained

Weight: Load Balancing

When multiple SRV records have the same priority, weight determines load distribution:

_http._tcp.example.com.  300  IN  SRV  10 60 80 server1.example.com.
_http._tcp.example.com.  300  IN  SRV  10 40 80 server2.example.com.

Clients should direct 60% of requests to server1, 40% to server2.

Common SRV Use Cases

HTTP and SRV: The Missing Link

Notably, HTTP/HTTPS don't traditionally use SRV records. Instead, browsers assume:

• HTTP: port 80
• HTTPS: port 443

RFC 6186 defines SRV for HTTP, but browser adoption is minimal. Modern alternatives include Alt-Svc headers and HTTPS DNS records (covered later).

CAA records (Certification Authority Authorization, RFC 8659) allow domain owners to specify which Certificate Authorities (CAs) are permitted to issue TLS certificates for their domain.

Why CAA Matters

Before CAA, any CA could issue a certificate for any domain (if they could validate domain control). This meant:

• Compromised CAs could issue fraudulent certificates
• Rogue CAs could issue certificates without authorization
• No way for domain owners to restrict issuance

CAA empowers domain owners to restrict which CAs can issue certificates, reducing the attack surface.

CAA Record Format

<domain>  TTL  IN  CAA  <flags> <tag> <value>

Tags:

• issue: CAs permitted to issue regular certificates
• issuewild: CAs permitted to issue wildcard certificates
• iodef: URL for incident reporting

Examples:

; Only Let's Encrypt can issue for this domain
example.com.  300  IN  CAA  0 issue "letsencrypt.org"

; Let's Encrypt for regular, DigiCert for wildcard
example.com.  300  IN  CAA  0 issue "letsencrypt.org"
example.com.  300  IN  CAA  0 issuewild "digicert.com"

; No wildcards allowed
example.com.  300  IN  CAA  0 issuewild ";"

; Report violations via email
example.com.  300  IN  CAA  0 iodef "mailto:security@example.com"

How CAs Use CAA

1. Before issuing a certificate, CA queries CAA records
2. CA climbs the domain hierarchy if no CAA at exact name:
   • Query www.example.com → no CAA
   • Query example.com → CAA found → evaluate
3. If CAA exists and CA is not listed → refuse issuance
4. If no CAA exists → proceed (no restriction)
5. Since September 2017, CAA compliance is mandatory for all CAs

CAA Flags

The flags field (0 or 128) controls behavior:

• Flag 0: Standard processing
• Flag 128: Critical (issuer-critical tag) — CA must understand the tag or refuse issuance

; Unknown critical tag - CA must refuse if it doesn't understand
example.com.  300  IN  CAA  128 customtag "value"

CAA Hierarchy and Inheritance

CAA records are inherited by subdomains unless overridden:

; Only DigiCert for all of example.com
example.com.  300  IN  CAA  0 issue "digicert.com"

; api.example.com allows Let's Encrypt (overrides parent)
api.example.com.  300  IN  CAA  0 issue "letsencrypt.org"

The www.example.com subdomain inherits the DigiCert restriction from parent.

PTR records (Pointer records) enable reverse DNS lookups—mapping IP addresses back to hostnames. While A/AAAA records answer "What is the IP for this name?", PTR records answer "What is the name for this IP?"

The in-addr.arpa and ip6.arpa Domains

Reverse DNS uses special domain hierarchies:

IPv4: in-addr.arpa

IP: 192.0.2.1
Reverse domain: 1.2.0.192.in-addr.arpa.

Note: The octets are reversed.

IPv6: ip6.arpa

IP: 2001:db8::1
Full: 2001:0db8:0000:0000:0000:0000:0000:0001
Reverse: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Each hex digit becomes a label, reversed.

PTR Record Format

1.2.0.192.in-addr.arpa.  3600  IN  PTR  mail.example.com.

This declares: "The IP 192.0.2.1 has hostname mail.example.com."

Who Manages PTR Records?

PTR records are managed by whoever controls the IP address space, typically:

• ISPs for customer IP ranges
• Hosting providers for VPS/dedicated servers
• Cloud providers for cloud IPs (usually via console/API)
• Enterprises for delegated IP blocks

You typically request PTR record creation from your IP provider, rather than managing them yourself.

Why Reverse DNS Matters

1. Email Deliverability

Many mail servers verify that the sending IP has a valid PTR record that matches the SMTP HELO/EHLO hostname. Missing or mismatched PTR often causes email rejection:

; Forward lookup
mail.example.com.  A  192.0.2.1

; Reverse lookup (should match)
1.2.0.192.in-addr.arpa.  PTR  mail.example.com.

2. Logging and Diagnostics

Network administrators prefer hostnames in logs:

192.0.2.50 → webserver.example.com (more readable)

3. Access Control

Some services restrict access based on reverse DNS patterns:

# Apache configuration
Require host .example.com

4. Anti-Spam Heuristics

Lack of PTR record is a spam indicator. Generic PTR (like 192-0-2-1.generic.isp.com) is less trusted than dedicated PTR.

FCrDNS: Forward-Confirmed Reverse DNS

FCrDNS (Forward-Confirmed reverse DNS) requires:

1. PTR lookup returns hostname
2. A/AAAA lookup of that hostname returns original IP

Both directions must match for the strongest verification:

192.0.2.1 → PTR → mail.example.com
mail.example.com → A → 192.0.2.1 ✓

If the forward lookup returns a different IP, FCrDNS fails.

The SOA record (Start of Authority) contains essential metadata about a DNS zone. Every zone must have exactly one SOA record at its apex.

SOA Record Format

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                           2024011701  ; Serial
                           7200        ; Refresh
                           3600        ; Retry
                           1209600     ; Expire
                           3600        ; Minimum TTL (negative caching)
                           )

SOA Field Meanings

Serial Number Conventions

Date-based (recommended):

YYYYMMDDnn
2024011701 → January 17, 2024, revision 01

Sequential:

1, 2, 3, 4...

Critical Rule: Serial must always increment when zone changes. If serial goes backward, secondaries may not update.

Negative Caching (Minimum TTL)

The SOA minimum field determines how long NXDOMAIN (non-existent domain) responses are cached:

Query: nonexistent.example.com
Response: NXDOMAIN, SOA in authority section
Negative cache TTL: min(query TTL, SOA minimum)

This prevents repeated queries for non-existent names.

Zone Transfers and SOA

AXFR (full zone transfer) and IXFR (incremental zone transfer) use SOA:

1. Secondary queries SOA of primary
2. Compares serial numbers
3. If primary serial > secondary serial → transfer needed
4. IXFR transfers only changed records; AXFR transfers entire zone

SOA Best Practices

1. Use Realistic Timers

• Refresh: 1-24 hours depending on change frequency
• Retry: 15 minutes to 2 hours
• Expire: 1-2 weeks (long enough for outages, short enough for security)

2. Always Update Serial Forgetting to increment serial is a common cause of secondary servers serving stale data.

3. Use Meaningful Email Address The email in SOA should be monitored. DNS issues are often reported there.

4. Consider Dynamic DNS For zones updated programmatically (e.g., via API), serial is often Unix timestamp:

Serial: 1705487700  ; Unix timestamp

DNS continues evolving with new record types addressing modern infrastructure needs.

HTTPS and SVCB Records (RFC 9460)

HTTPS records provide rich service binding for HTTPS connections:

example.com.  300  IN  HTTPS  1 . alpn="h2,h3" ipv4hint="192.0.2.1" ipv6hint="2001:db8::1"

Benefits:

• No A/AAAA query needed (address hints included)
• Indicates HTTP/2, HTTP/3 support
• Can specify alternative ports
• Enables ECH (Encrypted Client Hello) distribution

SVCB (Service Binding) is the general form; HTTPS is the HTTPS-specific alias.

TLSA Records (DANE)

TLSA records bind TLS certificates to domain names via DNS:

_443._tcp.www.example.com.  300  IN  TLSA  3 1 1 abc123...

With DNSSEC, this provides CA-independent certificate validation.

DNSKEY and DS Records (DNSSEC)

DNSKEY: Public keys for zone signing

example.com.  3600  IN  DNSKEY  257 3 13 (base64-public-key)

DS: Delegation signer linking child zone's key to parent

example.com.  3600  IN  DS  12345 13 2 (hash-of-child-DNSKEY)

We've conducted a comprehensive exploration of TXT records and specialized DNS record types that extend DNS beyond simple address resolution. Let's consolidate the essential knowledge: