DNS Records Explained: A Complete Guide for Web Developers

DNS is the system that converts domain names into IP addresses — and much more. Every time someone visits your website, sends you an email, or verifies your domain ownership, DNS records are involved. Misconfigured DNS breaks everything. Correct DNS is invisible.

This guide covers every record type you will encounter as a web developer, with practical examples, real configuration patterns, and the mistakes that cause the most outages.

How DNS Resolution Works

When a browser navigates to example.com, the resolution path involves multiple servers before reaching your content:

sequenceDiagram
    participant B as Browser
    participant R as Recursive Resolver
    participant Root as Root Server
    participant TLD as .com TLD Server
    participant Auth as Authoritative NS
    B->>R: Where is example.com?
    R->>Root: Where is .com?
    Root-->>R: Try these .com TLD servers
    R->>TLD: Where is example.com?
    TLD-->>R: Try these authoritative nameservers
    R->>Auth: What is the A record for example.com?
    Auth-->>R: 93.184.216.34
    R-->>B: 93.184.216.34 (cached for TTL)

The recursive resolver (usually your ISP or a public resolver like 1.1.1.1 or 8.8.8.8) does the heavy lifting. It walks the DNS hierarchy from root to TLD to authoritative nameserver, then caches the result for the duration specified by the record's TTL (Time To Live).

TTL matters. A TTL of 3600 means resolvers cache the answer for one hour. During a migration, lower your TTL to 60-300 seconds before the change so the old value expires quickly. After migration, raise it back for performance.

DNS Record Types

A Record

Maps a domain to an IPv4 address. This is the most fundamental record — it tells the internet where your server is.

example.com.    300    IN    A    93.184.216.34

Most domains have at least one A record. Load-balanced setups use multiple A records pointing to different IP addresses — the resolver returns them in round-robin order.

AAAA Record

The IPv6 equivalent of an A record. Maps a domain to a 128-bit IPv6 address.

example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

IPv6 adoption is growing steadily. Major cloud providers, CDNs, and hosting platforms all support AAAA records. If your infrastructure supports IPv6, publish AAAA records — it improves reachability and can reduce latency for IPv6-native clients.

CNAME Record

An alias that points one domain to another. Instead of an IP address, a CNAME says "look up this other domain instead."

www.example.com.    300    IN    CNAME    example.com.
blog.example.com.   300    IN    CNAME    hosting.provider.com.

