DNS Record Types Cheat Sheet: A vs CNAME vs MX vs TXT

You opened your registrar's DNS panel to make one change, and now you are staring at a dropdown with A, AAAA, CNAME, MX, TXT, NS, and SRV. This cheat sheet skips the theory and answers the only question that matters at that moment: which record type do I add for the task in front of me? Each row is keyed to a real job, and the gotchas section covers the four mistakes that silently break otherwise-correct setups.

The one-screen decision table

Match your goal to a record type. If your goal is in the left column, the second column is almost always the right answer.

A and AAAA: point a name at a machine

An A record maps a hostname directly to an IPv4 address; AAAA does the same for IPv6. This is the foundational record. When you buy a VPS and want example.com to load it, you create an A record on the apex (the bare domain, often shown as @) pointing at the box's IP. To serve over IPv6 too, add an AAAA with the same name. Resolvers will hand out whichever family the client asks for, so having both is fine and increasingly expected. If your host gives you only an IP, A/AAAA is your tool. If they give you a hostname to point at, you are in CNAME territory instead.

CNAME: make one name an alias of another

A CNAME (canonical name) says "this name is just another label for that name; go look up the target instead." It is the right choice when a platform tells you to point www or a subdomain at their hostname, like cname.vercel-dns.com or a CDN endpoint. The benefit is indirection: when the provider changes the underlying IP, your record keeps working because it resolves through their name. A CNAME target must be a hostname, never an IP, and a node that has a CNAME cannot also carry other records for the same name (per RFC 1034). That single rule is the source of the most common DNS mistake, covered below.

MX: route inbound mail

An MX (mail exchanger) record tells the world where to deliver email for your domain. Each MX has a preference number (lower = higher priority) and a target hostname. Google Workspace, for example, now hands you a single host, smtp.google.com, with a priority. You can list several for failover; senders try the lowest number first. Crucially, MX only governs receiving mail. Your ability to send from the domain and not get filtered depends on the TXT-based records below. If you do not run mail on the domain at all, you can leave MX empty, but you should still publish a TXT/SPF record that says so (again, see gotchas).

TXT: verification, SPF, DKIM, DMARC

A TXT record holds arbitrary text and has become the universal place for machine-readable policy. The four jobs you will use it for:

• Domain verification — a service gives you a token string to publish so it can confirm you control the domain.
• SPF — one TXT record beginning v=spf1 listing who may send mail as you (RFC 7208).
• DKIM — a public key, published at a selector subdomain, used to sign outgoing mail.
• DMARC — a policy at _dmarc.yourdomain beginning v=DMARC1 telling receivers what to do with mail that fails SPF/DKIM.

Publish exactly one SPF TXT record per domain; two or more v=spf1 records on the same name cause a PermError and break SPF entirely (RFC 7208).

The gotchas that actually break setups

Most "DNS isn't working" tickets are one of these four, not a propagation problem.

1. Never CNAME the apex

Because a CNAME node cannot coexist with other records, and the apex (example.com) must carry NS and usually SOA and MX records, putting a real CNAME on the apex is illegal and will break mail and delegation. If a provider asks you to "CNAME your root domain," use your DNS host's flattening feature instead — Cloudflare calls it CNAME flattening, others call it ALIAS or ANAME. These return an A record at lookup time while letting you configure a hostname target.

2. MX must target a hostname, not an IP and not a CNAME

The MX value must be a real hostname that itself resolves via A/AAAA. Putting an IP address in an MX is invalid, and pointing MX at a name that is a CNAME is prohibited by RFC 2181 and rejected by many mail servers. Always create an A/AAAA for the mail host, then point MX at that hostname.

3. TXT 255-character chunking

A single TXT string is capped at 255 characters. Long DKIM keys exceed that, so a TXT record holds multiple 255-char strings that are concatenated on read. Most DNS panels chunk this automatically when you paste a long value; if yours does not, split the value into quoted 255-char segments yourself, or DKIM verification will fail.

4. Use -all on SPF for domains that never send

If a domain is not used for outbound email, publish v=spf1 -all. The -all is a hard fail telling receivers that no server is authorized to send as you, which blunts spoofing. Pair it with a strict DMARC policy (p=reject) for parked or app-only domains. On a domain that does send, prefer ~all (soft fail) until you are confident your sources are all listed.

Build it, then prove it propagated

Getting the syntax exactly right — trailing dots, priority fields, quoted TXT segments — is where copy-paste goes wrong. Assemble the record with the DNS record builder, which formats A, CNAME, MX, and TXT values the way registrar panels expect. After you save the change, do not refresh your browser and guess; query the authoritative answer with the DNS over HTTPS lookup tool to confirm the record resolves as intended before you move on. For the underlying concepts behind why any of this works, see what is DNS.

Keep this rule of thumb: IP goes in A/AAAA, a hostname goes in CNAME, mail goes in MX, and anything that is policy or proof goes in TXT. Get the record type right and most "DNS problems" never happen.

Frequently Asked Questions