Point Your Bare Domain to a Host: CNAME, A or ALIAS?

For a bare domain like example.com, use a plain A record (plus AAAA if your host gives you an IPv6 address). A standard CNAME is only safe on the bare domain if your DNS provider flattens it, the way Cloudflare does. Everywhere else, keep CNAME records for names like www.

This rule is easy to break by accident. RFC 1912, one of the old operational guides for DNS, says it plainly: "A CNAME record is not allowed to coexist with any other data." Your bare domain already holds other data: the NS records that say which servers answer for your zone, and usually the MX records that tell the world where your email goes. RFC 1912 warns that a CNAME there makes the NS entries ignored, and mail is put at risk too.

By the end of this guide you will be able to check what your bare domain points to right now, pick the right record type, and make the change safely in cPanel's Zone Editor, Cloudflare or a plain registrar DNS panel.

What a CNAME actually is

A CNAME record (canonical name) is a forwarding note. It says "this name is really that other name, go and ask about that one instead."

Think of a mail forwarding card at the post office. Once you file it, everything addressed to your old flat goes to the new one. You cannot say "forward the letters but keep the parcels here."

DNS treats a CNAME the same way. Resolvers (the servers that look up names for browsers and mail servers) follow it for every question about that name, which is why nothing else may sit beside it.

An A record is different. It is a direct answer: "this name lives at 203.0.113.25." An AAAA record does the same for an IPv6 address such as 2001:db8::10. Neither one stops other records from living at the same name.

The bare domain, also called the zone apex or root, is the top of your zone: example.com with nothing in front. The www in www.example.com is a separate name, and a CNAME there is fine. RFC 1912 even calls CNAME records "useful (and encouraged)" for generic service names like www and ftp.

Why this matters

Here is what RFC 1912 says happens when you combine a CNAME with NS records: DNS servers like BIND "will see the CNAME and refuse to add any other resources for that name." Since nothing may coexist with a CNAME, "the NS entries are ignored," and the hosts in the domain are ignored as well.

The same section covers the mail side. It says not to use CNAME records in combination with records that point to other names, such as MX, and your email lives on the MX records at the bare domain. RFC 1912 also says MX records must not point to a name that is itself a CNAME.

Made-up example: Sam runs a small online shop on example.com. A site builder tells Sam to "point the domain" to shop-target.example.net, so Sam adds a CNAME for the bare domain. The site loads the next morning, but mail to orders@example.com starts bouncing. Nothing was hacked. One record type was wrong.

Why this matters: the symptoms can show up hours later, after caches expire, so the outage rarely gets linked to the change.

Before you start

Run through this checklist before you touch anything.

• You can log in to the place that actually hosts your DNS. That is wherever your nameservers point, which might be your host's cPanel, Cloudflare or your registrar. Step 1 below shows how to check.
• You have a copy of your current records. In Cloudflare, go to the DNS Records page, select Import and Export, then Export to download a zone file. In cPanel's Zone Editor, click Manage for the domain and take screenshots of the full record list, scrolling until you have every row.
• You know what your host gave you: an IP address such as 203.0.113.25, a hostname such as shop-target.example.net, or both.
• You have 30 minutes at a quiet time of day, because a mistake here hits the website and email together.
• You know your current TTL (time to live, the number of seconds resolvers may cache an answer). Old answers can stick around for that long after you change a record. If you are planning a move, lowering it first helps, and our guide on lowering TTL before a hosting move walks through it.

Heads up: in cPanel, do not use Reset DNS Zone as a quick undo. cPanel's own docs warn that it "erases any modifications that you made to your zone records," keeping only an attempt to save TXT entries.

Diagnose what your bare domain has today

These checks use dig, the DNS lookup tool from the BIND project, run from a terminal. Replace example.com with your own domain.

Step 1: Find out who answers for your domain

Run this to see your domain's nameservers.

dig NS example.com +short

You should see two or more hostnames. The values below are made-up examples.

ns1.example.net.
ns2.example.net.

These names tell you where to make changes: Cloudflare, your host's cPanel or your registrar's DNS panel. If you see nothing at all, stop and talk to your host before changing anything.

Step 2: Check the address and look for a CNAME

Run this to see the full answer for the bare domain. If you give dig no record type, it looks up an A record.

dig +noall +answer example.com

A healthy answer is an A record with an IP address, like this made-up line.

example.com.    3600    IN    A    203.0.113.25

If the first line shows CNAME instead of A, your bare domain has a CNAME. Confirm it directly.

dig CNAME example.com +short

Any output here means there is a CNAME on the bare domain as resolvers see it. Empty output is what you want. On Cloudflare, check the dashboard as well, because Cloudflare's docs say flattening returns the final IP instead of the CNAME (more on that below).

Step 3: Check your email records

Run this to see where mail for the domain is delivered.

dig MX example.com +short

You should see one or more lines with a priority number and a hostname, such as this made-up example.

10 mail.example.com.

