DNS Record Types Explained: A, CNAME, MX, TXT & More (2025)

Quick Answer

Table of Contents

Introduction to DNS Records

DNS records are the fundamental building blocks of the Domain Name System. They act as a database that maps human-readable domain names to machine-readable IP addresses and other information needed for internet communication.

What Are DNS Records?

DNS records are entries in a DNS zone file that provide information about a domain. Each record consists of:

• Name: The domain or subdomain the record applies to
• Type: The kind of record (A, CNAME, MX, etc.)
• Value: The data associated with the record
• TTL: Time To Live, how long the record should be cached
• Priority: For certain record types like MX and SRV

How DNS Records Work

When you type a domain name into your browser, here's what happens:

1. Your computer queries a DNS resolver
2. The resolver checks its cache for the domain's records
3. If not cached, it queries authoritative nameservers
4. The nameserver returns the appropriate DNS records
5. Your browser uses the record data to connect to the correct server

Understanding different DNS record types is essential for:

• Website hosting: Pointing domains to web servers
• Email configuration: Routing email to mail servers
• Domain verification: Proving domain ownership
• Service discovery: Locating specific services
• Security: Implementing SPF, DKIM, and DMARC

A Record (Address Record)

The A record is the most fundamental DNS record type, mapping a domain name to an IPv4 address.

What Is an A Record?

An A record (Address Record) creates a direct connection between a domain name and an IPv4 address. When someone visits your website, the A record tells their browser which server to connect to.

A Record Format

example.com.    3600    IN    A    192.0.2.1

Breaking down this record:

• example.com.: The domain name (trailing dot indicates root)
• 3600: TTL in seconds (1 hour)
• IN: Internet class (standard for all DNS records)
• A: Record type
• 192.0.2.1: IPv4 address

Common Uses for A Records

1. Root Domain Mapping

   example.com.    A    192.0.2.1
   

   Points your main domain to your web server.

2. Subdomain Mapping

   www.example.com.     A    192.0.2.1
   blog.example.com.    A    192.0.2.2
   shop.example.com.    A    192.0.2.3
   

   Each subdomain can point to a different server.

3. Multiple A Records (Round-Robin DNS)

   example.com.    A    192.0.2.1
   example.com.    A    192.0.2.2
   example.com.    A    192.0.2.3
   

   Distributes traffic across multiple servers for load balancing.

A Record Best Practices

• Use for root domains: A records are the only way to point root domains directly to an IP
• Set appropriate TTL: Use shorter TTL (300-600 seconds) when planning changes
• Monitor IP changes: Update A records immediately if your server IP changes
• Don't use for CDNs: Use CNAME records for CDN services instead
• Keep records updated: Outdated A records cause website downtime

A Record Limitations

• Only works with IPv4 addresses (use AAAA for IPv6)
• Cannot point to another domain name (use CNAME)
• Changes may take time to propagate based on TTL
• No automatic failover if the server goes down

AAAA Record (IPv6 Address Record)

The AAAA record is the IPv6 equivalent of the A record, mapping domain names to IPv6 addresses.

What Is an AAAA Record?

An AAAA record (quad-A record) maps a domain name to a 128-bit IPv6 address. As the internet transitions from IPv4 to IPv6 due to IPv4 address exhaustion, AAAA records are becoming increasingly important.

AAAA Record Format

example.com.    3600    IN    AAAA    2001:0db8:85a3:0000:0000:8a2e:0370:7334

IPv6 addresses are written in hexadecimal and separated by colons.

Compressed IPv6 Format

IPv6 addresses can be compressed:

Full format:

2001:0db8:0000:0000:0000:0000:0000:0001

Compressed format:

2001:0db8::1

Leading zeros in each section can be omitted, and consecutive sections of zeros can be replaced with :: (only once per address).

Common Uses for AAAA Records

1. Dual Stack Configuration

   example.com.    A       192.0.2.1
   example.com.    AAAA    2001:0db8::1
   

   Provides both IPv4 and IPv6 connectivity.

2. IPv6-Only Services

   api.example.com.    AAAA    2001:0db8::2
   

   For services that only support IPv6.

3. Subdomain IPv6 Mapping

   www.example.com.     AAAA    2001:0db8::1
   mail.example.com.    AAAA    2001:0db8::2
   

AAAA Record Best Practices

• Always include A records: Maintain IPv4 compatibility with dual-stack
• Test IPv6 connectivity: Verify your server is properly configured for IPv6
• Match TTL values: Keep A and AAAA TTL values consistent
• Monitor adoption: Track IPv6 traffic to understand user adoption
• Security considerations: Ensure firewalls protect both IPv4 and IPv6

Why AAAA Records Matter

• Address space: IPv6 provides 340 undecillion addresses vs. IPv4's 4.3 billion
• Future-proofing: Major providers (Google, Facebook, Netflix) prioritize IPv6
• Performance: Some networks route IPv6 traffic more efficiently
• SEO benefits: Google has confirmed IPv6 support is a positive signal
• Mobile networks: Most mobile carriers now prefer IPv6