Critical rule: A CNAME cannot coexist with any other record type at the same name. This means you cannot put a CNAME on the zone apex (example.com itself) because the apex must have SOA and NS records. Some DNS providers offer proprietary workarounds (Cloudflare's CNAME flattening, AWS Route 53's ALIAS record, DNSimple's ALIAS) that resolve this limitation.

MX Record

Specifies the mail servers that accept email for your domain. The priority value (lower = preferred) determines which server receives mail first.

example.com.    300    IN    MX    10 mail1.example.com.
example.com.    300    IN    MX    20 mail2.example.com.

If the priority-10 server is unreachable, the sending server falls back to priority-20. For Google Workspace, you would configure five MX records pointing to Google's mail servers with different priorities.

MX records must point to A/AAAA records, never CNAMEs. While some mail servers tolerate CNAME targets, RFC 2181 prohibits it, and you will encounter delivery failures with strict MTAs.

TXT Record

A general-purpose text record used for domain verification, email authentication, and configuration metadata. TXT records carry the most operational weight of any record type because they handle:

• SPF — v=spf1 include:_spf.google.com -all
• DKIM — public keys at selector._domainkey.example.com
• DMARC — policies at _dmarc.example.com
• Domain verification — Google, Microsoft, Stripe, and most SaaS platforms verify domain ownership through TXT records

example.com.    300    IN    TXT    "v=spf1 include:_spf.google.com -all"
example.com.    300    IN    TXT    "google-site-verification=abc123..."

You can have multiple TXT records on the same domain. SPF is the exception — you must have exactly one SPF TXT record (multiple SPF records cause validation failures).

NS Record

Delegates authority for a domain to specific nameservers. These tell the internet which servers are authoritative for your zone.

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

NS records are usually set at your registrar and rarely need to change. When you switch DNS providers (e.g., from your registrar's DNS to Cloudflare), you update the NS records at the registrar to point to the new provider's nameservers.

Your NS records identify your DNS provider. When SiteProbe scans a domain, it reads the NS records to determine whether you are using Cloudflare, AWS Route 53, Google Cloud DNS, or another provider — each with different capabilities and configuration patterns.

SOA Record

The Start of Authority record defines administrative parameters for the DNS zone: the primary nameserver, the responsible party's email, a serial number (incremented on each zone change), and timing values for refresh, retry, expiry, and negative caching TTL.

example.com.    86400    IN    SOA    ns1.example.com. admin.example.com. (
                                        2026040601  ; serial
                                        7200        ; refresh
                                        3600        ; retry
                                        1209600     ; expire
                                        300         ; minimum TTL
                                    )

You rarely need to edit SOA records directly — most DNS providers manage them automatically. The minimum TTL field in the SOA controls how long resolvers cache negative responses (NXDOMAIN), which matters when you create new subdomains.

CAA Record

Certificate Authority Authorization records specify which certificate authorities are allowed to issue certificates for your domain. This is a security control that prevents unauthorized CAs from issuing certificates — a defense against CA compromise or social engineering attacks.

example.com.    300    IN    CAA    0 issue "letsencrypt.org"
example.com.    300    IN    CAA    0 issuewild "letsencrypt.org"
example.com.    300    IN    CAA    0 iodef "mailto:security@example.com"

• issue — which CAs can issue standard certificates
• issuewild — which CAs can issue wildcard certificates
• iodef — where to send violation reports

Most domains are missing CAA records. In our scan data across 178 popular domains, the majority have no CAA records at all. Without CAA, any of the hundreds of trusted CAs could issue a certificate for your domain. Adding CAA records takes two minutes and significantly reduces your attack surface.

How Records Work Together

DNS records do not exist in isolation. A typical web domain requires several record types working in concert:

graph TD
    NS["NS Records<br/>Delegate to nameservers"] --> A["A / AAAA Records<br/>Point to server IP"]
    NS --> MX["MX Records<br/>Route email to mail servers"]
    NS --> TXT["TXT Records<br/>SPF, DKIM, DMARC, verification"]
    NS --> CAA["CAA Records<br/>Restrict certificate issuance"]
    A --> CNAME["CNAME Records<br/>Alias subdomains"]
    MX --> AMXR["A Records for mail servers"]

    style NS fill:#1a1f26,stroke:#00d4aa,color:#e8e6e3
    style A fill:#1a1f26,stroke:#00d4aa,color:#e8e6e3
    style MX fill:#1a1f26,stroke:#00d4aa,color:#e8e6e3
    style TXT fill:#1a1f26,stroke:#00d4aa,color:#e8e6e3
    style CAA fill:#1a1f26,stroke:#00d4aa,color:#e8e6e3
    style CNAME fill:#1a1f26,stroke:#00d4aa,color:#e8e6e3
    style AMXR fill:#1a1f26,stroke:#00d4aa,color:#e8e6e3

A minimal production configuration for a domain using Vercel for hosting and Google Workspace for email looks like this:

; Hosting
example.com.        A       76.76.21.21
www.example.com.    CNAME   cname.vercel-dns.com.

; Email
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.

; Email auth
example.com.        TXT     "v=spf1 include:_spf.google.com -all"
google._domainkey   TXT     "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
_dmarc.example.com. TXT     "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

; Security
example.com.        CAA 0   issue "letsencrypt.org"

Common Mistakes

Forgetting to lower TTL before migration. If your A record has a TTL of 86400 (24 hours), some users will point to the old IP for up to a day after you change it. Lower TTL to 60-300 at least 24 hours before the migration, then raise it after.

CNAME at the zone apex. Putting a CNAME on example.com breaks DNS because it conflicts with the required SOA and NS records. Use your provider's ALIAS/ANAME equivalent, or use an A record.

Multiple SPF records. Having two TXT records that both start with v=spf1 causes SPF validation to return permerror — which is worse than having no SPF at all. Consolidate all your authorized senders into a single SPF record using include: mechanisms.

Exceeding SPF lookup limits. SPF allows a maximum of 10 DNS mechanisms (include, a, mx, ptr, exists, redirect). Every include: triggers additional lookups. Organizations using multiple SaaS email senders routinely hit this limit, causing SPF failures.

No CAA records. Without CAA, any trusted CA can issue a certificate for your domain. This is a real attack vector — in a CA compromise, the attacker can issue certificates for your domain. Adding CAA records is free and takes two minutes.

MX pointing to a CNAME. While some mail servers handle this, it violates RFC 2181 and causes intermittent delivery failures. MX targets must resolve directly to A or AAAA records.

Checking Your DNS Configuration

You can verify your records from the command line:

# Check A records
dig A example.com +short

# Check MX records
dig MX example.com +short

# Check TXT records (SPF, DKIM, DMARC)
dig TXT example.com +short
dig TXT _dmarc.example.com +short

# Check CAA records
dig CAA example.com +short

# Check nameservers
dig NS example.com +short

# Trace the full resolution path
dig example.com +trace

For a comprehensive view, dig is sufficient for individual lookups. But verifying the interplay between records — whether your MX targets resolve correctly, whether your SPF includes chain stays under 10 lookups, whether your CAA records cover your actual certificate issuer — requires checking multiple records and cross-referencing them.

How SiteProbe Checks DNS

SiteProbe resolves all record types in parallel — A, AAAA, MX, NS, TXT, SOA, CNAME, and CAA — then analyzes the results together. It identifies your nameserver provider, flags missing CAA records, parses your email authentication chain (SPF, DKIM, DMARC), and reports the full picture in a single view.

Rather than running individual dig commands and cross-referencing manually, scan your domain at siteprobe.live to get a complete DNS health check alongside your SSL grade, security headers, and email authentication analysis — all in one report.