If this comes back empty and you know you receive email at this domain, treat it as an emergency: the MX records are missing or being hidden. Also check that the mail hostname itself is not a CNAME, since RFC 1912 says MX records shall not point to one.

dig CNAME mail.example.com +short

Empty output is the good result.

Step 4: Save the evidence

Run this to keep a plain text record of what you found, so you can compare later.

dig +noall +answer example.com NS example.com A example.com MX > dns-before.txt

Keep dns-before.txt with your screenshots or exported zone file.

Decide which record you need

Work down this list and stop at the first line that matches you.

• Your host gave you an IP address: use an A record on the bare domain, plus an AAAA record if they also gave you an IPv6 address.
• Your host gave you only a hostname, and your DNS is on Cloudflare: a CNAME on the bare domain is fine, because Cloudflare flattens it.
• Your host gave you only a hostname, and your DNS is in cPanel or a registrar panel: ask the host for an IP address to use in an A record. If they cannot give you one, consider moving your DNS to a provider that flattens apex CNAME records.
• You are setting up www: a CNAME from www.example.com to the bare domain or to the host's hostname is the normal choice.
• You are tempted by the ALIAS option in cPanel: skip it. See the cPanel section for why.

Quick tip: when your host lists an IP, ask whether that address is stable. If it might change, a flattened CNAME on Cloudflare saves you from updating it by hand.

Fix it in cPanel Zone Editor

Open the Zone Editor in cPanel. Its exact location and label depend on your cPanel theme, and cPanel's docs note that your host can enable or disable the interface in WHM's Feature Manager, so if you cannot find it, ask your host.

Step 1: Open the zone for your domain

Find your domain in the Zone Editor list and click Manage. You will see a table with Name, TTL, Type, Record and Actions columns.

What you should see: every record for the domain, including the NS and MX rows at example.com.. Take your screenshots now if you have not already.

Step 2: Remove the CNAME on the bare domain

Find the row where Name is example.com. and Type is CNAME. Click Delete next to it, then Continue in the confirmation box.

What you should see: the row disappears, and the NS and MX rows for example.com. are still there.

Heads up: do this right before Step 3, not hours earlier. Between the two steps your bare domain has no address.

Step 3: Add the A record

Click Add Record (or use the arrow next to it to pick the type), choose A, and fill in the values below. cPanel's docs show full names written with a trailing dot, such as prefix.example.com., so use the same style for the bare domain.

Name:    example.com.
Type:    A
Address: 203.0.113.25

Click Save Record. If your host gave you an IPv6 address, add a second record the same way.

Name:    example.com.
Type:    AAAA
Address: 2001:db8::10

What you should see: a new A row (and AAAA row if you added one) for example.com., sitting alongside the untouched NS and MX rows.

Step 4: Point www with a CNAME

Check whether www.example.com. already has a record. If it does not, add a CNAME. cPanel requires the target to be a full hostname, and its docs state you cannot point a CNAME at an IP address.

Name:   www.example.com.
Type:   CNAME
Record: example.com.

Click Save Record. What you should see: one CNAME row for www.example.com. and no other record types on that same name.

About the ALIAS record in cPanel

You may see ALIAS in the record type list. cPanel's documentation says it is only available on systems running PowerDNS, is experimental, is not RFC-compliant, and "may cause unexpected behavior," including security issues, breaking DNSSEC and site inaccessibility. cPanel strongly recommends against using it, and so do we.

Some record types only appear if your host has enabled them in WHM's Feature Manager, which can explain a missing record type.

Fix it in Cloudflare

Cloudflare handles this case for you through CNAME flattening. When a resolver asks for your bare domain, Cloudflare follows the CNAME chain itself and returns the final IP address instead of the CNAME. Cloudflare's docs say flattening happens by default on all plans when the record Name is @.

Step 1: Export your records

Go to the DNS Records page, select Import and Export, then select Export. Save the file somewhere safe.

What you should see: a downloaded text file in BIND zone file format listing every record.

Step 2: Pick a CNAME or an A record for @

If your host gave you a hostname, add or edit the record for @ as a CNAME pointing at that hostname.

Name:   @
Type:   CNAME
Target: shop-target.example.net

If your host gave you an IP, an A record works just as well.

Name:    @
Type:    A
Address: 203.0.113.25

Select Save. What you should see: one record for @ with the type you chose, and your MX and other records still listed.

Heads up: if a record you saved seems to be ignored, our guide to fixing shadowed DNS records in Cloudflare is the next place to look.

Step 3: Leave the extra flattening settings alone unless you need them

On the DNS Settings page, paid zones have an option called CNAME flattening for all CNAME records. Paid zones can also flatten single records with a Flatten toggle when editing them. You do not need either for the bare domain. Cloudflare's docs note that the per-record Flatten option is not available at the apex, and that proxied records are flattened already.

Why this matters: Cloudflare warns that flattening all CNAME records can make third-party domain verification fail, because the CNAME itself is no longer returned. Many services verify ownership with exactly such a record.

Variants

The same goal looks a little different depending on where your DNS lives.

