Skip to main content
Back to blog

DNS Record Types Explained — A, AAAA, MX, TXT, and More

networkingDNSinfrastructure

DNS Record Types Explained — A, AAAA, MX, TXT, and More

DNS (Domain Name System) translates human-readable domain names into the addresses and metadata that internet infrastructure needs. But "DNS" isn't a single lookup — it's a system of different record types, each serving a different purpose. If you've ever set up a website, configured email, or verified domain ownership, you've worked with DNS records. Here's what each type does and when you need it.

A records — IPv4 addresses

An A record maps a domain name to an IPv4 address. This is the most fundamental DNS record — it's what makes example.com resolve to 93.184.216.34.

example.com.    300    IN    A    93.184.216.34

The number 300 is the TTL (Time To Live) in seconds — how long resolvers should cache this answer before checking again. Lower TTLs mean changes propagate faster; higher TTLs reduce DNS query load.

Most domains have at least one A record. Many have multiple, either for load balancing (round-robin DNS distributes traffic across several servers) or for redundancy. When a domain has multiple A records, resolvers typically rotate through them.

When you need it: Every domain that serves a website or receives direct IP connections needs an A record. If you're pointing a domain to a web host, the first thing you'll set is the A record.

AAAA records — IPv6 addresses

An AAAA record (pronounced "quad-A") is the IPv6 equivalent of an A record. It 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 — as of 2025, roughly 40-45% of Google's traffic arrives over IPv6. If your server supports IPv6, publishing AAAA records alongside A records ensures users on IPv6-only or IPv6-preferred networks can reach you without relying on translation mechanisms.

When you need it: Whenever your hosting infrastructure supports IPv6. Most major cloud providers (AWS, GCP, Cloudflare, Vercel) assign IPv6 addresses automatically, and adding AAAA records is usually just a checkbox.

MX records — mail routing

MX records (Mail Exchange) tell the world which servers handle email for your domain. When someone sends an email to [email protected], their mail server looks up the MX records for example.com to find where to deliver it.

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

The number before the server name is the priority (sometimes called preference). Lower numbers have higher priority. In the example above, mail servers will try mail1.example.com first. If it's unreachable, they'll fall back to mail2.example.com. This priority system is how email achieves redundancy — if your primary mail server goes down, the backup still receives mail.

MX records point to hostnames, not IP addresses. The hostname in the MX record must itself have an A or AAAA record. An MX record pointing directly to an IP address is invalid per the DNS specification (RFC 5321).

When you need it: Any domain that receives email. If you use Google Workspace, your MX records point to Google's servers (aspmx.l.google.com, etc.). If you use Microsoft 365, they point to Microsoft. Custom mail servers get their own MX records.

TXT records — text metadata

TXT records store arbitrary text strings associated with a domain. Originally designed for human-readable notes, TXT records now carry critical machine-readable data for email authentication and domain verification.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain.

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

This record says: "Google's mail servers are authorized to send mail for example.com. Treat mail from other servers with suspicion (~all is a soft fail)." Without SPF, anyone can forge your domain in the "From" field of an email, and receiving servers have no way to detect it.

DKIM (DomainKeys Identified Mail)

DKIM uses public-key cryptography to sign outgoing emails. The public key is published as a TXT record, and the private key signs each message. Receiving servers verify the signature against the public key to confirm the message wasn't altered in transit and was sent by an authorized server.

selector._domainkey.example.com.    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails — monitor, quarantine, or reject.

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

Domain verification

Services like Google Search Console, Microsoft 365, and various SaaS platforms verify domain ownership by asking you to add a specific TXT record. If the record appears in DNS, it proves you control the domain.

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

When you need it: Every domain that sends email should have SPF, DKIM, and DMARC records. Domain verification TXT records are needed when setting up third-party services.

NS records — nameservers

NS records (Name Server) delegate authority for a domain to specific DNS servers. They tell the rest of the internet which servers are authoritative for your domain's DNS records.

example.com.    86400    IN    NS    ns1.example-dns.com.
example.com.    86400    IN    NS    ns2.example-dns.com.

When you register a domain and set its nameservers to Cloudflare, AWS Route 53, or your registrar's DNS, you're updating NS records. These records are set at the registry level (not in your DNS zone) and typically have long TTLs.

NS records are also used for subdomain delegation. If you want api.example.com to be managed by a different DNS provider than example.com, you add NS records for api.example.com pointing to that provider's nameservers.

When you need it: Every domain has NS records. You interact with them when you change DNS providers or delegate subdomains.

CNAME records — canonical names

A CNAME record (Canonical Name) creates an alias from one domain name to another. Instead of pointing to an IP address, it says "this name is actually that name — go look up that name instead."

www.example.com.    3600    IN    CNAME    example.com.
blog.example.com.   3600    IN    CNAME    mysite.hosting.com.

When a resolver looks up www.example.com and finds a CNAME pointing to example.com, it follows the chain and looks up the A/AAAA records for example.com.

CNAME has an important constraint: a CNAME cannot coexist with other record types at the same name. This means you cannot put a CNAME on a bare domain (the zone apex, like example.com) because the apex already has NS and SOA records. This is why www.example.com can be a CNAME but example.com cannot — at least not in standard DNS.

Some DNS providers work around this with proprietary record types: Cloudflare's CNAME flattening, AWS Route 53's ALIAS record, and similar features resolve the CNAME chain at the DNS server level and return A/AAAA records directly. This lets you point a bare domain at a CDN or load balancer hostname without violating the CNAME restriction.

When you need it: Whenever you want a subdomain to point to an external service's hostname rather than a fixed IP. Common uses: www pointing to a CDN, subdomains pointing to SaaS platforms (e.g., status.example.com → yoursite.statuspage.io).

SOA records — zone authority

The SOA record (Start of Authority) contains administrative information about a DNS zone. Every zone has exactly one SOA record, and it's mostly relevant to DNS operators rather than end users.

example.com.    86400    IN    SOA    ns1.example-dns.com. admin.example.com. (
                                      2024010101  ; serial number
                                      3600        ; refresh interval
                                      900         ; retry interval
                                      604800      ; expire time
                                      86400       ; minimum TTL
                                      )

The fields that matter:

  • Serial number: Incremented on every zone change. Secondary DNS servers compare serials to know when to pull updates (zone transfers).
  • Refresh interval: How often secondary servers should check for updates.
  • Retry interval: How soon to retry after a failed refresh.
  • Expire time: After this many seconds without a successful refresh, secondaries stop serving the zone.
  • Minimum TTL: The default TTL for negative responses (NXDOMAIN — "this name doesn't exist"). Controls how long resolvers cache the fact that a name doesn't exist.

When you need it: You rarely edit SOA records directly. Managed DNS providers handle them automatically. They become relevant when debugging DNS propagation issues or configuring zone transfers between primary and secondary DNS servers.

Practical scenarios

Setting up email for a new domain

  1. Add MX records pointing to your mail provider (e.g., Google Workspace, Fastmail)
  2. Add an SPF TXT record listing your mail provider's sending IPs
  3. Add a DKIM TXT record with the public key your provider generates
  4. Add a DMARC TXT record with your preferred policy

Pointing a domain to a web host

  1. Add an A record (and AAAA if available) for the bare domain pointing to your host's IP
  2. Add a CNAME for www pointing to the bare domain or the host's provided hostname

Verifying domain ownership

  1. Add the TXT record the service provides (one-time verification)
  2. Some services use CNAME verification instead, asking you to create a specific CNAME under your domain

You can look up any domain's records using our DNS lookup tool — it queries each record type and shows the results with TTL values, so you can verify your configuration or inspect how other domains are set up.