CNAME Records: Aliases That Point One Name at Another
Domain names are a system of pointers, and the CNAME record is one of its most useful pointers. CNAME stands for canonical name, and a CNAME record says that one name is an alias for another name: whenever anyone looks up the alias, they should follow the pointer and use the target name instead. This is how a subdomain such as blog.example.com can point at a hosting platform's name without anyone needing to know or maintain the platform's numeric addresses. The CNAME Lookup validates the format of CNAME records that you paste in. It does not run a live DNS lookup, so it cannot tell you what is actually published for a name; it can only confirm whether the lines you pasted are well formed and what they mean.
How it works
The distinction between a CNAME and an address record is the key to using it correctly. An A record maps a name directly to a numeric IPv4 address, and an AAAA record maps a name to an IPv6 address. A CNAME maps a name to another name, and the lookup then continues with that target name, which may itself have address records or even another CNAME. This indirection is the source of both its power and its pitfalls. It is powerful because the target's addresses can change without any change to the alias: if a hosting provider moves its servers, every alias pointing at its name follows automatically. It is a pitfall because every extra hop adds a lookup, and a chain of aliases that loops back on itself, or that never ends at an address, breaks resolution entirely.
Where it goes wrong
The strictest rule about CNAME records is that a CNAME cannot share its name with any other record, with one narrow exception for certain signing records. In practical terms, this means a name that has a CNAME cannot also have its own A record, its own mail records, or its own text records, because the alias is supposed to stand in for the target's records entirely. This is why a CNAME is not normally used at the apex of a domain, the bare domain itself, where mail and other records usually live: placing a CNAME there would conflict with them. Providers offer alias-like features for apex names, but those are provider-specific mechanisms, not ordinary CNAME records, and confusing the two is a common source of failed setups.
Worked example
Worked example with sample values. Suppose you paste these 2 sample lines: blog.example.com. CNAME hosting.example.net. and shop.example.com. CNAME stores.example.net.. Counting gives 2 records, each with one alias name and one target name, so 2 aliases and 2 targets in total. In the first record, a lookup for the alias blog.example.com follows the pointer to hosting.example.net, which must then resolve to an address for the chain to succeed. If the target itself were another alias, the chain would have 2 hops before reaching an address, and each hop adds a lookup step. If a third sample line added a mail record on blog.example.com, the set would violate the exclusivity rule, because 1 name would then carry 2 record types, and the CNAME would be in conflict. The sample names here are illustrative, not live DNS data.
Mistakes to avoid
Common mistakes cluster around the same themes. The first is pointing a CNAME at an address instead of a name, which is a type error: a CNAME target must be a domain name, and an address belongs in an A or AAAA record. The second is a trailing-dot confusion: in zone file notation a name ending in a dot is absolute, while a name without a dot may be treated as relative to the zone, so the same text can mean different targets in different contexts. The third is a chain that is too long or that loops, which usually arises when aliases are copied between providers without tracing the full path. The fourth is placing a CNAME at an apex and then wondering why mail stops working, which is the exclusivity rule asserting itself.
Putting it into practice
Use the checker to validate a draft before publishing it. Paste the record lines, confirm that each target is a name rather than an address, and confirm that no name in the set carries a second record type. Then trace each chain mentally to an address, counting the hops, and check that no chain loops. After publishing, confirm the live records separately, since the checker validates text rather than live DNS. A well-formed CNAME is a small thing, but it is the kind of small thing that quietly holds a website, a blog or a store together, and a few minutes of validation can save a confusing outage later.
Related tools and reading: the DNS Lookup and the SPF Checker cover neighbouring checks that pair naturally with this one, and the guide at [/blog/website-seo-audit-guide/] extends the same topic with further background and examples for readers who want to go deeper.
Key points
- Target is a domain name, never a numeric address
- No other record type shares the alias name
- Chain traced hop by hop to a real address
- No loops and no excessively long chains
- Live records confirmed separately after publishing
In short: A CNAME maps one name to another name, not to an address. The checker validates the format of pasted CNAME records. A CNAME cannot coexist with other records on the same name. Chains of aliases must eventually end at a real address.
One habit ties all of this together: re-check after every change. A result from the CNAME Lookup is only as current as the text it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.