cPanel Zone Editor

Use A and AAAA records on example.com., a CNAME on www.example.com., and no ALIAS. A CNAME target must be a hostname, never an IP.

Cloudflare

Use @ as the name. A CNAME or an A record both work at the apex, since flattening is on by default for every plan.

A generic registrar DNS panel

Panels differ too much to name their buttons, so think in record types. On the bare domain, keep the NS and MX records and add an A record (and AAAA for IPv6) with your host's IP. On www, add a CNAME. If the panel offers an alias-style record for the root, read that provider's own documentation before trusting it.

Quick tip: look at how your existing MX rows name the bare domain and copy that convention.

How to check it worked

Give resolvers time to drop the old answer. The wait is up to the TTL of the record you replaced.

Check DNS with dig

Run this to confirm the bare domain now returns an address.

dig +noall +answer example.com

You should see an A line with your host's IP, and no CNAME line, as in this made-up example. On Cloudflare you will see an A answer even if you saved a CNAME, because flattening returns the final IP.

example.com.    300     IN    A    203.0.113.25

Run this to confirm your nameservers and mail records are intact.

dig NS example.com +short
dig MX example.com +short

Both should match what you saved in dns-before.txt. Finally, compare the whole picture with your earlier file.

dig +noall +answer example.com NS example.com A example.com MX > dns-after.txt
diff dns-before.txt dns-after.txt

The only difference should be on the address lines.

Check the website in a browser

Open a private browser window and visit http://example.com and https://example.com, then the same with www. You should see your site on all four without certificate warnings.

Check email

Send a message from an outside account on a different provider to an address at your domain, then reply from your domain's mailbox. Both should arrive. If your site and email share the same cPanel account, our guide to routing WordPress email on the same domain in cPanel covers the mail side in more depth.

Troubleshooting

• Symptom: the Zone Editor or registrar panel will not save your new A record for the bare domain. Likely cause: a CNAME still exists on that name, and RFC 1912 says no other data may coexist with it. Fix: delete the bare domain CNAME first, then add the A record straight away.
• Symptom: the site works but email to your domain bounces, and dig MX example.com +short returns nothing. Possible cause: a CNAME on the bare domain conflicts with the MX records, or they were deleted in the same edit. Fix: remove the CNAME, add an A record, and restore the MX records from your screenshots or export.
• Symptom: dig NS example.com +short returns nothing. Possible cause: a CNAME at the apex, which RFC 1912 says makes the NS entries and the hosts in the domain ignored. Fix: replace the CNAME with an A record, then ask your host or registrar to confirm the delegation is healthy.
• Symptom: on Cloudflare, visitors see Error 1014. Cause: your CNAME points to a hostname in a different Cloudflare account, which Cloudflare names "CNAME Cross-User Banned." Fix: ask the service you are pointing to for an IP address or their supported setup, or use an A record.
• Symptom: on Cloudflare, dig example.com returns no answer at all and it feels like the change is "still propagating." Cause: the CNAME target has no A or AAAA records, so flattening has nothing to return and gives an empty response (NODATA). Fix: check the target with dig shop-target.example.net +short and correct or replace it. Our guide on cleaning up dangling DNS records explains why a target that no longer exists is also a security risk.
• Symptom: a third-party service suddenly says it can no longer verify your domain. Cause: CNAME flattening for all CNAME records was turned on, so the verification CNAME is no longer returned. Fix: turn that option off on the DNS Settings page.
• Symptom: dig shows the new IP but your browser still shows the old site. Cause: cached DNS on your computer or network, within the old TTL. Fix: wait out the TTL, try a private window or another network, then check again.

Security notes and when to ask your host

A bare domain CNAME pointing at a service you have stopped using is a loose end. RFC 1912 tells you to delete CNAME records whose target is gone, and an unclaimed target is something an attacker might take over.

If you use DNSSEC (signatures that let resolvers check your DNS answers are genuine), avoid cPanel's ALIAS record, which cPanel warns can break DNSSEC. If you also plan to turn DNSSEC on later in Cloudflare, make the record change first and confirm it works.

Ask your host for help when dig NS returns nothing, when the Zone Editor or some record types are missing, or when they only give you a hostname and your DNS does not flatten.

The one message worth forwarding

If a developer or host is doing this for you, send them something like this.

Hi, please point example.com to the new site without using a CNAME on the bare domain.

- Bare domain (example.com): A record to 203.0.113.25, plus AAAA to 2001:db8::10 if IPv6 is available.
- www.example.com: CNAME to example.com (or to the host's target hostname).
- Do not change or remove the NS or MX records on example.com.
- If our DNS is on Cloudflare, a CNAME on @ is fine because it is flattened, but please do not turn on flattening for all CNAME records.
- Before the change, please export or screenshot the current zone, and afterwards send me the output of: dig +noall +answer example.com NS example.com A example.com MX

Thanks!

The bare domain carries your nameservers and your mail, so give it a direct A record unless your DNS provider flattens CNAME records for you.