CNAME Record (Canonical Name Record)

CNAME records create aliases that point one domain name to another, enabling flexible domain management.

What Is a CNAME Record?

A CNAME (Canonical Name) record creates an alias from one domain name to another. When a DNS resolver encounters a CNAME record, it performs a second lookup for the target domain name.

CNAME Record Format

www.example.com.    3600    IN    CNAME    example.com.

This tells DNS resolvers that www.example.com is an alias for example.com.

Common Uses for CNAME Records

1. WWW Subdomain

   www.example.com.    CNAME    example.com.
   

   Points www version to your root domain.

2. CDN Configuration

   cdn.example.com.    CNAME    d111111abcdef8.cloudfront.net.
   

   Points to a CDN distribution.

3. Service Integration

   blog.example.com.     CNAME    myblog.wordpress.com.
   shop.example.com.     CNAME    mystore.shopify.com.
   mail.example.com.     CNAME    ghs.google.com.
   

4. Multiple Aliases

   ftp.example.com.     CNAME    files.example.com.
   files.example.com.   A         192.0.2.1
   

CNAME Record Rules and Restrictions

Critical Limitations:

1. No CNAME at Root Domain

   ❌ example.com.    CNAME    target.example.com.
   ✅ www.example.com. CNAME    target.example.com.
   

   Root domains cannot have CNAME records (RFC 1912 violation).

2. No Other Records with CNAME

   ❌ subdomain.example.com.    CNAME    target.example.com.
      subdomain.example.com.    TXT      "verification"
   
   ✅ subdomain.example.com.    CNAME    target.example.com.
   

   A domain with a CNAME cannot have any other record types.

3. CNAME Cannot Point to CNAME

   ❌ a.example.com.    CNAME    b.example.com.
      b.example.com.    CNAME    c.example.com.
   
   ✅ a.example.com.    CNAME    c.example.com.
      b.example.com.    CNAME    c.example.com.
   

   Avoid CNAME chains (causes extra DNS lookups).

CNAME vs A Record

When to Use CNAME Records

Use CNAME when:

• Pointing to third-party services (CDN, hosting, SaaS)
• You want automatic IP updates from the target
• Creating multiple aliases for the same destination
• Implementing service-specific subdomains

Use A record instead when:

• Configuring the root domain
• Performance is critical (avoid extra DNS lookups)
• You control the IP address directly
• Other records exist on the same subdomain

CNAME Best Practices

• Never use CNAME at root domain: Use A/AAAA records or ALIAS records
• Avoid CNAME chains: Point directly to the final destination
• Monitor target changes: Ensure the CNAME target remains valid
• Use for third-party services: Let providers manage IP changes
• Set appropriate TTL: Use longer TTL (3600+) for stable CNAMEs

MX Record (Mail Exchange Record)

MX records specify which mail servers handle email for your domain, enabling email delivery.

What Is an MX Record?

An MX (Mail Exchange) record directs email to the mail servers responsible for accepting email messages on behalf of a domain. MX records include a priority value to define the order in which mail servers should be used.

MX Record Format

example.com.    3600    IN    MX    10    mail.example.com.
example.com.    3600    IN    MX    20    backup.example.com.

Breaking down this record:

• example.com.: The domain receiving email
• 3600: TTL in seconds
• MX: Record type
• 10, 20: Priority (lower number = higher priority)
• mail.example.com.: Mail server hostname

How MX Records Work

When someone sends email to [email protected]:

1. Sender's mail server queries DNS for example.com MX records
2. DNS returns all MX records sorted by priority
3. Sender's server attempts delivery to the lowest priority number first
4. If that server is unavailable, it tries the next priority
5. Email is delivered or queued for retry

Common MX Record Configurations

1. Single Mail Server

   example.com.    MX    10    mail.example.com.
   mail.example.com.    A     192.0.2.1
   

2. Redundant Mail Servers

   example.com.    MX    10    mail1.example.com.
   example.com.    MX    10    mail2.example.com.
   

   Same priority = load balancing between servers.

3. Primary and Backup Mail Servers

   example.com.    MX    10    primary.example.com.
   example.com.    MX    20    backup.example.com.
   example.com.    MX    30    fallback.example.com.
   

4. Google Workspace (Gmail)

   example.com.    MX    1     aspmx.l.google.com.
   example.com.    MX    5     alt1.aspmx.l.google.com.
   example.com.    MX    5     alt2.aspmx.l.google.com.
   example.com.    MX    10    alt3.aspmx.l.google.com.
   example.com.    MX    10    alt4.aspmx.l.google.com.
   

5. Microsoft 365

   example.com.    MX    0     example-com.mail.protection.outlook.com.
   

MX Record Priority Explained

The priority value determines the order in which mail servers are contacted:

• Lower numbers = higher priority (10 is tried before 20)
• Same priority = load balancing (random selection)
• Gap in numbers doesn't matter (10, 20, 30 works the same as 10, 11, 12)

Priority Strategy Examples:

