CNAME Record

A CNAME record is a DNS entry that points one hostname to another hostname instead of to an IP address. CNAME stands for Canonical Name, and the record tells resolvers that the name being queried is an alias for the canonical name given as its value. It exists so that several hostnames can follow one target without repeating and maintaining that target’s IP addresses.

How a CNAME Record Works

A resolver that hits a CNAME restarts the lookup at the new name. The alias itself never carries an IP address.

go.example.com.    3600    IN    CNAME    cname.linkutm.com.

Left to right: the hostname, a TTL of 3600 seconds, the internet class, the record type, and the canonical name. The trailing dot marks a fully qualified name. Most DNS dashboards add it for you and ask only for the host (go) and the value.

Resolution runs in two stages:

1. A visitor requests go.example.com. The resolver finds the CNAME and learns the real name is cname.linkutm.com.
2. The resolver queries that name, gets its A or AAAA record, and connects to the returned IP.

The practical benefit is that the target’s IP can change without touching your zone. If the platform behind cname.linkutm.com moves servers, every alias pointing at it follows automatically.

CNAME vs A Record

An A record points a hostname to an IPv4 address. A CNAME points a hostname to another hostname.

Aspect	CNAME record	A record
Value	A hostname (cname.linkutm.com)	An IPv4 address (203.0.113.10)
IPv6 equivalent	Same record handles both	AAAA record, added separately
Allowed at root domain	No	Yes
Coexists with other records at the same name	No	Yes
Maintenance when the target IP changes	None	Manual update
Lookup cost	One extra query per hop	Direct

Use an A record when you control the server and know its IP. Use a CNAME when a third-party platform hosts the service and manages its own addresses.

Why a CNAME Cannot Sit at a Root Domain

RFC 1034 states that if a CNAME record exists at a name, no other data may exist there. A root domain (the apex, example.com with no subdomain) always carries SOA and NS records, so a CNAME at that name conflicts with the standard and breaks resolution.

Three ways around it:

• ALIAS or ANAME records. Route 53, DNSimple, and others offer a virtual record that behaves like a CNAME at the apex and returns an IP in the answer.
• CNAME flattening. Cloudflare resolves the target at the edge and serves the resulting A record for the apex.
• Redirect from the apex. Point example.com at a redirect service and put the CNAME on www or another subdomain.

Related rule from RFC 2181: the value of an MX or NS record must not be an alias. Pointing mail routing at a CNAME causes intermittent delivery failures that are difficult to diagnose.

How to Add a CNAME Record

The flow is the same at every registrar and DNS host.

1. Open the DNS or zone editor for the domain at whichever provider answers for it. That is the nameserver in charge, which is often not the registrar.
2. Create a record of type CNAME.
3. Enter the host or name field: just the subdomain label, such as go, not the full hostname. Some providers want the full name instead.
4. Enter the value or target exactly as the platform supplies it, including the trailing dot if the field expects one.
5. Set the TTL. Use 300 seconds while testing, then raise it to 3600 once the record works.
6. Save, then confirm from the command line.

dig CNAME go.example.com +short
nslookup -type=CNAME go.example.com

A correct record returns the target hostname. Changes usually resolve in minutes, though caches holding the previous answer can take up to 48 hours to expire.

Common Uses for a CNAME Record

• Custom domains on a SaaS platform. Link shorteners, help desks, and status pages all verify ownership through a CNAME. Setting up a custom domain for branded short links is the most common marketing case: go.yourbrand.com aliases the link platform, which then issues the SSL certificate.
• CDN routing. assets.example.com points to the CDN’s edge hostname.
• Email authentication. Klaviyo, SendGrid, and Mailchimp hand over DKIM and tracking CNAMEs so mail signs under your domain.
• Certificate validation. A _acme-challenge CNAME delegates proof of ownership so certificates renew without manual steps.
• Domain verification. Google Search Console and many SaaS tools accept a CNAME as proof of control.
• www to apex. A CNAME on www pointing to the root domain keeps both versions serving the same site.

Common CNAME Record Mistakes

• Adding a CNAME at the apex, or alongside an existing A, MX, or TXT record at the same name. Both break the zone.
• Entering the full hostname in a host field that expects only the label, which creates go.example.com.example.com.
• Chaining aliases across several providers. Each hop adds a query, and resolvers cap chain depth.
• Treating a CNAME as a redirect. It resolves a name and never changes the address in the browser.
• Leaving a stale CNAME after cancelling a service, which lets someone else claim the target and serve content on your subdomain.
• Expecting an SEO effect. A CNAME is invisible to crawlers, which see only the site that answers. A subdomain still counts as a separate host regardless of how it resolves.

Frequently Asked Questions

What is a CNAME record?

A CNAME record is a DNS record that makes one hostname an alias for another. It stores a hostname as its value, never an IP address, so the resolver looks up the target next and uses whatever address that name returns. CNAME stands for Canonical Name, defined in RFC 1034 in 1987. Its main use today is pointing a subdomain you own at a service someone else operates.

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

An A record maps a hostname directly to an IPv4 address, while a CNAME maps it to another hostname. The A record answers in one step and is required at the root domain. The CNAME adds a lookup but removes maintenance, since the target owner manages the underlying IPs. Use an A record for a server you run and a CNAME for a hosted platform.

How do I add a CNAME record for a custom domain?

Create the record at the DNS provider that answers for your domain, with the subdomain as the host and the platform’s hostname as the value. Most link platforms display the exact target to paste. Verify with dig CNAME yourhost.example.com +short, then complete verification inside the platform so it can issue an SSL certificate. Expect the whole process to take under an hour.

Why is my CNAME record not working?

The usual causes are a conflicting record at the same name, an apex CNAME, a mistyped host field that doubled the domain, or DNS still served by an old nameserver. Check which nameservers answer for the domain before debugging the record itself. If the record resolves correctly with dig but the site does not load, the problem is on the platform side, usually pending SSL provisioning.

Point a branded subdomain at your links with linkutm’s branded domains and the CNAME is the only DNS change you need.