DNS Records Explained: A, AAAA, CNAME, MX, TXT, and SPF with Practical Examples

Why DNS Records Matter

DNS (Domain Name System) is the backbone of internet infrastructure. When you type a domain into your browser, DNS records determine where traffic goes, how email is routed, and whether your domain is legitimate. Misconfigured DNS records can break your website, email delivery, or security posture.

Whether you’re setting up a new domain, migrating servers, or implementing email authentication, understanding DNS record types is essential. This guide covers the most common types and shows how to configure, test, and troubleshoot them.

What Are DNS Records?

DNS records are text-based instructions stored on authoritative nameservers. Each record tells DNS resolvers how to handle requests for your domain. Records are organized by type, and each type serves a specific purpose.

Every DNS record contains:

• Name/Host: The subdomain or domain being queried
• Type: The record type (A, AAAA, CNAME, MX, TXT, SPF)
• Value/Data: Where traffic should be directed
• TTL (Time To Live): How long the record is cached (in seconds)
• Priority (for some types): Determines order of preference (MX records)

A Records: IPv4 Addresses

The A record (Address record) maps a domain name to an IPv4 address. It’s the most fundamental DNS record type.

A Record Example

Host: example.com
Type: A
Value: 192.0.2.1
TTL: 3600

This tells DNS resolvers: “When someone requests example.com, send them to IP 192.0.2.1.”

Real-World Scenario

You’re launching a web application on a server at 192.0.2.1. Your DNS control panel (GoDaddy, Route 53, Cloudflare, etc.) lets you create an A record:

example.com  A  192.0.2.1  3600
www.example.com  A  192.0.2.1  3600

Browser requests now resolve:

1. User types example.com
2. Resolver queries authoritative nameserver
3. Nameserver returns 192.0.2.1
4. Browser connects to that IP

TTL Considerations

• Low TTL (300–600 seconds): Changes propagate quickly, but increases resolver load
• High TTL (86400+ seconds): Reduces query volume, but changes take longer to propagate
• During migrations: Lower TTL before changing IPs to speed propagation

AAAA Records: IPv6 Addresses

The AAAA record (quad-A) is the IPv6 equivalent of an A record. As IPv6 adoption grows, AAAA records are increasingly important for modern infrastructure.

AAAA Record Example

Host: example.com
Type: AAAA
Value: 2001:0db8:85a3::8a2e:0370:7334
TTL: 3600

Dual-Stack Setup

Modern deployments use both A and AAAA records for IPv4 and IPv6 support:

example.com  A     192.0.2.1                          3600
example.com  AAAA  2001:0db8:85a3::8a2e:0370:7334     3600

Resolvers query both records and attempt IPv6 first if available.

Why It Matters

IPv6 adoption is critical in enterprise and cloud environments. Many ISPs and cloud providers now prefer IPv6 traffic. Without AAAA records, your site may be inaccessible to IPv6-only clients (though still rare).

CNAME Records: Aliases

A CNAME record (Canonical Name) creates an alias pointing to another domain name. It’s useful for subdomains and service integrations.

CNAME Record Example

Host: blog.example.com
Type: CNAME
Value: example.wordpress.com
TTL: 3600

This says: “Requests for blog.example.com should be treated as requests for example.wordpress.com.”

Real-World Use Cases

1. CDN Integration

You host static assets on Cloudflare:

cdn.example.com  CNAME  example.com.cdn.cloudflare.net  3600

2. Third-Party Services

You use a commenting platform (Disqus):

comments.example.com  CNAME  disqus.example.com  3600

3. Subdomain Delegation

Your API team manages api.example.com independently:

api.example.com  CNAME  api-prod.internal.example.com  3600

Important CNAME Restrictions

• CNAME cannot exist at the root domain: You cannot have example.com CNAME other.com. Use A records for the root.
• CNAME conflicts: A domain cannot have both CNAME and A records (or any other record type)
• CNAME chains: Avoid multiple CNAME hops; they increase query latency

Testing CNAME Resolution

Use the DNS Lookup tool to verify CNAME records:

nslookup blog.example.com
# Returns: blog.example.com is an alias for example.wordpress.com
# example.wordpress.com has address 192.0.2.50

MX Records: Mail Exchange

An MX record (Mail Exchange) directs email traffic to mail servers. It’s critical for email delivery.

MX Record Example

Host: example.com
Type: MX
Value: mail.example.com
Priority: 10
TTL: 3600

The priority field determines preference (lower numbers = higher priority).

