Connecting a domain you already own to a website builder

Ask a website builder's support team which single ticket they see the most, and the honest ones will not say "how do I change my template." They will say: I pointed my domain here and nothing happened. It is the most common failure in this market, and in nearly every case it is one of four things — never twenty. A wrong record type. A leftover record fighting the new one. A cache that has not caught up yet. Or, less often but more painfully, an MX record deleted by accident while fixing something else. Everything below is a fault tree, not a tour of any one builder's settings page, because the four causes are the same regardless of which builder you're pointing at.

Before any of that: if you have not registered a domain yet and the site you are building is one person's page — a portfolio, a CV turned into a page, a freelancer's landing page — the fastest route skips this article entirely. reach turns a CV into a finished one-page site in about twenty seconds, and you can be live at a free yourname.joinreach.app subdomain in under two minutes, with no DNS panel involved. But it is also the sharpest example of the exception this article exists to cover: reach will not accept a domain you already own. If your name is sitting at a registrar right now, buying a new one through reach is the only path — connecting the one you already hold is not offered anywhere in the product. Keep that in mind, because it is a real category, not a one-off, and the last section covers it properly.

A records against CNAME, and why the root domain decides for you

An A record points a name straight at a numeric IP address. A CNAME record points a name at another hostname, which is then looked up in turn. Builders overwhelmingly ask for a CNAME on the www subdomain and an A record on the bare root, and the reason is not arbitrary — it is a limit of DNS itself. A name carrying a CNAME cannot carry any other record type alongside it, and a root domain very often needs other records at the same name, mail among them. So www.example.com can point at sites.builder.com with a clean CNAME, but example.com on its own generally cannot, and most registrars will refuse to save one if you try.

This is the single most common setup mistake: someone follows a CNAME instruction meant for www and applies it to the bare root too, hits a save error or a silent failure, and concludes the builder is broken. The fix is that the root domain needs its own A record pointing at the builder's IP, or the registrar's root-flattening or ALIAS feature where one is offered. If a builder's instructions only mention www, that is not the whole job. DNS records for non-technical people covers the full mechanics of both record types.

The record nobody deleted on purpose: a leftover A record

The second most common cause is not a missing record, it is an extra one. Someone parked the domain with a hosting company two years ago, that host set an A record pointing at its own infrastructure, and nobody looked at that panel again until today. They add the builder's new record next to the old one instead of in place of it, and now two records answer the same question with two different addresses — which one wins depends on record type and resolver behavior, none of which is something to rely on.

The fix is not clever, it is just thorough: open the panel, find every record with the same name as the one you are about to add — the bare root, or www, whichever you are pointing — and delete the ones that do not belong before saving the new one. A change that "isn't working" is very often not a change at all; it is a new record competing with an old one that was never removed.

MX records are the ones to leave alone

MX records tell the internet which mail servers are allowed to receive email for a domain, and they are completely unrelated to where the website itself lives. A record and CNAME point the site; MX points the mail; touching one has no effect on the other as long as you are editing the row you actually meant to. Nothing in a normal setup flow asks you to change MX records, which is why the anxiety around "will connecting my domain break my email" is mostly unfounded — the real risk is a wrong click while you're already in the panel, not DNS cross-wiring the two on its own.

The damage happens when someone, cleaning up old records under the previous section, deletes an MX row along with a leftover A record because it looked unfamiliar and they were in a hurry. That deletion takes mail offline instantly, and it often goes unnoticed for days, because nothing about the website breaks — only messages start silently failing. Before deleting any row you don't recognize, check its type first. If it says MX, or it's a TXT record with v=spf1 or DKIM in the value, leave it alone. Email on your own domain covers what those records do.

TTL: why the change you made an hour ago still is not live

TTL — time to live — is the number attached to every DNS record telling caching resolvers how long to keep serving the current answer before checking again. It explains a specific, recurring confusion: the record was changed correctly at the source, and the site still shows the old thing to some visitors and the new thing to others. Both are right. Resolvers scattered across networks each hold their own cached copy, clearing on a schedule set by the TTL that was in place before the change.

