The Difference Between A, AAAA, CNAME, and MX Records

In the early days of ARPANET and early Internet, hosts were tracked in a simple flat file (like HOSTS.TXT) listing names and numeric addresses. As the network expanded, that approach became unscalable. The Domain Name System (DNS), introduced in the early 1980s (Mockapetris’s RFC 1034/1035), replaced that flat file with a hierarchical, distributed naming system. Over time, DNS evolved to support multiple record types—not only mapping names to IP addresses but also expressing aliases, mail routing, service records, and more.

When deploying services today, you rely heavily on a handful of master record types. Among them, A, AAAA, CNAME, and MX are among the most common. Understanding their differences (and constraints) is critical to correct DNS configuration, avoiding pitfalls, and ensuring robust name resolution.

The basic matchmakers: A vs AAAA

A (Address) record

An A record maps a hostname (domain) to an IPv4 address (32-bit). It is one of the oldest and most fundamental DNS record types. When you type www.dropletdrift.com, a resolver may fetch its A record to discover, say, 93.184.216.34 (as in the example world).

Each A record includes these components:

• Name / label (e.g. www.dropletdrift.com)
• TTL (time to live) — how long it should be cached
• Class (almost always IN for Internet)
• Type (A)
• IPv4 address (e.g. 192.0.2.17)

Because the IPv4 address is fixed in the record, any change in the server’s IP requires you to update the A record(s).

AAAA (Quad-A) record

An AAAA record serves the same purpose—mapping a hostname to an IP—but for IPv6 (128-bit addresses). It is the natural analog of A in the IPv6 world.

If a client supports IPv6, it typically tries AAAA first (or in parallel with A), offering a path to reach your server over IPv6.

Key difference summary:

• A → IPv4
• AAAA → IPv6
• Both are “direct” records: name → IP
• You can (and often do) define both A and AAAA records for the same hostname to support dual-stack clients

The alias: CNAME (Canonical Name) record

What is a CNAME record?

A CNAME record makes one hostname an alias for another (the “canonical” name). In essence, it says: “this name is just another name for that name.” It does not map directly to an IP. The resolver sees the CNAME, then continues with a lookup for the canonical name.

For instance:

blog.dropletdrift.com. 3600 IN CNAME dropletdrift.com.

blog.dropletdrift.com. 3600 IN CNAME dropletdrift.com.

When a resolver asks for blog.dropletdrift.com (type A), the DNS server returns the CNAME, and the resolver restarts the query for dropletdrift.com (type A). It then finds the A or AAAA record of dropletdrift.com and returns the final IP to the client.

Rules and constraints for CNAME

You must observe these key constraints when using CNAMEs:

• A CNAME record must point to another domain name (never to a raw IP).
• If a CNAME exists for a name, no other record types may coexist on that same name (e.g. you cannot have CNAME and MX or A simultaneously for the same label).
• You cannot place a CNAME at the zone apex (root of the domain, e.g. dropletdrift.com) because the apex must host SOA and NS records.
• CNAME chains are allowed (alias → alias → name), but each indirection slows resolution and risks circular loops.
• MX and NS records must point to names with A or AAAA records, not to names that are themselves CNAMEs.

Because of these constraints, CNAMEs are best for subdomains or aliasing non-critical hosts, not for apex or records needing additional types.

Email routing: MX (Mail Exchange) record

What is an MX record?

An MX record tells the world which mail server(s) accept email for a domain. When someone sends mail to user@dropletdrift.com, the sending mail server queries the MX records of dropletdrift.com and gets one or more mail server hostnames, each carrying a priority (preference) number. The sender then attempts delivery starting with the lowest (most preferred) priority.

A sample MX record:

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

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

Here, mail1.dropletdrift.com is preferred; if delivery to it fails, the sender tries the next.

Requirements and constraints

• The hostname in the MX record must resolve via A or AAAA records (not to a CNAME).
• You cannot embed an IP directly in the MX record value; it must be a domain name.
• You may define multiple MX records for redundancy and load distribution.
• The preference number is a 16-bit unsigned integer (0 to 65535). Lower values are tried first.
• RFC changes over time: MX was introduced as a replacement for the older MD/MF records in 1985 (RFC 973/974).

Comparison and interactions

To help you see how they relate, here is a Mermaid diagram showing how a name resolution might traverse these records:

flowchart LR
  S([Start: lookup FQDN + type])
  S --> C{CNAME at FQDN?}
  C -- Yes --> A1[CNAME -> canonical name]
  A1 --> R1[Resolve canonical for requested type]
  C -- No --> R1[Resolve FQDN for requested type]
  R1 -->|type = A or AAAA| IP[Answer: IPs from A/AAAA]
  R1 -->|type = MX| M1[Answer: MX hostnames]
  M1 --> R2[Resolve each hostname to A/AAAA]
  R2 --> IP

Here’s how the types interplay:

• If you query A/AAAA and the name has a CNAME, you first follow the alias (CNAME) to the canonical name, then look up its A/AAAA record.
• If you query MX, you get hostnames of mail servers; those hostnames must themselves have A/AAAA records so they can be resolved to IP addresses.
• Because MX cannot point to a CNAME, that simplifies the chain of resolution and avoids alias ambiguity in mail routing.

Let me recap the main practical differences:

Use cases and recommendations

• Use A (and AAAA) records for core services (web server, API endpoints) that you control at the IP level.
• Use CNAME when you want alias flexibility (e.g. blog.dropletdrift.com → dropletdrift.com) and you don’t need other record types on the alias.
• Avoid putting CNAME at the apex; when your DNS provider supports it, they may offer ALIAS or ANAME pseudo records that resolve like a CNAME behind the scenes but present as A/AAAA.
• Define MX records judiciously—for redundancy, list multiple mail servers with increasing priority—but ensure the target names resolve properly.
• Test your configuration using dig or nslookup to verify the alias chains, IP resolution, and MX priorities.