Multiple MX Records (Failover)

Redundancy is essential for email reliability:

example.com  MX  10  mail1.example.com  3600
example.com  MX  20  mail2.example.com  3600
example.com  MX  30  mail3.example.com  3600

Mail servers try mail1.example.com first. If it fails, they try mail2.example.com, then mail3.example.com.

Real-World Scenario: Using Google Workspace

Google provides MX records for their email service:

example.com  MX  5   gmail-smtp-in.l.google.com           3600
example.com  MX  10  alt1.gmail-smtp-in.l.google.com       3600
example.com  MX  20  alt2.gmail-smtp-in.l.google.com       3600
example.com  MX  30  alt3.gmail-smtp-in.l.google.com       3600
example.com  MX  40  alt4.gmail-smtp-in.l.google.com       3600

Google manages multiple servers for redundancy. Lower priorities are tried first.

Best Practices

• Always configure at least 2 MX records
• Use geographically distributed mail servers
• Test MX resolution with DNS tools
• Monitor mail delivery logs

TXT Records: Text Data

A TXT record stores arbitrary text data. It’s used for domain verification, email authentication, and service configuration.

TXT Record Example

Host: example.com
Type: TXT
Value: "v=spf1 include:_spf.google.com ~all"
TTL: 3600

Common TXT Record Uses

1. Domain Verification

Third-party services (Google Search Console, Stripe) request verification:

example.com  TXT  "google-site-verification=abc123def456"  3600

2. DKIM (DomainKeys Identified Mail)

Public key for email signing:

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

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

Email authentication policy:

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

4. Service Configuration

Acme protocol for Let’s Encrypt SSL verification:

_acme-challenge.example.com  TXT  "aBcD1234xYz..."  3600

Testing TXT Records

Use the DNS Lookup tool to query TXT records:

nslookup -type=TXT example.com
# Returns: v=spf1 include:_spf.google.com ~all

SPF Records: Sender Policy Framework

An SPF record is a TXT record that specifies which mail servers are authorized to send email from your domain. It prevents email spoofing and improves deliverability.

SPF Record Example

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

This means: “Only mail from 192.0.2.1 and Google’s servers can send email from @example.com.”

SPF Syntax Breakdown

SPF Qualifiers

• + (pass): Server is authorized
• - (fail): Server is not authorized
• ~ (softfail): Soft denial (for testing)
• ? (neutral): No policy

SPF Mechanisms

v=spf1                          # SPF version (always first)
ip4:192.0.2.0/24                # Authorize IPv4 range
ip6:2001:db8::/32               # Authorize IPv6 range
a                               # Authorize domain's A record
mx                              # Authorize domain's MX records
include:_spf.google.com         # Include another domain's SPF
ptr:example.com                 # Reverse DNS check (deprecated)
~all                            # Softfail for all others
-all                            # Hard fail for all others

Real-World SPF Configuration

Scenario: Using Google Workspace + Custom Mail Server

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

This authorizes:

• Your mail server at 192.0.2.1
• Google’s servers (via include:_spf.google.com)
• Soft-fail for others (temporary rejection)

Scenario: SaaS Email Platform (SendGrid)

example.com  TXT  "v=spf1 include:sendgrid.net ~all"  3600

SPF Best Practices

1. Keep it simple: Each SPF lookup adds latency. Limit mechanisms to 10 or fewer.
2. Use ~all for testing: Before enforcing with -all, use softfail.
3. Monitor rejections: Use SPF reporting to catch misconfiguration.
4. Use the SPF Analyzer: Validate your SPF record for syntax errors and efficiency.

Testing SPF Records

The SPF Analyzer tool validates SPF syntax and detects common issues:

v=spf1 ip4:192.0.2.1 include:_spf.google.com ~all
# ✓ Valid SPF record
# ✓ Uses 2 mechanisms (within limits)
# ✓ Softfail is safe for testing

Putting It All Together: Complete DNS Setup

Here’s a practical example of a complete DNS configuration for a business domain:

# Root domain (A record for IPv4)
example.com                    A        192.0.2.1                      3600

# IPv6 support
example.com                    AAAA     2001:0db8:85a3::8a2e:0370:7334 3600

# WWW subdomain (CNAME to CDN)
www.example.com                CNAME    example.com.cdn.cloudflare.net  3600

# API subdomain (A record for dedicated API server)
api.example.com                A        192.0.2.50                     3600