# High availability with failover
MX    10    primary.example.com.       (main server)
MX    20    secondary.example.com.     (backup)
MX    30    tertiary.example.com.      (last resort)

# Load balancing with failover
MX    10    mail1.example.com.         (50% traffic)
MX    10    mail2.example.com.         (50% traffic)
MX    20    backup.example.com.        (failover only)

MX Record Best Practices

• Always have backup MX: Configure at least 2 MX records for redundancy
• Use proper priority gaps: Space priorities (10, 20, 30) for future additions
• Point to hostnames, not IPs: MX records must point to A/AAAA records
• Avoid CNAME targets: MX should point to A records, not CNAMEs
• Test email delivery: Use tools like MXToolbox to verify configuration
• Match PTR records: Ensure reverse DNS matches your mail server
• Set reasonable TTL: Use 3600 (1 hour) or higher for stability

Common MX Record Mistakes

1. MX Pointing to CNAME

   ❌ example.com.    MX    10    mail.example.com.
      mail.example.com. CNAME    server.hosting.com.
   
   ✅ example.com.    MX    10    mail.example.com.
      mail.example.com. A         192.0.2.1
   

2. Missing Backup MX

   ❌ example.com.    MX    10    mail.example.com.
   
   ✅ example.com.    MX    10    mail.example.com.
      example.com.    MX    20    backup.example.com.
   

3. MX Pointing to IP Address

   ❌ example.com.    MX    10    192.0.2.1
   
   ✅ example.com.    MX    10    mail.example.com.
      mail.example.com. A         192.0.2.1
   

TXT Record (Text Record)

TXT records store text information in DNS, commonly used for domain verification and email security.

What Is a TXT Record?

A TXT (Text) record allows domain administrators to insert arbitrary text into DNS records. While originally designed for human-readable notes, TXT records now serve critical functions in email authentication, domain verification, and security policies.

TXT Record Format

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

TXT records contain quoted strings of text data.

Common Uses for TXT Records

1. SPF (Sender Policy Framework)

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

   Specifies which mail servers can send email for your domain.

2. DKIM (DomainKeys Identified Mail)

   default._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
   

   Provides a public key for email signature verification.

3. DMARC (Domain-based Message Authentication)

   _dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"
   

   Defines email authentication policies and reporting.

4. Domain Verification

   example.com.    TXT    "google-site-verification=abc123xyz"
   example.com.    TXT    "facebook-domain-verification=abc123xyz"
   

   Proves domain ownership to third-party services.

5. Site Verification

   example.com.    TXT    "v=msv1 MS=ms12345678"
   

   Microsoft domain verification.

SPF Records in Detail

SPF (Sender Policy Framework) prevents email spoofing by defining authorized mail servers.

SPF Record Structure:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

SPF Mechanisms:

• v=spf1: SPF version (always v=spf1)
• ip4: Authorize IPv4 address or range
• ip6: Authorize IPv6 address or range
• include: Include another domain's SPF policy
• a: Authorize domain's A record IPs
• mx: Authorize domain's MX record IPs
• all: Default rule for unlisted senders

SPF Qualifiers:

• + (Pass): Authorized sender - +ip4:192.0.2.1
• - (Fail): Not authorized, reject - -all
• ~ (Soft Fail): Not authorized, accept but mark - ~all
• ? (Neutral): No policy - ?all

SPF Examples:

# Allow only specified IP addresses
TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 -all"

# Allow domain's mail servers and Google Workspace
TXT "v=spf1 mx include:_spf.google.com -all"

# Allow multiple email providers
TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

# Soft fail for everything else
TXT "v=spf1 mx ~all"

DKIM Records in Detail

DKIM (DomainKeys Identified Mail) adds a digital signature to email headers.

DKIM Record Format:

selector._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

DKIM Components:

• v=DKIM1: DKIM version
• k=rsa: Key type (RSA)
• p=: Public key (base64 encoded)
• t=s: Test mode (optional)
• t=y: Domain testing DKIM (optional)

Common DKIM Selectors:

• default._domainkey.example.com
• google._domainkey.example.com
• k1._domainkey.example.com

DMARC Records in Detail

DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM.

DMARC Record Format:

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100"

DMARC Tags:

• v=DMARC1: Version (required)
• p=: Policy (none, quarantine, reject)
• sp=: Subdomain policy
• rua=: Aggregate report email
• ruf=: Forensic report email
• pct=: Percentage of messages to filter
• adkim=: DKIM alignment mode (r=relaxed, s=strict)
• aspf=: SPF alignment mode (r=relaxed, s=strict)

DMARC Policy Options:

• p=none: Monitor only, no action taken
• p=quarantine: Send suspicious email to spam
• p=reject: Reject unauthorized email

DMARC Implementation Stages:

# Stage 1: Monitoring (collect data)
_dmarc.example.com.    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]"

# Stage 2: Quarantine (mark spam)
_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]"

# Stage 3: Enforcement (reject)
_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"

TXT Record Best Practices

