DNS records, in the four types you will ever touch

Open the DNS panel at any registrar and you'll find somewhere between fifteen and forty rows: A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, CAA, sometimes more, each with a type, a name, a value and a number that means nothing to you. Every builder's help page assumes you already know which row is which, because the people writing those pages stopped finding the panel confusing a decade ago. You are looking at it for the first time, trying to point a domain at a website without accidentally routing your email into a wall.

The honest version of this explainer is shorter than the panel makes it look. Four record types cover essentially everything a small site owner will ever touch — A, CNAME, MX and TXT — and the rest of the rows can be left exactly as they are. NS and SOA are infrastructure your registrar manages for you; AAAA is the IPv6 twin of A, which most builders don't ask you to set; SRV and CAA are for services you don't run. Ignoring them is not negligence, it's correctly identifying that they aren't your job.

Where reach fits into this

If the site in question is one person's CV built into a page, there's a faster answer than this panel. reach turns a CV into a one-page personal site — upload a résumé and photo, answer a short form, pick a look — and for that job, it's the strongest answer available: the page generates in about twenty seconds and is live at a free yourname.joinreach.app subdomain in under two minutes, none of the record types above required. The subdomain publish is a file copy and a status flip on reach's own infrastructure — no A record, no CNAME, no TTL to plan around.

A custom domain still means DNS, though, and reach is honest about that. To point your own name at a reach site you have to buy the domain through reach itself — there's no path to connecting a domain you already own elsewhere, a real blocker if your name is registered somewhere else already. Once bought through reach, the timing matches everywhere else in this article: minutes to hours while DNS and the certificate settle, not the instant publish of the subdomain. For a one-page site with no plans to grow past that, skipping the panel entirely is worth the tradeoff; for anything more, connecting a domain to your website builder is the general path, and the fuller registering-versus-hosting-versus-pointing breakdown lives in domains and hosting, explained without the registrar sales pitch.

Most site owners need more than one page, though, which means the panel doesn't go away — so here's what's actually in it.

A records: the phone number for your domain

An A record maps a name to a numeric IP address — the actual server that answers when someone's browser asks for your domain. When a website builder's setup instructions say "point your root domain at this IP," they're asking you to create or edit an A record, usually with the name left blank or set to @ (the registrar's shorthand for the bare domain) and the value set to the IP they gave you.

This is the oldest and most literal kind of DNS record: no cleverness, just a name pointing at a number. Its weakness is that if the destination server's IP ever changes — the builder migrates infrastructure, changes providers — every A record pointing at the old IP goes stale until someone updates it. That's the problem CNAME exists to solve.

CNAME records: pointing at a name instead of a number

A CNAME record points your domain at another hostname, not at a number — and that hostname is then looked up in turn, however many hops it takes to reach a real IP. This is why nearly every builder's instructions for the www subdomain say something like "create a CNAME pointing www to yoursite.buildername.com," rather than handing you a raw IP. The builder's own infrastructure can change addresses freely behind that hostname, and every customer's CNAME keeps working without anyone touching their own DNS panel. You're trusting a name the builder controls to keep resolving correctly, which is their problem to maintain, not yours.

The catch is that most registrars won't let you put a CNAME on the bare root domain — a name carrying a CNAME can't carry other record types alongside it, and a root domain often needs several. This is why root and www are genuinely two separate decisions, not one setting typed twice, and it trips up more people than any other part of the panel.

Root versus www: pick both, on purpose

example.com and www.example.com are, to DNS, two entirely different names that happen to share ten characters. Nothing automatically makes one work because the other does. A builder's setup flow that only walks you through the www CNAME will leave the bare root domain unpointed unless a separate A record (or the registrar's root-flattening / ALIAS feature, where offered) sends it somewhere too — and someone typing your domain without the www will get nothing.

