CNAME record

A CNAME record points one web address at another web address instead of at a server. Ask for shop.yourbusiness.ph and the answer is not a number, it is another name, and your browser goes and asks about that one instead. The point is that the destination stays under somebody else’s control. When the platform behind it moves to a different server, your address follows without you touching anything.

In short

• A CNAME points a name at another name, not at a server address.
• It is how subdomains connect to platforms you do not run yourself.
• It cannot go on your bare domain, which is why providers offer a flattened alias instead.
• It is not a redirect, and visitors never see it happen.

What a CNAME record actually does

CNAME is short for canonical name. The record says that the name you asked about is an alias, and names the real one.

Take a shop running on a hosted platform. The platform gives you a hostname like shops.theplatform.com and tells you to point your own subdomain at it. You add a CNAME saying that shop.yourbusiness.ph is an alias for shops.theplatform.com. From then on, every visitor asking for your address is quietly handed the platform’s current server, whichever one that happens to be today.

That last part is the whole value. If you had written the platform’s server address into an A record instead, the day they moved servers your shop would stop working and nobody would have told you.

For the other record types you will meet alongside it, see DNS records.

Where you will actually meet one

You will add a CNAME rarely, and nearly always because a supplier asked you to.

• Connecting a subdomain to a platform. Shopify, Webflow, a booking system, a help desk, a learning portal. Each gives you a hostname and asks for an alias.
• Verifying that you own the domain. A service gives you a unique name and destination, then checks the record exists before it will act for you.
• Email sending services. Newsletter and transactional mail providers use CNAMEs so their signing keys can be rotated without asking you again.
• Getting an SSL certificate issued. The check itself is usually a text record, but hosts often have you point _acme-challenge at them with a CNAME so they can renew without asking you again.
• Pointing www at your main site. The oldest use of all, and still common.

In every case somebody hands you two strings and you paste them into two fields. The value of understanding the record is knowing what breaks if it is removed.

The rule that catches everybody

You cannot put a CNAME on your bare domain. Not yourbusiness.ph on its own, only something in front of it.

The reason is a rule as old as the system. A name that has a CNAME is not allowed to have any other record, because the alias is supposed to answer every question about that name. Your bare domain has to carry other records: the nameservers that make it work at all, and the MX records that receive your mail. Those cannot coexist with an alias, so the alias is not permitted.

This collides directly with the modern habit of running a site on a platform that only gives out hostnames. DNS providers solved it with a workaround, usually called ALIAS, ANAME or CNAME flattening. It behaves like a CNAME when you set it up, but the provider follows the alias themselves and hands out a plain address, so the rule is never broken.

If your provider does not offer one, the fallback is to run the real site on the www version and redirect the bare domain to it.

CNAME and your email

Two things to get right, and both fail quietly rather than loudly.

Mail records must never point at an alias. An MX record has to name a host with its own address record. Pointing it at a CNAME produces delivery that works for some senders and fails for others, which is far worse to diagnose than a clean failure.

The authentication records are the opposite case. Most email providers now hand out CNAMEs for the signing keys, precisely so they can change the underlying keys without contacting every customer. Those records look like noise in the list. Delete one during a tidy up and your mail starts landing in spam a week later, with nothing to connect the two events. Whoever runs your email hosting should be able to tell you what every one of those records is for.

Subdomains, tracking and first-party data

There is one use of CNAMEs that comes up in marketing rather than in plumbing.

Scripts loaded from an outside domain are treated with suspicion by browsers, and the cookies they set are cut short or blocked. Serving the same thing from data.yourbusiness.ph, aliased to the provider, makes it a first-party request and extends the life of what it stores. That is the reasoning behind a good deal of tracking setup work.

It is worth knowing that browsers have narrowed what this achieves. Safari in particular detects the arrangement and applies a short limit to the cookies anyway. It still helps, it no longer solves the problem outright, and anybody selling it as a complete answer to browser restrictions is overselling it.

Reading one that is not working

A CNAME either exists or it does not, which makes the fault list short.

• The record was added at the wrong company. Records live wherever the nameservers point, not necessarily at your registrar.
• The name was entered twice. Some panels want only the part in front, some want the whole thing. Entering shop.yourbusiness.ph in a field that already appends the domain produces a name nobody will ever ask for.
• A trailing dot is missing or extra. Some panels are strict about it.
• It is still cached. If a record existed before, the old answer survives until its TTL runs out.
• The certificate has not been issued yet. The record is right, the padlock is late. Wait rather than change anything.

Before you add one

1. Find out where your records actually live. Check the nameservers first.
2. Paste both values exactly as given, including anything that looks like noise. It is not noise.
3. Never point a mail record at an alias.
4. Leave verification records in place once the setup is finished, because many services recheck them.
5. Write down what each one is for. Your future self, or whoever maintains the hosting after you, will not be able to work it out from the record alone.