• Keep records under 255 characters: Split long records into multiple strings
• Use specific selectors for DKIM: Allows key rotation without downtime
• Implement DMARC gradually: Start with p=none, monitor reports, then enforce
• Monitor SPF lookups: Limit to 10 DNS lookups to avoid SPF failures
• Test before enforcing: Use email testing tools to verify configuration
• Document your records: Maintain comments explaining each TXT record's purpose

TXT Record Limits

• Single string limit: 255 characters
• Total record limit: Multiple strings can be concatenated
• SPF lookup limit: Maximum 10 DNS lookups per SPF check
• Multiple TXT records: Multiple TXT records per domain are allowed

NS Record (Name Server Record)

NS records delegate a domain or subdomain to specific nameservers, controlling DNS authority.

What Is an NS Record?

An NS (Name Server) record specifies which DNS servers are authoritative for a domain. These records determine which servers answer DNS queries for your domain.

NS Record Format

example.com.    86400    IN    NS    ns1.nameserver.com.
example.com.    86400    IN    NS    ns2.nameserver.com.

Where NS Records Exist

NS records exist in two places:

1. At the registry level (TLD nameservers)

   • Registered with your domain registrar
   • Points to your authoritative nameservers
   • Cannot be queried via standard DNS lookup tools

2. In your zone file (authoritative nameservers)

   • Stored on your DNS hosting provider
   • Must match registry records
   • Can delegate subdomains

Common Uses for NS Records

1. Domain Nameserver Configuration

   example.com.    NS    ns1.cloudprovider.com.
   example.com.    NS    ns2.cloudprovider.com.
   

2. Subdomain Delegation

   subdomain.example.com.    NS    ns1.subdomainhost.com.
   subdomain.example.com.    NS    ns2.subdomainhost.com.
   

   Allows different nameservers to manage subdomain DNS.

3. Multi-Provider Setup

   example.com.    NS    ns1.provider1.com.
   example.com.    NS    ns2.provider1.com.
   example.com.    NS    ns1.provider2.com.
   example.com.    NS    ns2.provider2.com.
   

NS Record Best Practices

• Use multiple nameservers: Minimum 2, recommended 3-4 for redundancy
• Different networks: Choose nameservers on different networks/locations
• Higher TTL: Use 86400 (24 hours) or longer for stability
• Match registry and zone: Ensure NS records match at registrar and DNS host
• Avoid single points of failure: Don't use nameservers from only one provider
• Monitor nameserver health: Ensure all NS records resolve properly

Checking NS Records

# Check authoritative nameservers
dig example.com NS

# Check from specific nameserver
dig @8.8.8.8 example.com NS

# Check SOA to find primary nameserver
dig example.com SOA

SOA Record (Start of Authority Record)

The SOA record provides essential information about a DNS zone, including the primary nameserver and zone refresh parameters.

What Is an SOA Record?

An SOA (Start of Authority) record defines authoritative information about a DNS zone, including the primary nameserver, administrator email, and timing parameters for zone transfers and caching.

SOA Record Format

example.com.    86400    IN    SOA    ns1.example.com. admin.example.com. (
                                      2025120101  ; Serial
                                      7200        ; Refresh
                                      3600        ; Retry
                                      1209600     ; Expire
                                      86400 )     ; Minimum TTL

SOA Record Components

1. Primary Nameserver (ns1.example.com.)

   • The primary DNS server for the zone
   • Source of authoritative data

2. Administrator Email (admin.example.com.)

   • Email address with @ replaced by .
   • admin.example.com. = [email protected]

3. Serial Number (2025120101)

   • Version number for the zone file
   • Format: YYYYMMDDnn (year, month, day, revision)
   • Incremented after every zone change
   • Secondary nameservers check this to know when to update

4. Refresh (7200 seconds = 2 hours)

   • How often secondary nameservers check for zone updates
   • Typical: 3600-7200 (1-2 hours)

5. Retry (3600 seconds = 1 hour)

   • How long to wait before retrying a failed refresh
   • Should be less than refresh interval
   • Typical: 600-3600 (10 minutes - 1 hour)

6. Expire (1209600 seconds = 14 days)

   • How long secondary nameservers serve stale data if primary is unreachable
   • After this, secondary stops answering queries
   • Typical: 604800-1209600 (7-14 days)

7. Minimum TTL (86400 seconds = 24 hours)

   • Default TTL for negative responses (NXDOMAIN)
   • How long to cache "domain doesn't exist" responses
   • Typical: 300-86400 (5 minutes - 24 hours)

Serial Number Best Practices

Format Options:

# Date-based serial (recommended)
2025120101    ; YYYYMMDDNN (December 1, 2025, revision 01)

# Unix timestamp
1733011200    ; Seconds since epoch

# Incremental
42            ; Simple counter

Why Serial Numbers Matter:

• Secondary nameservers only update if serial increases
• If you decrease the serial, secondaries won't update
• Serial number must fit in 32-bit unsigned integer (max: 4,294,967,295)
• Date format allows 99 updates per day with clear versioning

SOA Record Examples

Standard Configuration:

