Quick answer
A CNAME (Canonical NAME) record makes one name an alias for another. When a resolver looks up a name that holds a CNAME, it reads the target name from the record and continues resolution there, following the alias to wherever the real records live (RFC 1035 §3.3.1). The one rule that trips people up: a name that has a CNAME may have no other records of any type (RFC 1034 §3.6.2), which is why you cannot put a CNAME at the apex of a zone and cannot pair a CNAME with a TXT or MX record at the same name.
How a CNAME works
A CNAME record maps an alias name to a single canonical target name. A typical entry looks like this:
www.example.com. 3600 IN CNAME example.com.
When a resolver is asked for the address of www.example.com, it finds the CNAME, sees that the canonical name is example.com, and restarts the query against example.com. It reads the A or AAAA records there and returns those addresses. The client that asked for www.example.com gets an answer that contains both the CNAME and the address records it pointed to.
The value stored in a CNAME is a domain name, not an address and not a URL. It carries no path or port. It says only "for this name, go look at that name instead." Because the resolver switches to the target and takes whatever record type it needs from there, one CNAME can serve an A lookup, an AAAA lookup, and a TXT lookup all at once. That is what makes CNAME useful for pointing a hostname at a provider whose IP addresses you do not control and do not want to hard-code.
CNAME vs A record
This is the distinction worth getting right. An A record holds an IP address; a CNAME holds a target name.
An A record is the end of the chain. example.com IN A 203.0.113.10 says the name resolves to 203.0.113.10, and resolution stops. If that IP ever changes, you edit the A record.
A CNAME is a redirection. www.example.com IN CNAME example.com says "resolve example.com and use its answer." You are not committing to any IP; you are delegating that decision to the target name's records. If the target's A record changes, your alias follows automatically because it never held an address in the first place.
Use an A record when you know the address and want the name to point straight at it. Use a CNAME when you want a name to track another name's records, which is common for pointing a subdomain at a hosting provider, a CDN endpoint, or a SaaS vendor that manages the underlying addresses for you. For a fuller treatment of the address side, see the A record page.
The one-record restriction
The defining constraint on CNAME comes from RFC 1034 §3.6.2: if a name has a CNAME record, it may not have any other records. No second CNAME, no A, no TXT, no MX at that same name. The reason is that a CNAME redirects the entire name to its target, so any other record sitting alongside it would be ambiguous — the resolver is already being told to go look elsewhere.
Two practical consequences follow.
First, you cannot put a CNAME at the zone apex (the bare domain, example.com, with no host label in front). The apex is required to carry an SOA record and NS records for the zone to exist at all. Those records must coexist with anything else at the apex, and the CNAME rule forbids coexistence. So example.com IN CNAME something.example.net is invalid. DNS providers work around this with a synthetic record type, usually called ALIAS or ANAME, which behaves like a CNAME at the apex but is resolved by the provider's own nameservers into plain A/AAAA answers before they leave the zone. The apex keeps real address records in the wire response, so the RFC rule is not violated.
Second, you cannot add a CNAME to a name that already publishes other records. If mail.example.com already has an MX record or a domain-verification TXT record, you cannot also make it a CNAME. You have to choose one shape for that name. This surprises people who try to alias a name that is already carrying authentication records.
CNAME targets and chains
Two more rules keep CNAME usage sane.
MX and NS records should not point at a name that is itself a CNAME. RFC 2181 §10.3 states that the target of an MX or NS record must be a name with an address record, not an alias. Some mail and DNS software tolerates a CNAME target, but plenty does not, and the standard tells you not to rely on it. Point your MX at a real hostname with A/AAAA records; an MX record checker shows what a domain's MX currently resolves to.
A CNAME may point to another CNAME, forming a chain. This is legal, and resolvers will follow it, but each hop is another lookup and another cache entry that can go stale independently. Long chains slow resolution and give you more places for something to break. Keep chains short — ideally an alias points straight at a name that has real address records, with no intermediate hops.
If you are troubleshooting a name that resolves to the wrong place, check whether it is a CNAME and trace the target; the answer you want may live one or two names away. For the record type used to hold arbitrary text like verification strings and SPF policy, see the TXT record page, and for how all these types fit together see DNS record types.