DNS Record Types Explained: A / AAAA / CNAME / MX / TXT / NS / SRV

A DNS record is the smallest unit of domain resolution. Every entry you add in a domain's control panel is really just telling resolvers around the world: "here's what this name should translate to." Different record types answer different questions—some return an IP address, some point to another name, some carry a line of text. Let's take them one at a time.

A Record (IPv4 Address)

An A record maps a domain to an IPv4 address. It's the most fundamental and most common record. When a browser opens a website or a client connects to a server, an A lookup is usually the first step.

www.example.com.   A   203.0.113.10

This means www.example.com resolves to 203.0.113.10. You can attach several A records to one name for simple round-robin balancing.

AAAA Record (IPv6 Address)

AAAA (say "quad-A") does exactly what an A record does, but returns an IPv6 address. If your server has IPv6, publish both A and AAAA so dual-stack users can reach you either way.

www.example.com.   AAAA   2001:db8::1

CNAME Record (Alias)

A CNAME points one name at another name (not an IP), and the resolver keeps chasing that target. It's handy for aliasing several subdomains onto a single target, so a future IP change only has to be made in one place.

blog.example.com.   CNAME   www.example.com.

A classic mistake: never put a CNAME on the root (apex) domain. A bare domain like example.com (without www) must, by DNS rules, also carry SOA and NS records, but a CNAME requires that no other records exist alongside it—a direct conflict. A CNAME at the apex can break resolution outright, taking your mail and subdomains down with it. Use A/AAAA at the apex; if you genuinely need "point the root at an alias," reach for your provider's ALIAS/ANAME or CNAME-flattening feature instead.

MX Record (Mail Routing)

An MX (Mail Exchanger) record tells outside mail servers where to deliver messages addressed to @example.com. Each record carries a priority number—lower means preferred.

example.com.   MX   10   mail.example.com.

The MX target must be a hostname that resolves to an A/AAAA record. Don't point it at an IP, and don't point it at a CNAME.

TXT Record (Text / Verification)

A TXT record holds arbitrary text. In practice it's used mainly for domain-ownership verification and email-security policies such as SPF, DKIM, and DMARC.

example.com.   TXT   "v=spf1 include:_spf.example.net -all"

That example is an SPF record declaring which hosts may send mail on the domain's behalf. Any "add this TXT record to prove you own the domain" flow lives here too.

NS Record (Delegation)

An NS (Name Server) record names the authoritative servers responsible for a zone. It delegates the right to answer for a domain (or subdomain) to a specific set of servers.

example.com.   NS   ns1.registrar-dns.com.

The NS records set at your registrar decide which DNS service handles the whole domain—that's the prerequisite for every other record you create to take effect.

SRV Record (Service Location)

An SRV record specifies which host and port a given service runs on, common with protocols like SIP, XMPP, Minecraft, and Active Directory. The name follows a service.protocol pattern.

_sip._tcp.example.com.   SRV   10   5   5060   sipserver.example.com.

The four fields are, in order: priority, weight, port, and target host.

Quick Reference

| Type | Purpose | Target | |------|---------|--------| | A | IPv4 address | IPv4 | | AAAA | IPv6 address | IPv6 | | CNAME | Alias (not for apex) | Domain name | | MX | Mail routing | Hostname + priority | | TXT | Text / verification (SPF, etc.) | String | | NS | Delegation | Name servers | | SRV | Service location | Host + port |

Summary

Each record has its own job: A/AAAA land a name on an IPv4/IPv6 address, CNAME creates an alias (never at the apex), MX routes mail, TXT carries verification and security policies, NS decides who answers, and SRV pinpoints a service and its port. Follow two rules of thumb—prefer A/AAAA at the apex, and make sure MX and CNAME targets point to resolvable hostnames—and you'll sidestep the vast majority of common errors. After any change, give the TTL time to expire before the update propagates everywhere.