example.com.    IN    SOA    ns1.example.com. hostmaster.example.com. (
                             2025120101  ; Serial
                             7200        ; Refresh (2 hours)
                             3600        ; Retry (1 hour)
                             1209600     ; Expire (14 days)
                             86400 )     ; Minimum (1 day)

High-Traffic Site (Shorter Intervals):

example.com.    IN    SOA    ns1.example.com. hostmaster.example.com. (
                             2025120101  ; Serial
                             3600        ; Refresh (1 hour)
                             600         ; Retry (10 minutes)
                             604800      ; Expire (7 days)
                             300 )       ; Minimum (5 minutes)

Low-Change Zone (Longer Intervals):

example.com.    IN    SOA    ns1.example.com. hostmaster.example.com. (
                             2025120101  ; Serial
                             86400       ; Refresh (24 hours)
                             7200        ; Retry (2 hours)
                             2419200     ; Expire (28 days)
                             86400 )     ; Minimum (1 day)

SOA Record Best Practices

• Increment serial after every change: Essential for zone propagation
• Use date-based serials: Makes tracking changes easier
• Set reasonable refresh intervals: Balance update speed vs. DNS traffic
• Keep retry less than refresh: Ensures timely retry attempts
• Set appropriate expire time: Long enough to survive extended outages
• Use professional email: Route hostmaster@ or admin@ to responsible person
• Document changes: Maintain change log with serial number references

Viewing SOA Records

# Query SOA record
dig example.com SOA

# Query from specific nameserver
dig @ns1.example.com example.com SOA

# Compact output
dig example.com SOA +short

PTR Record (Pointer Record)

PTR records provide reverse DNS lookup, mapping IP addresses back to domain names.

What Is a PTR Record?

A PTR (Pointer) record performs reverse DNS lookup, mapping an IP address to a domain name. While A records go from domain to IP, PTR records go from IP to domain.

PTR Record Format

IPv4 PTR Record:

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

IPv6 PTR Record:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.    PTR    mail.example.com.

How Reverse DNS Works

For IP address 192.0.2.1:

1. Reverse the octets: 1.2.0.192
2. Append .in-addr.arpa: 1.2.0.192.in-addr.arpa
3. Query for PTR record
4. PTR record returns domain name: mail.example.com

Common Uses for PTR Records

1. Email Server Reputation

   • Email servers check PTR records to verify sender identity
   • Missing or mismatched PTR records trigger spam filters
   • Essential for email deliverability

2. Security and Logging

   • Convert IP addresses in logs to readable hostnames
   • Identify source of network connections
   • Forensic analysis of security incidents

3. Network Troubleshooting

   • Identify devices on a network
   • Verify server identity
   • Diagnose connectivity issues

PTR Record Requirements for Email

Forward-Confirmed Reverse DNS (FCrDNS):

# Forward lookup
mail.example.com.    A    192.0.2.1

# Reverse lookup
1.2.0.192.in-addr.arpa.    PTR    mail.example.com.

Both must match for proper FCrDNS:

1. PTR record for IP returns domain name
2. A record for that domain name returns original IP
3. If they match: FCrDNS passes

Why This Matters for Email:

• Major email providers (Gmail, Outlook) check FCrDNS
• Missing PTR: Email may be marked as spam
• Mismatched PTR: Email may be rejected
• Proper PTR: Improves sender reputation

Setting Up PTR Records

Important: You typically cannot set PTR records yourself. PTR records must be configured by the organization that owns the IP address block.

How to Set PTR Records:

1. Dedicated Server/VPS: Contact your hosting provider or use their control panel
2. Cloud Provider (AWS, GCP, Azure): Configure through platform settings
3. Corporate Network: Work with your ISP or network administrator
4. Colocation: Contact the data center or IP provider

Example Request to Hosting Provider:

Please set PTR record for:
IP Address: 192.0.2.1
Hostname: mail.example.com

PTR Record Best Practices

• Match A and PTR records: Ensure forward and reverse DNS match exactly
• Use FQDN: Always include the trailing dot (mail.example.com.)
• One PTR per IP: Each IP should have exactly one PTR record
• Email servers must have PTR: Non-negotiable for email delivery
• Test email reputation: Use MXToolbox or similar to verify configuration
• Update after IP changes: Request PTR update if your server IP changes

Checking PTR Records

# Check PTR record (Linux/Mac)
dig -x 192.0.2.1

# Check PTR record (alternative)
nslookup 192.0.2.1

# Check FCrDNS
dig -x 192.0.2.1 +short
dig mail.example.com +short

# Check from specific nameserver
dig @8.8.8.8 -x 192.0.2.1

Common PTR Record Problems

1. No PTR Record

   • Symptom: Email rejected or marked as spam
   • Solution: Contact IP owner to create PTR record

2. Mismatched PTR

   • Symptom: FCrDNS fails
   • Example: PTR returns server123.hosting.com but you send email as mail.example.com
   • Solution: Either update PTR to match email hostname, or update email hostname

