DNS Requirements Before You Point a Domain at a Builder

The domain resolves, the browser loads the builder's placeholder page, and the site still breaks. A mail server stops accepting connections. A verification email never arrives. The form on the new page submits into a void. None of this is the builder's fault, and none of it gets fixed by clicking around inside the builder's dashboard, because the failure lives one layer down, in the DNS records that were set before the domain was ever pointed anywhere.

Pointing a domain at a site builder is the last step in a sequence that most people perform backwards. The builder gets configured first, the domain gets connected second, and the DNS zone is treated as a switch that gets flipped at the end. In practice the DNS zone is the foundation, and a builder's connection wizard can only work with what that foundation already reports. A missing record or a conflicting one turns a five-minute connection into an afternoon of support tickets.

What follows is the set of DNS facts worth confirming before any builder is handed a domain, along with the specific ways each one fails when it is skipped.

The registrar and the DNS host are frequently two different companies

A domain is registered somewhere. Its DNS records are served from somewhere. Those two places are often not the same, and the gap between them causes more confusion than any other single fact about domains.

Registrar dashboards routinely display nameserver fields as though editing them changes DNS. They change where DNS is answered from. If the registrar's default nameservers are still listed, the zone being edited on a separate hosting panel is invisible to the internet, and every record added there is decorative. The builder's verification will fail, the site will not resolve, and the records on the hosting panel will look perfectly correct the entire time.

Confirming this takes one lookup. A public DNS tool queried for the domain's NS records returns the nameservers actually in charge. If those nameservers belong to the registrar rather than the intended DNS host, the zone needs to be moved before anything else happens. Nameserver changes propagate on their own schedule, often within hours but sometimes longer, and every subsequent step waits on them.

The apex record decides whether the bare domain works at all

Builders hand out two addresses: one for the bare domain and one for the www prefix. Whether the bare domain can point at the builder depends on a record type that not every DNS host supports at the apex.

A CNAME record cannot legally sit at the zone apex, because the apex must also carry the zone's SOA and NS records and a CNAME is forbidden from coexisting with anything else. Some DNS providers work around this with a flattened or alias record that behaves like a CNAME at the apex. Others do not, and the builder's instructions will say to use an A record instead, with specific IP addresses that the builder publishes.

This is worth checking before the builder is configured, because the answer determines which connection method the builder should be told to use. Choosing the wrong one produces a domain that works with www and fails without it, or the reverse, and the builder's status page will report a partial connection that never resolves on its own.

An old A record left in place will shadow the new connection

Domains that have hosted a site before usually carry an A record pointing at the previous host. That record does not disappear when a builder is connected. If the builder's wizard adds its own records but the old A record survives at the same name, the zone holds two A records for one hostname. Traffic splits between them, and roughly half of all visitors land on the old server, which may be serving a parked page, an error, or nothing at all.

The same applies to old CNAME records for www, old subdomains for a previous storefront or blog, and leftover records from a verification step performed for some other service years ago. A DNS zone accumulates history, and that history keeps answering queries long after the service that created it was cancelled.

The cleanup step is unglamorous and easy to skip: export or screenshot the full record list before touching anything, then remove every record that points at a host no longer in use. Doing this first means the builder's connection is the only thing answering for the domain, which makes every later diagnostic simpler.

Email records have nothing to do with the builder and everything to do with the business

This is the failure that generates the most panic. A domain gets pointed at a builder, the website goes live, and within a day the company's email stops arriving. The cause is almost always a nameserver change that moved the domain to a DNS host with an empty zone, taking the MX records with it.

Website records and mail records live in the same zone, but they serve entirely separate systems. A builder needs A or CNAME records for the web. Mail needs MX records naming the mail provider's servers, plus SPF and DKIM records that prove which servers are allowed to send on the domain's behalf. None of these overlap. Replacing the whole zone to connect a builder wipes the mail configuration whether or not anyone intended it.

Before any nameserver change, the MX, SPF, DKIM, and DMARC records should be recorded exactly as they appear, including the priority numbers on MX records and the full text of TXT records, which are long and easy to truncate when copied by hand. If the mail provider offers an export or a documented set of values, that document is more reliable than a screenshot.

TXT records are load-bearing and get overwritten by verification steps

Builders verify domain ownership by asking for a TXT record, sometimes a CNAME, containing a unique token. The verification step is harmless on its own. The trouble comes from what else lives at that name.

SPF records are TXT records at the apex. DMARC records are TXT records at a specific underscore-prefixed name. Domain verification tokens from search engines, payment processors, and mail providers are also TXT records, and several of them frequently want to sit at the same name. DNS allows multiple TXT records at one name, but some DNS panels present a single editable field rather than a list, and pasting the builder's token into that field silently replaces the SPF record.

The result is mail that still sends but increasingly lands in spam, or fails authentication outright, days after the website went live and with no obvious connection to the website work. Verification tokens should be added as new records, never typed over existing ones, and the SPF record should be confirmed present after the builder's verification completes.

TTL values set the pace of every mistake and every fix

Every DNS record carries a time to live, a number in seconds that tells resolvers how long to cache the answer. A record with a TTL of 86400 is cached for a full day. A record with a TTL of 300 is cached for five minutes.

High TTLs are efficient and completely reasonable for a zone that never changes. They are miserable during a migration, because a mistake made after a record has been cached cannot be undone quickly. The old answer keeps being served from caches around the internet for as long as the TTL allows, no matter what the authoritative zone now says.

A practical sequence: lower the TTL on the records that are about to change to 300 seconds or so, wait at least as long as the previous TTL, then make the change. The wait is the part people skip, and it is the part that matters, because until the old TTL expires, resolvers are still holding the old answer and the lowered TTL has not taken effect. After the migration is confirmed working for a few days, the TTL can go back up.

The builder's DNS panel and the real zone can drift apart

Several builders offer to manage DNS directly, either by taking over the nameservers or by presenting a records editor inside their own dashboard. This is convenient and creates a second source of truth that quietly diverges from the first.

When a builder manages DNS, records added at the registrar or the original DNS host may have no effect, and records shown in the builder's panel may not reflect what the nameservers actually serve. During a migration this produces a specific and maddening symptom: the record looks correct in whichever panel is open, and the public lookup returns something else entirely.

The only reliable check is an external lookup against the authoritative nameservers, performed after every change. If the public answer matches the panel, the change landed. If it does not, the panel being edited is not the one in charge, and the NS records will say which one is.

A fifteen-minute audit before the first builder login

The audit is short and entirely unglamorous. Query the NS records and identify the real DNS host. Query the A and CNAME records at the apex and at www, and note every stale target. Export the MX, SPF, DKIM, and DMARC records in full. List every TXT record with its exact name. Note the TTL on anything about to change, and lower it before the change rather than after.

Fifteen minutes of this turns the builder's connection step into what it was advertised as: a single action with a predictable result. The alternative is a live site that half-loads, a mail server that stopped accepting mail on a Tuesday, and a support queue where each team correctly insists the problem is somewhere else.

DNS is the one part of the stack that every other part depends on and no dashboard owns. The records are already there, answering queries right now, whether or not anyone has looked at them recently. Looking first is cheaper than diagnosing later.