Domains and DNS

Your site is served on your own domain. Connecting it takes one click if your registrar supports Domain Connect, or two DNS records if you would rather do it by hand. Either way, certificates are issued and renewed for you and there is nothing to upload, rotate or pay for.

Everything on this page happens on one screen: Settings → General (/settings/site), where the Domain field and the Domain Connect button sit together.

Your domain and your preview domain

Both fields are read-only, and both are derived rather than typed.

Domain is set when your workspace is created — it is the domain you gave at sign-up, and changing it is a workspace-level operation, not a settings edit. Preview Domain is not stored anywhere at all: the CMS renders it as literally staging. in front of your domain, every time. There is no way to point preview at a different hostname.

Both hostnames need a DNS record before they resolve, and they need separate records. Connecting one and forgetting the other is the most common half-finished state. The two sites, and what preview deliberately does not do, are described in preview site vs live site.

These fields sit alongside your site title, description, logo and favicon; the rest of that screen is covered in general site settings.

Before DNS is connected

Nothing is broken and nothing is waiting on you. Your site is already built, already deployed and already served over HTTPS — on a temporary Leed-provided address rather than on your own domain. The Visit live site and Visit preview site buttons on the Deploy screen point at that temporary address, and they keep pointing at it until Leed knows your domain is active.

So the state before DNS is “published, on the wrong address”, not “not published”. You can review, share and iterate on the real build the whole time.

There are two ways to move it onto your address. Pick one:

Option 1 — Domain Connect

In Settings → General, click Start Domain Connect next to the Domain field. The button then walks through a fixed sequence of labels, and the label is the whole status display — there is no separate progress indicator:

1. Start Domain Connect — the resting state. Clicking it opens a new tab at your DNS provider.
2. Redirecting… — Leed is signing the request that describes the records to create.
3. (your provider’s tab) — sign in if prompted, review the records Leed is asking for, and approve them. Your provider then returns you to Settings.
4. Waiting for DNS to propagate… — Leed is checking whether the records have taken effect.
5. Connected — done. The button is disabled from here on; hover it to see when the connection was made and through which provider.

Starting the flow requires the Administrator role. Without it the button is disabled and its tooltip reads “Requires Company Administrator role” — see roles and permissions.

The provider tab is opened the instant you click, before Leed even has the URL to put in it, specifically so that a popup blocker sees a real user gesture. If your browser blocks it regardless, Leed navigates the current tab instead — either way you end up at your provider.

The propagation window

After you approve the records, Leed re-checks every 10 seconds for up to 12 attempts — about two minutes. Most registrars land well inside that.

If they do not, the checking stops. The button quietly returns to Start Domain Connect with no explanation, and nothing further happens in the background. Your records are fine; Leed simply is not looking any more.

What Leed is checking, incidentally, is not a DNS lookup. It asks the edge whether your hostname has been reached and validated. That distinction matters for root domains, and it is explained under HTTPS.

What Domain Connect creates

You will be asked to approve five records, which is more than the two you might expect. They fall into two groups:

• Two CNAMEs — one for your domain and one for the staging. hostname, both pointing at Leed’s ingress host. These are what serve your site.
• Three email-authentication records — the DKIM keys for your workspace, so mail Leed sends on your behalf is signed by your domain rather than arriving unsigned. Approving them is what keeps your campaign and transactional mail out of spam folders; see bounces and deliverability.

Approving the whole set is the intended outcome. If you decline the mail group your site still works — you have just declined signed email.

When the flow completes, the Domain block stops offering an action: the button reads Connected and is disabled, and the Domain field is read-only.

Completion also does two things you will see elsewhere. Preview’s temporary address is switched off, so staging.yourdomain becomes the only way in; and both sites are rebuilt so the new configuration reaches the live workers. Those rebuilds appear on the Deploy screen as two rows badged Admin Rebuild with no content change behind them — expected, not a glitch.

Option 2 — CNAME records by hand

Create one CNAME per hostname at your DNS provider. Both records take the same value.

Replace example.com with your own domain. Two things to watch:

Root domains. Some DNS providers do not allow a plain CNAME at the root of a domain and offer an equivalent instead — usually called ALIAS, ANAME or CNAME flattening. Use it; it behaves the same for this purpose, and Leed’s validation is designed to work with it.

After the records resolve

Your domain will start serving your site, and its certificate is issued automatically. But the CMS does not learn about it by itself: the only things that mark a domain as active are the Domain Connect callback and its re-check. Set the records by hand and that marker is never flipped.

The visible consequence is that the Deploy screen’s Visit live site and Visit preview site buttons keep pointing at the temporary address even though your domain works. There are other consequences behind the scenes, in how requests are routed on your domain.

HTTPS

There is nothing to configure and nothing to buy. Once a hostname points at Leed, a certificate is issued for it, and it renews automatically for as long as the record stays in place. Your preview hostname gets its own certificate the same way.

The one mechanical detail worth knowing is how validation works, because it explains a result that otherwise looks impossible. Leed does not validate by looking up a CNAME record; it validates by reaching your hostname over HTTP. That is why a root domain using ALIAS or CNAME flattening validates perfectly well even though a raw CNAME query against it comes back empty — the flattened record answers with addresses, not with a CNAME, and a lookup-based check would wrongly call it unconfigured.

Checking that it worked

Four checks, in increasing order of how much they prove:

1. Settings → General shows the button as Connected. Only ever true on the Domain Connect path.
2. The Visit live site and Visit preview site buttons on the Deploy screen use your domain rather than the temporary address. Also Domain Connect only — see the caveat above if you set records by hand.
3. Visiting https:// + your domain shows your published site with a valid certificate.
4. The response headers say which build you are looking at. This one works regardless of how DNS was configured:

curl -I https://example.com

Look for X-Site-Version, which carries the commit your site was built from, and X-Preview, which is false on the live site and true on staging.. Comparing X-Site-Version against the commit hash on the newest Active row of the Deploy screen is the fastest way to answer “am I actually seeing the new build?”. The full set of response headers is described in headers, caching and security.

If it still does not resolve

DNS changes are usually visible within minutes and occasionally take hours. If a day has passed and your domain still does not answer, the cause is almost always one of four things.