3. Multiple PTR Records

   • Symptom: Inconsistent reverse DNS results
   • Solution: Keep only one PTR per IP

4. Generic PTR

   • Example: 192-0-2-1.static.isp.com
   • Solution: Request custom PTR from provider

SRV Record (Service Record)

SRV records enable service discovery by specifying the location of specific services within a domain.

What Is an SRV Record?

An SRV (Service) record specifies the hostname and port number for specific services. SRV records allow clients to discover service locations through DNS rather than hardcoded addresses.

SRV Record Format

_service._proto.name.    TTL    IN    SRV    priority weight port target.

Example:

_sip._tcp.example.com.    3600    IN    SRV    10 60 5060 sipserver.example.com.

SRV Record Components

1. Service (_sip): The service name (always prefixed with underscore)
2. Protocol (_tcp): Protocol (tcp, udp, or others)
3. Name (example.com.): Domain name
4. Priority (10): Like MX priority, lower is preferred
5. Weight (60): Load balancing for same priority (higher = more traffic)
6. Port (5060): Service port number
7. Target (sipserver.example.com.): Hostname providing the service

Common Uses for SRV Records

1. VoIP Services (SIP)

   _sip._tcp.example.com.       SRV    10 60 5060 sip1.example.com.
   _sip._tcp.example.com.       SRV    10 40 5060 sip2.example.com.
   _sip._tcp.example.com.       SRV    20  0 5060 sip-backup.example.com.
   

2. XMPP/Jabber (Chat)

   _xmpp-client._tcp.example.com.    SRV    5  0 5222 xmpp.example.com.
   _xmpp-server._tcp.example.com.    SRV    5  0 5269 xmpp.example.com.
   

3. LDAP Directory Services

   _ldap._tcp.example.com.    SRV    10  0 389 ldap.example.com.
   

4. Microsoft Active Directory

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

5. Minecraft Server

   _minecraft._tcp.example.com.    SRV    0 5 25565 mc.example.com.
   

Priority and Weight Explained

Priority (Lower = higher priority):

• Clients try lowest priority first
• Only move to higher priority if lower fails
• Same as MX record priority

Weight (Higher = more traffic):

• Only matters when multiple records have same priority
• Used for load balancing
• Weight 0 = minimum selection chance

Example Configuration:

# Primary servers (priority 10) with 60/40 load balancing
_service._tcp.example.com.    SRV    10 60 5060 server1.example.com.
_service._tcp.example.com.    SRV    10 40 5060 server2.example.com.

# Backup server (priority 20), only used if primary fails
_service._tcp.example.com.    SRV    20  0 5060 backup.example.com.

Traffic distribution:

• server1: 60% of traffic (priority 10, weight 60)
• server2: 40% of traffic (priority 10, weight 40)
• backup: Only if server1 and server2 fail

SRV Record Best Practices

• Use standard service names: Follow IANA registry for service names
• Include backup servers: Add higher priority SRV for failover
• Set appropriate weights: Distribute load based on server capacity
• Point to A records: SRV targets should have A/AAAA records
• Test service discovery: Verify clients can discover and connect
• Document port numbers: Maintain list of services and ports

Common SRV Service Names

Querying SRV Records

# Query SRV record
dig _sip._tcp.example.com SRV

# Query with short output
dig _sip._tcp.example.com SRV +short

# Query specific service
dig _xmpp-client._tcp.example.com SRV

# Query from specific nameserver
dig @8.8.8.8 _sip._tcp.example.com SRV

Other DNS Record Types

While the main record types cover most needs, several specialized record types serve specific purposes.

CAA Record (Certification Authority Authorization)

CAA records specify which certificate authorities (CAs) can issue SSL/TLS certificates for your domain.

example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 issue "digicert.com"
example.com.    CAA    0 issuewild "letsencrypt.org"
example.com.    CAA    0 iodef "mailto:[email protected]"

CAA Record Components:

• Flag (0): Critical flag (0 = non-critical)
• Tag: Type of authorization
  • issue: Authorize for domain
  • issuewild: Authorize for wildcard certificates
  • iodef: Reporting endpoint for violations
• Value: Certificate authority or email

Why CAA Matters:

• Prevents unauthorized certificate issuance
• Reduces risk of man-in-the-middle attacks
• Required check by CAs since September 2017

TLSA Record (DNS-Based Authentication of Named Entities)

TLSA records provide certificate information for DANE (DNS-based Authentication of Named Entities), enabling certificate validation through DNS.

_443._tcp.example.com.    TLSA    3 1 1 ABC123DEF456...

Used for enhanced SSL/TLS security by pinning certificates in DNS.

NAPTR Record (Naming Authority Pointer)

NAPTR records enable advanced service discovery and URI resolution, primarily used in telephony applications.

example.com.    NAPTR    100 10 "u" "E2U+sip" "!^.*$!sip:[email protected]!" .

Common in VoIP, ENUM (telephone number mapping), and dynamic delegation.

DNSKEY Record

DNSKEY records store public keys for DNSSEC (DNS Security Extensions), enabling cryptographic validation of DNS responses.

