A record vs CNAME: which one to use

When you point a domain at a host, the DNS panel asks for a record type. The wrong choice causes confusing failures: the panel rejects the record, the site disappears, or email stops arriving.

The decision is small, but one rule in the DNS standard trips up a lot of people. Once you know where it comes from, the root, www, subdomain and email cases mostly sort themselves out.

What is an A record?#

An A record maps a name to an IPv4 address. When someone looks up app.mysite.com, DNS answers with something like 203.0.113.10 and the browser connects to that IP. The IPv6 equivalent is the AAAA record.

dig app.mysite.com A +short
203.0.113.10

It is the simplest and most predictable type: one lookup, one answer. The cost is that the IP is written into your zone. If the host changes IP, you must edit the record on every name that points to it.

What is a CNAME?#

CNAME stands for "canonical name". The record says one name is an alias of another: whoever looks up the alias receives the target name and keeps resolving until an IP is found.

dig www.mysite.com CNAME +short
mysite.com.

The trailing dot marks a fully qualified name (FQDN). Without it, some panels append your domain to the value and the target ends up wrong.

The upside is maintenance: if the target changes IP, your alias follows without any DNS edit. The downside is one extra lookup during resolution, which caching usually absorbs for the length of the TTL.

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

There is no universal winner: what decides it is what your host gives you (an IP or a name) and where the record will live.

Why does a CNAME not work at the root domain?#

RFC 1034 states that if a CNAME exists at a name, no other data should exist at that same name. RFC 2181 reinforces the rule, and RFC 1912 sums it up: a CNAME record is not allowed to coexist with any other data.

The root domain (mysite.com, no prefix, also called the apex) always has SOA and NS records, and usually MX and TXT too. A CNAME there would conflict with all of them. DNS panels usually reject it, and when one accepts it the result is unpredictable: RFC 1912 warns that BIND refuses any other data at the name once it sees the CNAME, so the NS records are ignored and the hosts in that domain become unreachable.

Some providers work around this with CNAME flattening, also called ALIAS or ANAME. The provider itself resolves the target name and answers with IPs as if they were A records. It is a DNS provider feature, not part of the standard, and the name varies: Cloudflare calls it flattening, other providers use ALIAS or ANAME. If yours has none, use an A record at the root.

How does a CNAME affect email?#

A CNAME can break email in two separate ways.

A CNAME at the same name as the MX. Since a CNAME cannot coexist with other data, creating a CNAME at the root conflicts with the MX and TXT records (SPF, verifications). The domain's email stops arriving. It is the most common cause of "I changed the website and email stopped".

An MX pointing to a CNAME. RFC 2181 (section 10.3) says the target of an MX or NS record must not be an alias, and RFC 1912 also advises against it. The MX value should be a name that has an A or AAAA record.

So if the domain receives email, never put a CNAME at the root, and always point the MX to a name that resolves directly to an IP.

When should you use each one?#

• Root domain (mysite.com): an A record, or ALIAS/ANAME/flattening if your provider has it.
• www: a CNAME to the root (mysite.com.) or to the name your host provides. An A record with the same IP also works.
• Subdomains (app, api, bot): a CNAME when the host gives you a target name. It survives IP changes best. See what a subdomain is.
• Host that only gives you an IP: an A record, at any name.
• A name that also needs MX or TXT: an A (or AAAA) record, never a CNAME.

Example zone for a site at the root with www and app:

The values are fictional: use the ones your host gives you. The full walkthrough is in how to point a domain to your hosting, and the catalog of types is in DNS records explained.

How do you confirm what is published?#

Query the record type directly:

dig mysite.com A +short
dig www.mysite.com CNAME +short
dig mysite.com MX +short

To see the whole chain down to the IP, run dig www.mysite.com: the ANSWER section shows the CNAME followed by the A record. If one name shows a CNAME alongside other types, the zone is inconsistent and needs fixing.

After you change a record, the old value may stay visible until the TTL expires on resolvers.

How to do this on Square Cloud#

Every web application on Square Cloud gets a *.squareweb.app subdomain with HTTPS on every plan, with no record for you to create. Custom domains are available from the Standard plan.

You add the domain in the dashboard, which lists the DNS records you need, and you create those records at your registrar or DNS provider. The target is a CNAME to cname.squareweb.app, plus a TXT record for validation. The dashboard shows validation status in real time and issues TLS automatically.

Since there is no fixed IP to put in an A record, the root domain works when your DNS provider supports a CNAME at the apex (flattening or ALIAS), as covered above. For www, the recommended setup is a redirect to the main domain. The domain stays registered in your name, and the DNS zone stays with you.

If several applications serve the same domain, see load balancing too. The details are on the domains page.