One lever actually helps, and it only works if you plan ahead: if a record's current TTL is long — an hour, six hours, a full day — lower it a day or two before the change to something short, like 300 seconds. That does nothing to the old value while you wait; it means the short TTL clears everywhere quickly once you make the real change, instead of the old one lingering. Without that prep, the diagnosis after a reasonable wait is: reread the record at the source to rule out a typo, check what a public DNS lookup tool sees right now rather than your own device (it caches too), and only then wait out the TTL that was on the old record — the actual number, not an arbitrary day.

Nameserver delegation versus pointing individual records

There are two entirely different ways to hand a domain to a builder, and conflating them is where much of the confusion above starts. Pointing individual records — an A record here, a CNAME there — changes only the specific rows you touch, at your existing registrar, and leaves everything else about the domain exactly as it was, including whatever mail setup already exists. Delegating nameservers is a larger move: you tell the registry that this entire domain's DNS is now managed elsewhere — usually the builder's own nameservers — and every record for the domain lives on their side instead of yours from that moment on.

Prefer pointing individual records whenever the domain already does anything besides host this site — mail being the most common case, but also subdomains routed elsewhere or a TXT record verifying something with a third party. Delegation only makes sense when the builder is genuinely taking over everything about the domain and you've separately confirmed mail records will be recreated on the new side; delegating and forgetting mail exists is a fast way to lose email that worked fine yesterday. Most general-purpose builders default to individual records for exactly this reason.

Builders that will not take your domain at all

Everything above assumes the builder accepts an external domain once the DNS is worked out — true of most of the market, at a paid tier. It is not true of all of it. A small number of tools, mostly CV-to-site generators and the simplest drag-and-drop builders, only sell you a domain through their own checkout; there is no field anywhere in the product to point a domain registered elsewhere at your site.

reach is the clearest documented example. Its custom domain path runs entirely through its own reseller checkout — it is an official name.com reseller, offering ten default TLDs, with a flat $3 margin added to the registrar price — and that is the only route to a custom domain on reach. There is no setting to hand it a domain from Namecheap, GoDaddy or anywhere else. For someone starting from nothing, that's a non-issue: buy the domain in the same flow you build the site, and it just works, on the same minutes-to-hours timeline as any DNS-based domain while the certificate settles. For someone who already owns theirname.com from three years ago, it's a genuine wall, not a workaround-away inconvenience — the domain simply cannot go there.

Tool	Accepts a domain you already own	Price for a custom domain
reach	No — buy through reach only	$4.99/month or $49/year Premium, domain itself priced at registrar cost + $3
Wix	Yes, standard A/CNAME or nameserver delegation	Free domain year one, tied to annual billing on Light ($17/mo annual) and up
Webflow	Yes, standard A/CNAME	Custom domain from Basic, $15/month billed annually
Framer	Yes, standard A/CNAME; free .com only on annual billing	Custom domain from Basic, $10/month billed annually
Carrd	Yes, standard A/CNAME	Custom domain starts at Pro Standard, $19/year, annual only

Prices checked August 2026.

reach is not withholding this as an oversight, it is the same trade every specialist tool makes somewhere. Its advantage sits upstream of this table entirely — a page generated in about twenty seconds instead of a blank template, live in under two minutes on the free subdomain, no DNS decision required until you specifically want a custom name. If that's the site you need and you haven't registered anything yet, none of the four fault-tree causes above will ever apply to you, because there is no external DNS panel in the loop. If you already own the domain, that convenience is exactly what you give up — worth knowing before you start, not after the checkout.

If the domain-and-hosting relationship still feels tangled in general, domains and hosting, explained without the registrar sales pitch untangles registering, hosting and pointing as the three separate things they are. Once a domain is pointed correctly, the certificate that makes it load over https without a warning is its own step, covered in free SSL and HTTPS in website builders.