example.com.    DNSKEY    257 3 8 AwEAAagAIK...

Part of DNSSEC infrastructure for preventing DNS spoofing and cache poisoning.

DS Record (Delegation Signer)

DS records establish a chain of trust in DNSSEC by storing a hash of a child zone's DNSKEY record.

example.com.    DS    12345 8 2 ABC123DEF456...

HINFO Record (Host Information)

HINFO records provide information about host hardware and operating system.

server.example.com.    HINFO    "INTEL-XEON" "LINUX"

Security Warning: HINFO records reveal system information that could aid attackers. Rarely used in modern DNS.

DNS Record Comparison Table

Record Type Decision Tree

Need to point domain to server?

• IPv4: Use A record
• IPv6: Use AAAA record

Need to create alias?

• Use CNAME record (except root domain)

Need to configure email?

• Routing: Use MX record
• Security: Use TXT records (SPF, DKIM, DMARC)

Need to verify domain ownership?

• Use TXT record

Need to delegate DNS?

• Use NS record

Need reverse DNS?

• Use PTR record (contact IP owner)

Need service discovery?

• Use SRV record

Best Practices for DNS Record Management

1. Documentation

Maintain DNS Documentation:

• List all records with their purpose
• Document changes with dates and reasons
• Keep contact information for DNS providers
• Maintain disaster recovery procedures

Example Documentation Template:

DNS Record Inventory - example.com
Last Updated: 2025-12-01

A Records:
- example.com → 192.0.2.1 (Primary web server)
- www.example.com → 192.0.2.1 (WWW alias via CNAME)
- mail.example.com → 192.0.2.2 (Mail server)

MX Records:
- Priority 10: mail.example.com (Primary)
- Priority 20: backup.example.com (Backup)

TXT Records:
- SPF: "v=spf1 mx include:_spf.google.com ~all"
- DKIM: google._domainkey (Google Workspace)
- DMARC: "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

2. TTL Strategy

Adjust TTL Based on Activity:

# Normal operation (stable)
3600-86400 seconds (1-24 hours)

# Before migration (allow quick changes)
300-600 seconds (5-10 minutes)

# During migration (respond to issues)
60-300 seconds (1-5 minutes)

# After migration (return to normal)
3600-86400 seconds (1-24 hours)

TTL Best Practices:

• Lower TTL 24-48 hours before planned changes
• Never use TTL below 60 seconds in production
• Longer TTL reduces DNS query load
• Shorter TTL enables faster updates

3. Redundancy

Always Configure Backups:

Nameservers:

# Minimum 2, recommended 3-4 on different networks
example.com.    NS    ns1.provider.com.
example.com.    NS    ns2.provider.com.
example.com.    NS    ns3.provider.com.

Mail Servers:

# Primary + backup MX
example.com.    MX    10    mail.example.com.
example.com.    MX    20    backup.example.com.

Web Servers:

# Multiple A records for load balancing
example.com.    A    192.0.2.1
example.com.    A    192.0.2.2

4. Security

Implement DNS Security Measures:

• Enable DNSSEC: Prevent DNS spoofing and cache poisoning
• Use CAA records: Restrict certificate issuance
• Implement email authentication: SPF, DKIM, DMARC
• Monitor DNS changes: Set up alerts for unauthorized modifications
• Use registry lock: Prevent unauthorized domain transfers
• Restrict zone transfers: Only allow authorized secondary nameservers
• Regular audits: Review DNS records quarterly for unnecessary entries

5. Testing

Test Before and After Changes:

# Test A record
dig example.com A +short

# Test MX records
dig example.com MX +short

# Test from multiple locations
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# Check DNS propagation
https://www.whatsmydns.net

# Test email configuration
https://mxtoolbox.com

6. Monitoring

Set Up DNS Monitoring:

• Monitor nameserver availability
• Alert on DNS resolution failures
• Track DNS query performance
• Monitor TTL expiration
• Check for unauthorized changes
• Verify DNSSEC signatures

Recommended Monitoring Tools:

• Pingdom (uptime monitoring)
• DNSCheck (DNS validation)
• MXToolbox (email configuration)
• Uptime Robot (free monitoring)

7. Change Management

DNS Change Checklist:

1. Plan

   • Document current configuration
   • Identify all affected records
   • Lower TTL 24-48 hours in advance
   • Schedule change during low-traffic period

2. Test

   • Test new configuration in staging
   • Verify forward and reverse DNS
   • Check all dependent services
   • Prepare rollback plan

3. Execute

   • Make changes during maintenance window
   • Monitor logs for errors
   • Test from multiple locations
   • Verify all services function correctly

4. Verify

   • Check DNS propagation
   • Test from different geographic locations
   • Monitor service metrics
   • Confirm no unexpected issues

5. Document

   • Record changes made
   • Update DNS documentation
   • Note any issues encountered
   • Return TTL to normal values

Frequently Asked Questions

What's the difference between A and CNAME records?

