Updated September 2026
Connecting a domain to a launch page is a five-minute job. What almost nobody plans for is the second move — the morning you repoint it at the real site — and that is where launch days go wrong, in a way that is entirely preventable the week before.
Below: the record to add and why the apex is the awkward one, why the certificate fails if you do it in the wrong order, and the one setting to change before launch day so the switch takes minutes instead of a day and a half.
The first move
Both work. They are not the same amount of trouble, and the difference is a rule in the DNS specification rather than a limitation of any particular host.
launch.yourbrand.com
One CNAME pointing at your host. It follows the host wherever it moves, so if their IP address changes you do nothing.
Also the safest choice while the main domain is still serving something else — the existing site keeps working untouched.
yourbrand.com
A bare domain cannot hold a CNAME — the spec forbids it alongside the SOA and NS records that have to live there. So it is an A record to an IP address, or a provider-specific ALIAS / ANAME that fakes one.
An A record is a hard-coded address: if the host renumbers, your page goes dark until you update it. Cloudflare, DNSimple and Route 53 all offer a flattened alternative — use it if your registrar has one.
# A subdomain — follows the host if its address changes
launch.yourbrand.com. CNAME pages.example-host.com.
# The apex — a bare domain cannot hold a CNAME
yourbrand.com. A 203.0.113.10
www.yourbrand.com. CNAME yourbrand.com.
# Better, where your registrar supports it:
yourbrand.com. ALIAS pages.example-host.com. Point www as well, and make one of the two redirect to the other. Two names both answering 200 with the same page is a duplicate you created yourself.
The order matters
The instinct is to add the domain in the dashboard first, then set up DNS. Do it in that order and the certificate request fires while the name still points nowhere. The authority cannot reach the domain, the check fails, and the platform retries.
The retries are the problem. Let's Encrypt rate-limits failed validations, and a handful of impatient attempts can lock that exact hostname out for an hour or more — usually discovered on the one afternoon you needed it live. The lock is on the name, so no amount of clicking helps.
So: DNS first, dashboard second. Add the record, confirm it resolves, and only then tell the platform about the domain. The certificate then issues on the first attempt, usually in under a minute.
# Confirm the name resolves BEFORE adding it in the dashboard
dig +short launch.yourbrand.com
# pages.example-host.com.
# 203.0.113.10
# Empty output means DNS has not taken effect yet.
# Adding the domain now is what triggers the failed
# certificate attempts — and the rate limit on that hostname.The move nobody plans
A launch page is temporary by definition. On launch morning you will repoint the domain at the real site — and every resolver that already looked up your domain will keep serving the old answer until its cached copy expires. That expiry is the TTL you set, often left at the registrar default of 24 or 48 hours.
Which means: you launch, you announce it, you email the list you spent three months building — and a large share of them click through to the coming soon page. It is still promising a launch that already happened. Nothing is broken, so nothing alerts you.
The fix costs nothing and has to happen in advance, because lowering the TTL is itself subject to the old TTL. Drop it to five minutes about a week out. Switch on launch day, watch it take effect in minutes, then put it back up once things are settled.
Every page gets a free subdomain immediately, so you can publish and share before touching DNS at all. Connecting your own domain is a Pro feature: add the record, type the domain into the builder, and the certificate is issued automatically — nothing to buy or renew.
Nothing is rebuilt when the domain changes; the same page simply answers on a new name. And since it answers 200 rather than 503, it can start earning search results on your real domain while you build the thing behind it.
Questions
Either. The main domain gives the launch page the SEO value of your real address, which is usually the point. A subdomain is safer while something else is still serving on the main one, and it lets you keep both live at the same time.
The DNS specification does not allow a CNAME alongside the SOA and NS records that must exist at the apex. Use an A record, or your registrar’s ALIAS/ANAME if it has one — that gives you the flexibility of a CNAME at an address the spec is happy with.
Not the 24 to 48 hours everyone quotes. It takes as long as the TTL on the record that resolvers already cached — which is often 24 hours by default, hence the folklore. Lower the TTL in advance and the same change lands in minutes.
Usually because the domain was added on the platform before DNS pointed at it. The authority tries to reach the name, cannot, and the attempt fails; repeat that a few times and the hostname is rate-limited for a while. Set DNS first, confirm it resolves, then add the domain.
It stops being served on that name and stays reachable on its subdomain. Keep it there for a while — it is a decent record of what you promised, and the list you collected on it does not move.
Both should resolve, but only one should answer with the page. Redirect the other with a 301. Two names both returning 200 with identical content is a duplicate you created for yourself, and Google has to pick a winner you did not choose.