What is a CNAME record? (and why not at your apex)

A CNAME record is a forwarding address for DNS: it points one name at another. It is how your email vendors manage your DKIM keys, and the one record you must never put at your domain root.

The one-sentence version

A CNAME (canonical name) record is an alias: it says “this name is really just another name for that one.” When a resolver hits a CNAME, it follows the pointer and looks up the records at the target instead.

www.example.com.    3600   IN   CNAME   example.com.
shop.example.com.   3600   IN   CNAME   stores.myshopify.com.

Ask for www.example.com and the resolver sees the CNAME, then continues the lookup at example.com and returns its address. The alias and its target can live in completely different domains, which is exactly what makes CNAMEs useful for pointing your names at someone else's service.

The one rule that explains everything

Almost every CNAME gotcha comes from a single rule: a name that has a CNAME record cannot have any other record at the same name. No A, no MX, no TXT alongside it. The DNS clarifications standard (RFC 2181) is explicit that a CNAME's name may carry no other data (bar a couple of DNSSEC signing records). The reason is integrity: an alias and its canonical name must resolve to the same thing, so the alias is not allowed to also hold its own competing answers.

Why you cannot CNAME your apex

This rule is why you cannot put a CNAME on your bare domain. Your apex (example.com with nothing in front) must always carry its SOA record and its NS records. A CNAME is not allowed to coexist with those, so the apex stays an A or AAAA record.

Because so many people want a root domain to point at a host, DNS providers invented workarounds: Route 53 calls it an ALIAS record, some hosts call it ANAME, and Cloudflare calls it CNAME flattening. None of these is a real DNS record type in any standard. They are server-side tricks: the provider follows the alias for you and answers the query with a normal A or AAAA address, so what goes out on the wire is always RFC-legal. They are genuinely useful, just know that they are your provider doing the work, not a CNAME at the apex.

MX and NS must never point to a CNAME

The mirror image of the apex rule: the hostname an MX or NS record points to must be a real name with its own address record, never a CNAME. RFC 2181 spells this out. The practical failure is quiet: when a mail server resolves an MX whose target is a CNAME, the address it needs is not returned, and delivery breaks. As with the apex, it sometimes appears to work on lenient resolvers, which is what makes it dangerous.

How CNAMEs run your email authentication

Here is where CNAMEs become an everyday part of email. Most email service providers set up DKIM through CNAME delegation: instead of pasting a public key into your DNS, you publish a CNAME at <selector>._domainkey.yourdomain that points to a key the provider hosts. Because they hold the key, they can rotate it without you ever touching DNS again.

s1._domainkey.example.com.   IN   CNAME   s1.domainkey.u123.wl.sendgrid.net.
s2._domainkey.example.com.   IN   CNAME   s2.domainkey.u123.wl.sendgrid.net.

SendGrid, Mailchimp, HubSpot, and most major senders work this way (a few, such as Amazon SES with Easy DKIM, use TXT records instead, so “most” is the honest word, not “every”). Providers also use a CNAME for a custom Return-Path or bounce subdomain. That CNAME points the subdomain at the provider, who then publishes the SPF for it; aligning that bounce subdomain under your own domain is what lets SPF contribute to a DMARC pass. Our SendGrid setup guide walks a real example end to end.

The apex CNAME trap

If you take one warning from this page: never force a CNAME onto your apex. The danger is not just that it is disallowed, it is that a correctly-behaving server will then serve only the CNAME and drop your SOA, NS, and MX. The result is your mail stops and your zone can go lame, with no obvious cause. Use an A record or your provider's ALIAS or flattening option instead.

Common questions

Can I use a CNAME record at my domain root?

Not a real one. The apex must hold SOA and NS records, which a CNAME cannot coexist with. Use an A or AAAA record, or your provider's ALIAS / ANAME / CNAME-flattening feature, which resolves to an address record behind the scenes.

Why does my email provider ask me to add a CNAME for DKIM?

So they can host and rotate your DKIM key without you editing DNS again. You publish a CNAME at the selector; it points to a key on their servers. It is the standard way most senders handle DKIM, and it is why a vendor can renew a key silently.

What is the difference between a CNAME and an A record?

An A record points a name straight at an IP address. A CNAME points a name at another name, and the resolver then looks that name up. Use an A record when you know the IP; use a CNAME when you want to follow whatever address a service uses, without tracking its IPs yourself.

Keep reading

Last verified 2026-06-23 against RFC 2181 section 10, clarifications on CNAME, MX, and NS records.

Stop guessing. Start monitoring.

Free for one domain. Set up in five minutes. We parse the reports; you read plain-English summaries.