# Mail exchange (Google Workspace)
example.com                    MX       5   gmail-smtp-in.l.google.com     3600
example.com                    MX       10  alt1.gmail-smtp-in.l.google.com 3600

# SPF (authorize Google and custom server)
example.com                    TXT      "v=spf1 ip4:192.0.2.1 include:_spf.google.com ~all" 3600

# DKIM (email signing)
default._domainkey.example.com TXT      "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." 3600

# DMARC (email policy)
_dmarc.example.com             TXT      "v=DMARC1; p=quarantine; rua=mailto:[email protected]" 3600

# Domain verification (Google Search Console)
example.com                    TXT      "google-site-verification=abc123def456" 3600

Common DNS Pitfalls and Troubleshooting

1. CNAME at Root Domain

Problem: example.com CNAME other.com

Why it fails: The root domain must have an A or AAAA record for basic DNS resolution. CNAME cannot coexist with other records at the root.

Solution: Use an A record at root; reserve CNAME for subdomains.

2. Forgetting MX Records

Problem: Email sent to @example.com bounces. No MX records exist.

Why it fails: Without MX records, mail servers don’t know where to deliver email.

Solution: Always create at least 2 MX records with different priorities.

3. SPF Lookup Limit Exceeded

Problem: too many DNS lookups (max 10) error

Why it fails: SPF mechanisms that require DNS lookups (include, mx, a) are limited to 10 total. Exceeding this breaks SPF.

Example of problem:

v=spf1 include:vendor1.com include:vendor2.com include:vendor3.com \
       include:vendor4.com include:vendor5.com include:vendor6.com ~all
# ✗ 6 includes + implicit lookups = >10 lookups

Solution: Consolidate vendors or create a single include point that aggregates all vendors.

4. DNS Propagation Delays

Problem: Changed DNS records, but old values still resolve.

Why it happens: TTL caching. Recursive resolvers cache records for the TTL duration.

Solution:

• Lower TTL before making changes (300–600 seconds)
• Wait for old TTL to expire (or force flush local DNS cache)
• Use the DNS Lookup tool to check propagation

5. Typos in DNS Values

Problem: api.example.com CNAME api.exmaple.com (typo: “exmaple”)

Why it fails: DNS query returns NXDOMAIN (non-existent domain).

Solution: Double-check domain names. Use DNS lookup tools to verify resolution.

Tools for DNS Testing and Validation

When configuring DNS records, use these tools to verify configuration:

DNS Lookup

Query A, AAAA, CNAME, MX, TXT, and other records. Test propagation across regions.

# Test A record
nslookup example.com

# Test MX records
nslookup -type=MX example.com

# Test SPF
nslookup -type=TXT example.com

SPF Analyzer

Validate SPF syntax, check for DNS lookup limits, and test SPF policies.

Input: v=spf1 ip4:192.0.2.1 include:_spf.google.com ~all
Output: ✓ Valid SPF | 2 mechanisms | Ready for production

Domain Checker

Verify domain registration and check basic DNS health.

DNS Record Priority and Performance

TTL Strategy

Choose TTL based on your change frequency:

Scenario	TTL	Reasoning
Stable production domain	86400 (24 hours)	Low query load
Active development	300–600	Fast propagation
During migration	300	Minimize downtime
Email records	3600	Balance responsiveness

Query Optimization

• Minimize CNAME chains: Resolvers must follow each CNAME, increasing latency
• Use A records when possible: Direct resolution is faster than CNAME
• Batch DNS queries: Modern browsers parallelize DNS lookups

Best Practices Summary

1. Always use A and AAAA records for primary domains
2. Create multiple MX records with different priorities for redundancy
3. Implement SPF, DKIM, and DMARC to secure email
4. Test configuration with DNS lookup and SPF validation tools
5. Lower TTL before changes to speed propagation
6. Document your DNS setup for team collaboration
7. Monitor DNS health regularly for misconfiguration
8. Use CNAME for subdomains, not root domains
9. Keep SPF records simple to avoid lookup limit errors
10. Verify email authentication with test sends and DMARC reports

Conclusion

DNS records are the foundation of internet infrastructure. Understanding A, AAAA, CNAME, MX, TXT, and SPF records—and how to configure them correctly—is essential for any developer or DevOps engineer.

Start with basic A/AAAA records for your domain, add MX records for email, and layer in SPF for authentication. Use DNS lookup and SPF validation tools to verify your configuration, and follow the best practices outlined here to ensure reliability and security.

DNS may seem complex, but mastering these record types gives you full control over domain infrastructure.