A CNAME record is an alias in DNS. Instead of giving a name its own address, it says "this name is another name for that one". It sounds simple, yet CNAME records account for a large share of failed domain setups: a verification that will not pass, a subdomain that stops working when you add one, an email authentication record that does not resolve or a dashboard that says the record "cannot coexist" with another. People search for what a CNAME record is, how it differs from an A record, how to create one for a subdomain, whether you can use one on the root domain and why it is not working. This guide answers each, with the rules that explain the errors, and shows where CNAME records appear in email setup: DKIM delegation, tracking domains and return-path domains. We use plain examples and never invent provider values; always copy the target from the service you are connecting.
What is a CNAME record?
CNAME stands for canonical name. A CNAME record maps one name, the alias, to another name, the canonical or target name. When a resolver looks up the alias, it finds the CNAME, then looks up the target and returns that answer. For example, if links.example.com is a CNAME to tracking.provider.example, any lookup for links.example.com follows the alias and returns the address of tracking.provider.example. The benefit is that the provider can move servers without asking you to change anything, because your record points to a name they control.
| Field | Meaning |
|---|---|
| Name (host) | The alias you are creating, such as links or em123 |
| Type | CNAME |
| Value (target) | The name it points to, supplied by the service |
| TTL | How long resolvers cache the answer |
CNAME vs A record
An A record maps a name to an IPv4 address (an AAAA record does the same for IPv6). A CNAME maps a name to another name. The difference affects when to use each.
| Question | A record | CNAME record |
|---|---|---|
| Points to | An IP address | Another hostname |
| Follows the target's changes | No; you must update the IP yourself | Yes; if the target's address changes, you follow automatically |
| Can coexist with other records at the same name | Yes | No |
| Allowed at the root domain | Yes | Not in standard DNS |
| Extra lookup | No | Yes, one more |
| Typical use | Your own server, root domain | Third-party services, subdomains, delegated records |
Use an A record when you control the server and know its address. Use a CNAME when a service gives you a hostname to point at.
The rules behind the common errors
1. A CNAME must be alone at its name
If mail.example.com is a CNAME, it cannot also have an MX, TXT or A record. DNS would not know which answer to give. This is the most common cause of "record conflicts" and "cannot add CNAME" messages. The fix is to delete the conflicting record or to use a different subdomain for the alias.
2. No CNAME on the root domain
The root, or apex, of a domain already carries required records (SOA and NS), and also usually MX and TXT for email. A CNAME there would conflict with all of them. If a service tells you to point your root domain at a hostname, you have three options: use an A record with the IP address the service gives you; use the www subdomain as a CNAME and redirect the root to it; or use a DNS host that offers an ALIAS, ANAME or flattened CNAME feature. Those are vendor-specific and not part of the standard, so check how your DNS host handles them. See DNS records for email explained for how this interacts with email records.
3. MX records must not point to a CNAME
An MX target should be a hostname with a direct address record, not an alias. See MX records explained.
4. Doubled domain names
Many control panels append your domain to whatever you type in the name field. If you enter links.example.com and the panel adds .example.com, the result is links.example.com.example.com. Enter only the part before the domain, or follow the panel's hint exactly. The same issue affects the target field in panels that expect a trailing dot for fully qualified names.
5. Proxying can hide the record
Some DNS hosts offer a proxy mode that answers with the proxy's address instead of the CNAME target. For records used for email, such as DKIM delegation, tracking and return-path domains, keep the record in DNS-only mode so that the real target is visible to the checks that need it.
How to create a CNAME record
- Get the exact name and target from the service you are connecting, such as a dashboard domain settings page. Do not guess.
- Open the DNS settings at your authoritative DNS host. If you are unsure who that is, check your domain's nameservers. See adding DNS records at common hosts.
- Add a new record of type CNAME. Enter the alias in the name field exactly as the service shows it. Adjust for your panel's habit of appending the domain.
- Enter the target in the value field. Do not add
http://or a path; it is a hostname. - Save and wait. Most changes appear within minutes, but caches can keep the old answer until the TTL expires. See TTL and propagation.
- Verify with a lookup.
How to check a CNAME record
dig CNAME links.example.com +short
nslookup -type=CNAME links.example.com
If you get no answer, either the record does not exist at that name or something else is at the same name. Query your authoritative nameserver directly to avoid cache confusion.
Where CNAMEs appear in email setup
- DKIM delegation. Some services ask you to publish a CNAME at a selector name, such as
selector._domainkey.example.com, pointing at a name the service controls. That lets the service rotate keys without asking you to edit DNS. See DKIM selectors and key rotation. - Tracking domains. A branded domain for click and open links is commonly a CNAME to the service's tracking host. See custom return-path and tracking domains.
- Return-path (bounce) domains. A subdomain used for bounce handling may be a CNAME to the provider so that SPF can align with your domain.
- Autodiscover and similar service records. Mailbox suites sometimes ask for CNAMEs so that mail apps configure themselves.
When a service asks for CNAMEs, it needs them exactly as shown in the dashboard. For ours, copy values from the domain settings in your dashboard and run the SPF, DKIM and DMARC checker afterwards. See also authenticating your sending domain.
Troubleshooting
| Problem | Cause | Fix |
|---|---|---|
| Panel says a record already exists | Another record type at the same name | Remove it or use another name |
| Verification fails | Name entered with the domain doubled, or wrong target | Look up the record and compare with the dashboard |
| Works for some people, not others | Cached older answer | Wait for the TTL; test from another resolver |
| Chain too long | CNAME pointing to a CNAME pointing to another | Point to the final target if you can |
| Root domain will not accept a CNAME | Standard rule | Use an A record, a www CNAME with a redirect, or your host's alias feature |
Quick answers
- A CNAME can point to a name outside your domain.
- A CNAME's target can be another CNAME, but long chains slow lookups and some tools reject them.
- Deleting a CNAME removes the alias immediately for new lookups, but cached copies can persist until the TTL expires.
Copy the exact records from your dashboard Domain settings show the CNAME and TXT values to publish; verify them with the free checker.
References and further reading
Frequently asked questions
What is a CNAME record?
A DNS record that makes one name an alias for another name. Resolvers follow the alias to the target and return the target's address.
What is the difference between an A record and a CNAME?
An A record maps a name to an IP address. A CNAME maps a name to another name, follows the target's changes and cannot share its name with other records.
Can I use a CNAME on my root domain?
Not in standard DNS, because the root carries other required records. Use an A record, a www CNAME with a redirect or your DNS host's ALIAS or flattening feature if it has one.
Why does my panel say the CNAME conflicts with another record?
A CNAME must be the only record at its name. Remove the conflicting MX, TXT or A record or choose a different subdomain.
Why is my CNAME not working?
Common causes are a doubled domain in the name, a wrong target, caching until the TTL expires, proxy mode on the record or another record at the same name.