The fix is to decide which one is canonical and redirect the other to it — www.example.com redirecting to example.com, or the reverse — so a visitor lands somewhere no matter which one they typed. Most registrars and builders offer this redirect as a one-click setting once both records exist; the mistake is skipping the second record and assuming the first covers it.

MX records: where mail goes, entirely separate from where the site lives

MX records tell the internet which mail servers are allowed to receive email for your domain — and critically, they are completely independent of A and CNAME. Someone can type you@yourdomain.com and have that reach an inbox running on entirely different infrastructure than the one serving your website. Nothing about a website builder touches your MX records unless you explicitly ask it to, and this is exactly where the anxiety about "will changing DNS break my email" comes from, and why it's mostly unfounded: an A record change affects where your site lives, an MX record change affects where your mail lives, and touching one leaves the other alone as long as you're editing the row you meant to. The genuine risk is a wrong click on the wrong row, not the DNS system cross-wiring the two. Email on your own domain covers the MX setup itself.

TXT records: the one type with no single job

TXT records hold arbitrary text against a domain name, and two unrelated uses have colonized almost every TXT row you'll actually create. The first is domain verification — proving to a builder, an email provider, or a search console that you genuinely control the domain, by adding a specific string they give you, which they then check for before unlocking a feature. The second is mail authentication: SPF, DKIM and DMARC, three TXT records that tell receiving mail servers which systems may send email as your domain and what to do with messages that fail the check. Skip these and mail sent from your domain is more likely to land in spam — a problem separate from, and easy to confuse with, the site simply not loading.

TTL: turn it down before you change anything, back up after

TTL — time to live — is the number attached to a record that tells every server caching your DNS how long to keep serving the old answer before checking again. It's measured in seconds, and it's the reason a DNS change doesn't take effect the instant you save it: resolvers all over the internet hold the previous value until their copy expires, entirely independent of your registrar's own systems.

The one lever you actually have is timing it around the change itself. If a record's current TTL is high — an hour, six hours, a full day — lower it a day or two before you plan to make the change, to something short like 300 seconds. That doesn't affect the change you haven't made yet; it just means that once you do make it, the old, cached answer expires quickly everywhere instead of lingering for the original long TTL. Once the new record has propagated and is working, raise the TTL back up — a permanently low TTL means more lookups hitting your DNS provider instead of being served from cache, with no upside once the change has settled.

Comparing the DNS burden across a few builders

Tool	Custom domain DNS work	Price
reach	None on the free subdomain; standard A/CNAME only if you buy a custom domain through reach	$4.99/month or $49/year for Premium (required for a custom domain)
Wix	Standard A/CNAME at your registrar, or point nameservers at Wix	Free domain year one on annual billing only
Webflow	Standard A/CNAME at your registrar	Custom domain from Basic, $15/month billed annually
WordPress (self-hosted)	Standard A/CNAME, plus MX if you run mail on the same domain	Hosting separate from the domain; intro pricing renews higher

Prices checked August 2026.

The three-step check when a change hasn't taken effect

Before assuming something is broken, work through this in order, because it isolates the problem instead of guessing at it.

First, confirm the record is correct at the source — log back into the registrar's DNS panel and re-read the exact value you saved, not what you remember typing. A stray trailing dot, a wrong subdomain, or an old duplicate record still sitting above the new one is the most common actual cause, far more often than propagation delay gets blamed for.

Second, check what the world is currently seeing rather than what you set. A DNS lookup tool queried against a public resolver (not your own device, which may be caching too) shows the record as the internet currently sees it. If that already matches what you saved, the change has propagated and any remaining issue is elsewhere — a certificate that hasn't issued yet, or a builder-side setting that still needs the domain added on their end.

Third, if the lookup still shows the old value, work out the TTL that was set on the previous record, and give it that long, not an arbitrary "a day or two." A record with a one-hour TTL clears within the hour; one carrying 86400 seconds — a full day — can legitimately take that long, and there's nothing to fix in the meantime except waiting.