CNAME vs A Record: Which Do You Need to Connect a Domain?

An A record points your domain directly at a server's numeric IP address; a CNAME record points it at another domain name, which then gets looked up itself. Both get a visitor to the same website. The difference is one extra lookup step, and a rule about where each type is allowed. Most website builders ask you to add an A record for your root domain (example.com) and a CNAME for www — this covers what each record actually does, why builders split them that way, the one thing CNAMEs can't do at the root, and worked DNS values from a real builder's own setup guide.

What does an A record do?

An A record is the most direct kind of DNS record. Cloudflare's DNS documentation defines the pair plainly: "A and AAAA records map a domain name to one or multiple IPv4 or IPv6 address(es)" (Cloudflare, "DNS record types", checked September 2026). An A record holds an IPv4 address (the AAAA variant holds IPv6). When a visitor's browser looks up your domain, it asks a DNS server for the A record, gets back an IP address like 198.51.100.10, and connects to that server directly. There's no second lookup — the A record is the final answer.

What does a CNAME record do?

A CNAME record works differently: it doesn't hold an address at all. Cloudflare's documentation says "CNAME records map a domain name to another (canonical) domain name" (same source). So a CNAME at www.example.com might point to example.figment.so — the resolver then has to look up that name's own A record to find an actual IP address. This is one extra step, but it means the target company (your website host) can change its servers' IP addresses whenever it needs to, without you ever touching your own DNS again. You're pointing at a name they control, not a number that can go stale.

Why do builders ask for an A record on the root and a CNAME on www?

This split exists because of a rule in the DNS specification itself, not because builders prefer it that way. RFC 1034, one of the foundational DNS standards, states: "If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different" (IETF, RFC 1034, section 3.6.2). Your root domain already has other required records at that same name — at minimum an SOA (start of authority) record and NS (nameserver) records, which is how the domain has a DNS zone at all. A CNAME can't share a name with those, so the root domain (also called the apex or the bare domain) generally can't hold a CNAME. www.example.com, on the other hand, is a separate name with no other records competing for that spot, so it's free to be a CNAME.

That's the practical reason a builder's setup guide gives you two different instructions: an A record (or several) for example.com, and a CNAME for www.example.com pointed at the builder's own hosting name.

Can I put a CNAME on my root domain anyway?

Not through a plain CNAME, no — that's the RFC restriction above. But several DNS providers offer a workaround with a different name: CNAME flattening, or an ALIAS record, depending on the vendor. Cloudflare describes its version this way: "CNAME flattening speeds up CNAME resolution and allows you to use a CNAME record at your zone apex." In practice, "Cloudflare finds the IP address that a CNAME points to" and then "returns the final IP address instead of a CNAME record" (Cloudflare, "CNAME flattening", checked September 2026). In other words, the DNS host does the lookup on its own servers ahead of time and hands your visitors a plain A-record-style answer, so the RFC rule is never actually broken — it just happens behind the scenes.

Not every DNS host offers this. If yours doesn't document CNAME flattening or an ALIAS record type, use the A record your builder gives you for the root domain instead of looking for a workaround.

What is TTL, and how long does a DNS change take to work?

Every DNS record carries a TTL (time to live) value, usually shown in seconds. Cloudflare's documentation defines it directly: "Time to Live (TTL) is a field on DNS records that controls how long each record is cached and — as a result — how long it takes for record updates to reach your end users" (Cloudflare, "TTL", checked September 2026). The trade-off is built into the same sentence: "Longer TTLs speed up DNS lookups by increasing the chance of cached results, but a longer TTL also means that updates to your records take longer to go into effect" (same source). A short TTL (a few minutes) makes future changes propagate faster, at a small cost in lookup performance; a long TTL (hours or a day) is more efficient day-to-day, but a mistake takes longer to fix.

This is also why "propagation" isn't instant. Old answers can stay cached at your ISP or in your own browser until their TTL expires, so a DNS change that looks correct in a lookup tool can still take time to reach every visitor.

Worked example: connecting a domain with real DNS values

Example (hypothetical): here is what one real builder's own instructions actually ask for, to show the A-record-on-root, CNAME-on-www pattern with genuine values rather than placeholders. Squarespace's DNS Connect setup documents these exact records for pointing an outside domain at a Squarespace site: a CNAME for www pointed at ext-cust.squarespace.com, and four A records, all with @ (meaning the root) as the host, pointed at 198.185.159.144, 198.185.159.145, 198.49.23.144, and 198.49.23.145 (Squarespace, "Connect a third-party domain to your Squarespace site", checked September 2026). Squarespace also documents a separate CNAME, with a unique verification code, pointed at verify.squarespace.com — that one confirms you control the domain before the connection goes live. Our full guide to Squarespace domains covers the rest of that setup, including nameserver-based connection as an alternative to record-by-record DNS.

The shape is the same everywhere, even though the exact IPs and CNAME targets differ by host: multiple A records at the root for redundancy, one CNAME at www pointed at the host's own domain name, and sometimes a verification record layered on top.

What if my DNS change doesn't work?

Before assuming something's broken, check the obvious first: did you enter the record at @ (root) versus www correctly, and does your DNS provider require a trailing dot on the CNAME target (some do)? A public DNS lookup tool, checked from a browser or terminal, will show you what's actually being returned right now — compare that against the values your builder's guide gave you.

If the values are right and it's simply not resolving yet, that's most likely the TTL of the old record still being cached somewhere between you and the visitor — wait out the old TTL before changing anything else. If you edited the wrong record and need to undo it, the fix is simple as long as you noted the previous values first: put the old A or CNAME record back exactly as it was. This is one more reason to write down your full existing DNS zone before making any change, not just the records you think you're touching.

One record type is easy to break by accident here: MX records, which route your email, live at the same root name as your A records but are a completely separate record type. Changing your A records for a website move doesn't touch MX records unless you edit them directly — leave them alone. Our guide to switching builders without breaking email covers which records are safe to touch and which aren't.

Where this fits if you're moving your whole site

Connecting a domain is one piece of a larger move. If you're leaving a website builder for a Figma-based site published through Figment, the DNS step above still applies — Figment's paid plans support custom domains, and you'll add records at your registrar the same way described here. If you're taking the domain's registration itself somewhere else, rather than just repointing DNS, that's a different process with its own lock periods and authorization codes; see our guide to transferring a domain away from a website builder. And if the whole reason you're touching DNS is a builder switch, our website migration checklist walks through the domain step in the order that keeps the rest of the site working while you do it.

Bottom line: an A record is a direct address; a CNAME is a pointer to another name that gets looked up again. The DNS specification itself is why your root domain almost always needs an A record and www can use a CNAME — not a preference any one builder invented. CNAME flattening or an ALIAS record, where your DNS host documents one, is the one way around that restriction at the root.