# Comprehensive Guide to DNS CNAME Records > A DNS CNAME record aliases one hostname to another. Learn how CNAMEs work, when to use them, the apex-domain rule, and how they power DKIM setup. A DNS **CNAME record** (Canonical Name record) makes one hostname an alias for another. Instead of pointing at an IP address the way an [A record](/resources-post/what-is-a-dns-a-record-understanding-the-fundamentals) does, a CNAME points a name at *another name* — the "canonical" name — and the resolver follows that pointer to find the final address. It is the record you reach for when a provider says "create a CNAME pointing to `something.theirdomain.com`." ![Comprehensive Guide to DNS CNAME Records](/images/generated/comprehensive-guide-to-dns-cname-records.webp) ## The basics: canonical names and aliases A canonical name is the "real," primary name for a host. An alias is an alternate name that resolves to it. When a client looks up an alias, DNS returns the canonical name and then resolves *that* to an IP using an A or [AAAA record](/learning/what-is-an-aaaa-dns-record-quad-a-explained). CNAMEs never hold IP addresses themselves — they always defer to another name's address records. That indirection is the whole point: change the target once, and every alias pointing at it follows automatically. ## How a CNAME record resolves When a client requests a name that has a CNAME: 1. The resolver looks up the alias and receives the canonical name in return. 2. It then resolves the canonical name to an IPv4 address (A record) or IPv6 address (AAAA record). 3. The resolved IP is returned to the client, which opens its connection. Because the alias always resolves through the canonical name's address records, the two stay in sync. If the target's IP changes, every alias updates without you editing them one by one. ## Creating a DNS CNAME record ![Four-step card showing how to create a DNS CNAME record, from opening the DNS console to setting the TTL.](/images/figures/comprehensive-guide-to-dns-cname-records-fig1.webp) *The four steps to create a CNAME record in your DNS management console.* 1. **Open your DNS console** at your registrar or DNS host. 2. **Add a new record** and choose the **CNAME** type. 3. **Enter the alias and target** — the hostname you are creating (for example, `shop.example.com`) and the canonical name it should point to (for example, `stores.provider.net`). 4. **Set the TTL** to control how long resolvers cache the answer, then save. Confirm the record resolves with a [DNS lookup tool](/tools/dns-lookup) before you rely on it. ## What CNAME records are good for - **Aliasing subdomains onto a provider's host** — `www`, `shop`, or `status` pointing at a platform that manages the underlying servers for you. - **Content delivery networks** — pointing a subdomain at your CDN's hostname so the CDN can route users to the nearest edge. - **Vendor verification and email authentication** — many providers ask you to publish a CNAME so they can prove domain control or manage a rotating key on your behalf. - **Consolidating services** — mapping several friendly names onto one canonical host you maintain in a single place. ## CNAME vs A vs ALIAS ![Three-column comparison of CNAME, A, and Alias records showing what each points to and when to use it.](/images/figures/comprehensive-guide-to-dns-cname-records-fig2.webp) *Each record type serves a different purpose in the DNS infrastructure.* - An **[A record](/resources-post/what-is-a-dns-a-record-understanding-the-fundamentals)** points a name directly at an IPv4 address. Use it when you know the IP. - A **CNAME** points a name at another name. Use it to alias onto a hostname a provider controls. - An **ALIAS** (sometimes ANAME, or "CNAME flattening") behaves like a CNAME but is legal at the domain apex and resolves to the target's IPs server-side. Support and naming vary by DNS provider. ## How CNAME records power DKIM Email authentication is one of the most common reasons to publish a CNAME. When you enable [DKIM](/learning/what-is-dkim), many senders have you create CNAME records at `selector._domainkey.yourdomain.com` that point to a key the provider hosts. Microsoft 365, for example, has you publish two CNAMEs (`selector1._domainkey` and `selector2._domainkey`) that point into Microsoft's infrastructure, so Microsoft can rotate the underlying keys without you touching DNS again. The receiving server follows the CNAME to fetch the current public key and verifies the signature. You can confirm a published key with a [DKIM lookup](/tools/dkim). ## Common CNAME mistakes ### Putting a CNAME at the domain apex The root of your domain (`example.com` with no subdomain) already carries mandatory SOA and NS records, and a CNAME is not allowed to sit alongside other records. Publishing a CNAME at the apex breaks resolution. Use an A record — or your provider's ALIAS/flattening feature — at the apex instead. ### Adding an MX or TXT record on a CNAME'd name A hostname with a CNAME cannot also have MX, TXT, or any other record of the same name. If you need an [MX record](/learning/what-is-an-mx-record) or an [SPF TXT record](/learning/what-is-a-txt-record) on a name, that name cannot be a CNAME. This is a frequent cause of "my SPF/MX suddenly stopped working" after someone aliases a subdomain. ### Long CNAME chains A CNAME can point to another CNAME, but each hop adds a lookup and some resolvers cap the chain length. Keep chains short — ideally one hop to a canonical name that has real address records. ### Confusing a CNAME with an HTTP redirect A CNAME changes name resolution but keeps the URL the user sees. A 301 (permanent) or 302 (temporary) redirect operates at the HTTP layer and actually changes the URL in the browser. If you need the address bar to change, you need a redirect, not a CNAME. ## Frequently asked questions ### Can I use a CNAME for my root domain? No. The apex must carry SOA and NS records, and a CNAME cannot coexist with them. Providers work around this with ALIAS, ANAME, or CNAME-flattening records that are legal at the apex and resolve to the target's IP addresses behind the scenes. ### Does a CNAME slow down DNS resolution? Slightly — the resolver has to look up the alias and then the canonical name. One hop is negligible. Long chains of CNAMEs pointing to other CNAMEs add measurable latency and should be avoided. ### Can two CNAME records point to the same target? Yes. Many aliases can point to one canonical name, which is exactly why CNAMEs are useful: update the target's address once and every alias follows. ### Why did my email break after I added a CNAME? Almost certainly because you added the CNAME to a name that also needed MX or TXT records. DNS forbids a CNAME from sharing a name with other record types, so the MX/[SPF](/learning/what-is-spf) records on that name stop being honored. Move the alias to a different label, or use A/MX/TXT records on that name instead. ### How do I check what a CNAME resolves to? Use a [DNS lookup tool](/tools/dns-lookup) or run `dig shop.example.com CNAME`. Both show the canonical name the alias points to and let you trace the chain to a final address. ## Where Palisade fits CNAMEs are how many providers hand you DKIM keys and domain-verification tokens — and a single fat-fingered target quietly breaks authentication. Palisade watches your DNS for missing or malformed records and checks that DKIM, [SPF](/learning/what-is-spf), and [DMARC](/learning/what-is-dmarc) all line up. Start with a free [Email Security Score](/tools/email-security-score) to see where your domain stands. ## Related reading - [What is a DNS A record?](/resources-post/what-is-a-dns-a-record-understanding-the-fundamentals) - [What is DKIM?](/learning/what-is-dkim) - [What are DMARC, DKIM, and SPF?](/resources-post/what-are-dmarc-dkim-and-spf)