A vs CNAME Records: Choose the Right Website DNS

Web Hosting & Domains / DNS records / Practical guide

Use an A record when your website provider gives you an IPv4 address. Use a CNAME when it gives you another hostname to follow, usually for a subdomain such as www. For the root domain, follow the provider’s specific instructions because ordinary CNAME rules and provider-specific flattening behave differently.

Before changing either record, check which DNS service is authoritative and whether email depends on the name being changed. Moving a website does not automatically require moving email, changing nameservers, or transferring the domain registration.

01 / Match the record type to the destination

An A record maps a name to an IPv4 address; AAAA serves the corresponding role for IPv6. A CNAME makes one DNS name an alias of another. Its value is a hostname, not an IP address.

For a hypothetical setup, a host might ask for www.example.com to alias sites.example.net. That describes a DNS relationship. It is not an instruction to paste a full address such as https://sites.example.net/account/page into the CNAME value.

Do not resolve a provider’s hostname once and substitute the returned address unless its instructions explicitly permit that. If the service later changes its addressing, a manually copied IP can stop following the intended destination.

Neither choice is universally better for search visibility or speed. The correct record is the one supported by the hosting service and DNS arrangement. Avoid turning a connection task into an unsupported optimization experiment.

02 / Treat the root domain and www as separate names

example.com and www.example.com are different DNS names. Many control panels use @ to represent the zone’s root, also called its apex. A change for www does not automatically configure the root name.

Ordinary CNAME records cannot share their name with other ordinary record data. RFC 2181, section 10.1, explains that restriction. Because the zone apex already has required DNS data, a conventional CNAME is not the normal root-domain solution.

Some DNS providers offer special apex handling. Cloudflare’s CNAME flattening, for example, resolves a target and returns final IP addresses instead of publishing an ordinary CNAME answer at the apex. Other providers may use labels such as ALIAS or ANAME; check their documented behavior rather than assuming the names mean identical implementations.

Decide whether both root and www should serve the site or whether one should redirect to the preferred address. Record the DNS requirements and the web redirect requirement as separate tasks.

03 / Preserve email records and inspect shared dependencies

Microsoft’s DNS reference distinguishes MX mail routing from SPF and client-discovery records. A website-only move should not casually replace those email settings with a new host’s default template.

• Record the current MX entries and their priorities.
• Retain the email provider’s authentication and verification records, including relevant TXT and CNAME entries.
• Identify any mail-server or email-client hostname that depends on the website name.
• Check with the email administrator before changing a shared hostname.

The dependency check matters even when MX entries stay unchanged. If an MX destination is the same hostname whose A record you change, mail delivery can follow that changed address. An apparently separate service can therefore depend on the website record indirectly.

SPF can have a similar dependency. RFC 7208’s a and mx mechanisms use DNS address lookups when evaluating authorized senders. If your policy relies on one of those mechanisms, changing the associated addresses can change what the policy authorizes. Review the actual policy rather than assuming an untouched TXT string means unchanged behavior.

Also avoid making an MX destination a CNAME alias: RFC 2181, section 10.3, requires the MX target to have address records. Keep a website alias decision separate from the mail-server target.

If the real task includes moving the registration or DNS service, our domain transfer vs DNS change guide explains that broader decision. This guide focuses on choosing and changing website records.

04 / Prepare the destination and a recovery note

Start in the authoritative DNS service, not whichever control panel happens to be convenient. Record the current nameservers and confirm where live records are managed. If the domain uses an external DNS provider, editing a hosting panel’s unused zone may have no public effect.

Before the change, collect:

• The old record names, types, values, TTLs, and relevant proxy settings.
• The new host’s exact connection instructions for root and www.
• Confirmation that the site is added to the destination hosting account.
• The required HTTPS and domain-verification steps.
• A named person who can restore the old records if verification fails.

Plan cache timing. Cloudflare’s TTL documentation explains that DNS TTL controls how long records are cached. Lowering an editable TTL in advance can help a planned change, but it does not erase answers already cached under the previous value.

Record the previous TTL and allow for it when planning the transition. “Propagation” is not a single worldwide switch that flips at a guaranteed minute. Keep the old service available while you verify the new destination wherever your migration arrangement allows.

05 / Enter only the requested website records

Use the provider’s required name and destination, then check the fully qualified name shown by the DNS editor. Some panels append the zone name automatically, while others accept the full hostname. A preview can catch a name accidentally entered twice.

Resolve conflicts at the exact name being changed. For an ordinary CNAME, adding it alongside an existing A or AAAA record for that same name is not a valid substitute for deciding which configuration the service requires. Preserve the saved previous values before replacing the conflicting website entry.

Review IPv6 as well as IPv4. An old AAAA record may continue sending IPv6 clients to another destination even after the A record changes. Update or remove it only in line with the new host’s supported configuration.

If using Cloudflare, distinguish DNS content from proxy behavior. Its proxy documentation explains that proxied web records return Cloudflare addresses and route traffic through its network. DNS-only records behave differently; email and third-party verification uses may require DNS-only handling. Follow the service’s integration instructions.

Do not toggle every cloud icon or flatten every CNAME during the move. Cloudflare warns that flattening verification CNAMEs can prevent a service from seeing the expected CNAME answer. Limit the change to the documented website requirement.

06 / Verify DNS and the website as separate layers

First compare the stored authoritative records with your change note. Then check public DNS answers using your DNS provider’s diagnostic tools or a suitable DNS lookup tool. Review root and www separately, including A, AAAA, and CNAME behavior where relevant.

A proxied or flattened record may legitimately return addresses rather than the literal target you entered. Compare the answer with the provider’s documented behavior instead of treating every difference as a fault.

Next check the actual service:

1. Open the intended HTTPS hostname and confirm the correct site appears.
2. Check both root and www, including the preferred redirect behavior.
3. Confirm there are no certificate warnings.
4. Try an important page and an essential form or application flow.
5. Test incoming and outgoing email with an external mailbox, and review any authentication or delivery errors.

Write down the result, time, and resolver or network used. If one device still sees the old destination, compare DNS answers before repeatedly changing records. A website configuration error and a cached DNS answer call for different fixes.

07 / Diagnose the result before changing more records

Restore the known previous website configuration when the new setup cannot be made reliable within your planned window. Recovery can also be affected by caching, so retain the change notes and continue checking the affected services.

Frequently asked questions