An A record points a domain directly to an IP address, while a CNAME record creates an alias that points to another domain name. Use A records for root domains and when you control the IP. Use CNAME records for subdomains pointing to third-party services or when you want automatic IP updates.

Can I use CNAME for my root domain?

No, you cannot use CNAME for root domains (example.com) due to RFC 1912 restrictions. Root domains must have A or AAAA records. Some DNS providers offer ALIAS or ANAME records as alternatives that work like CNAME but are allowed at the root domain.

How long does it take for DNS changes to propagate?

DNS propagation depends on TTL values. If your records have a 3600-second TTL, full propagation takes 1-2 hours. To speed this up, lower your TTL to 300 seconds (5 minutes) 24-48 hours before making changes. After the change, propagation will complete within the new TTL timeframe.

Why is my email going to spam even with correct MX records?

MX records only handle routing. Email reputation requires additional records: SPF (authorizes mail servers), DKIM (signs messages), DMARC (sets policies), and PTR records (reverse DNS). All four must be configured correctly, and your mail server must not be blacklisted.

How many DNS records can I have?

There's no strict limit on the number of DNS records per domain, but practical limits exist. Most DNS providers support thousands of records per domain. However, excessive records slow DNS responses and may hit provider-specific limits. For optimal performance, keep records organized and remove unused entries.

Should I use multiple A records or a CNAME for load balancing?

For basic load balancing, multiple A records (round-robin DNS) work but lack health checking. For production systems, use a proper load balancer with a single A record, or use a DNS-based load balancing service that monitors server health and routes traffic accordingly.

What happens if I delete an NS record?

Deleting all NS records for your domain will make it unreachable - DNS queries will fail and your website and email will stop working. Always maintain at least 2 NS records pointing to functioning nameservers. Never modify NS records unless you're intentionally changing DNS providers.

Can I point multiple domains to the same IP?

Yes, multiple domains can have A records pointing to the same IP address. Your web server must be configured to handle multiple domains (virtual hosts) and serve the appropriate content based on the domain requested. This is how shared hosting works.

Why do I need both SPF and DKIM?

SPF and DKIM serve different purposes. SPF validates that email comes from authorized servers (checks infrastructure). DKIM validates that email wasn't tampered with in transit (checks message integrity). Together with DMARC, they provide comprehensive email authentication and prevent spoofing.

How do I fix "DNS_PROBE_FINISHED_NXDOMAIN" errors?

This error means the domain doesn't exist in DNS. Causes include: domain not registered, incorrect nameservers, missing A records, or DNS propagation in progress. Verify your domain is registered, check nameserver configuration at your registrar, and ensure A records exist in your DNS zone file.

Key Takeaways

• A and AAAA records map domains to IP addresses (IPv4 and IPv6)
• CNAME records create aliases but cannot be used at root domains
• MX records route email with priority-based failover
• TXT records enable SPF, DKIM, DMARC for email security and domain verification
• NS records delegate DNS authority to specific nameservers
• SOA records define zone authority and refresh parameters
• PTR records provide reverse DNS, critical for email delivery
• SRV records enable service discovery with port and priority information
• Multiple record types work together for complete domain functionality
• Proper configuration requires understanding each record type's purpose and limitations
• Regular monitoring and documentation prevent DNS-related outages
• Security measures like DNSSEC, CAA, and email authentication protect your domain

Next Steps

Improve Your DNS Configuration

1. Audit Current Records

   • Use DomainDetails.com to view all your DNS records
   • Identify missing or misconfigured records
   • Document current configuration

2. Implement Email Security

   • Add SPF, DKIM, and DMARC records
   • Test email authentication with MXToolbox
   • Monitor DMARC reports for issues

3. Set Up Monitoring

   • Configure DNS monitoring for your nameservers
   • Set up alerts for DNS failures
   • Track DNS query performance

4. Plan for Changes

   • Lower TTL before planned migrations
   • Test changes in staging environment
   • Prepare rollback procedures

Monitor Your DNS with DomainDetails Pro

Upgrade to DomainDetails Pro for advanced DNS monitoring:

• Automatic DNS monitoring - Track all record changes
• Change history - See when records were modified
• Email alerts - Get notified of DNS issues
• Bulk lookups - Check multiple domains at once
• Export reports - Download DNS data for analysis

Start Your Free Trial →

Related Articles

• What is DNS and How Does It Work?
• Understanding DNS TTL and Propagation
• Understanding EPP Status Codes
• How Do Domain Names Work?
• Domain Lifecycle Stages

Research Sources

1. RFC 1035 - Domain Names - Implementation and Specification
2. RFC 1912 - Common DNS Operational and Configuration Errors
3. RFC 3596 - DNS Extensions to Support IP Version 6
4. RFC 7208 - Sender Policy Framework (SPF)
5. RFC 6376 - DomainKeys Identified Mail (DKIM)
6. RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
7. RFC 2782 - A DNS RR for specifying the location of services (SRV)
8. RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record
9. IANA - DNS Parameters Registry
10. ICANN - DNS Best Current Practices