Landing Page Custom Domain: DNS Setup Done Right

For a landing page custom domain, choose Webflow if the page may grow into a marketing site and you need structured site control; it loses to Unbounce for teams whose main priority is conversion testing. Use a subdomain for isolated campaigns, edit records at the authoritative DNS provider, complete SSL verification, and test redirects, forms, analytics, and final ad URLs before spending on traffic.

The short version

Our pick: Webflow

Best for: Marketing teams building campaign pages that may become part of a larger, structured website.

Skip it if: Do not pick Webflow solely for conversion experimentation; Unbounce is the stronger fit when testing workflows are the primary requirement.

Key takeaways

• •Decide between a campaign domain, subdomain, and root domain before changing DNS; that choice affects routing, reporting, and future site ownership.
• •Edit DNS where the authoritative zone is managed, which may be your registrar, host, or CDN rather than the company that sold the domain.
• •A record, CNAME, and forwarding are different tools. Use the exact record type and target supplied by your page platform.
• •A domain resolving in a browser is not enough: verify SSL, canonical redirects, forms, analytics, and ad destination URLs before launch.
• •Platform connection targets change. Use current instructions from Carrd, Unbounce, Webflow, or HubSpot instead of copying DNS values from another guide.

What's on this page

• •1. Pick the domain structure before you open DNS
• •2. Find the authoritative DNS provider and inventory what is already live
• •3. Know what A records, CNAMEs, and forwarding actually do
• •4. Connect the preferred hostname, alternate hostname, and canonical redirect
• •5. Follow the platform-specific connection path, not a copied record set
• •6. Treat verification and SSL as separate launch gates
• •7. Run a staged launch checklist before you turn on ads
• •8. Fill the gap between a template builder and a full site rebuild

1. Pick the domain structure before you open DNS

Your first decision is not which DNS record to paste. It is what this page should own.

Use a dedicated campaign domain when isolation matters. This is useful for a one-off product launch, a partner campaign, or a paid-media test that should not share URL structure with your main site. You get a clean boundary, but you also create another domain to renew, secure, measure, and document.

Use a subdomain when your main site must stay where it is. For example, go.example.com, pages.example.com, or launch.example.com can point to a landing page platform while www.example.com continues to serve your existing site. For most established businesses, this is the lowest-risk option for a landing page with custom domain.

Use the root domain—also called the apex, such as example.com—only if the landing page is becoming your primary site. Pointing the root domain at a new platform can replace the website visitors see at the bare domain. It can also affect redirects, existing paths, and services using that hostname.

Write down the intended public URL before setup: hostname, path, and redirect rule. For example: go.example.com/summer or example.com/launch. Then answer one practical question: what currently answers at that address? If the answer is “an existing site,” do not change records until you know how that site is routed.

2. Find the authoritative DNS provider and inventory what is already live

The registrar is where you bought the domain. It is not always where you edit DNS.

Look at the domain’s nameservers or DNS delegation. If they point to a CDN, hosting company, or managed DNS service, that provider is authoritative. That is where your new records must be created. Adding a CNAME at the registrar while the DNS zone is actually managed elsewhere changes nothing.

Before you add or delete anything, export or screenshot the DNS zone. Then inventory records for the hostname you plan to use:

• •A and AAAA records may serve an existing website.
• •CNAME records may point a subdomain to another platform.
• •MX, SPF, DKIM, and DMARC records support email and should not be casually removed.
• •TXT records may be used for domain verification, email authentication, or third-party services.

A common launch-day mistake is seeing a record with an unfamiliar label and deleting it to “make room.” That can break email delivery or a live verification workflow without taking the website down, which makes the problem harder to spot.

Add only the exact records your platform currently supplies. If there is a conflict, identify the service behind the existing record first. A hostname cannot generally point to two competing destinations of the same record type. Preserve the old value somewhere safe, plan the cutover window, and make the replacement deliberately.

3. Know what A records, CNAMEs, and forwarding actually do

DNS setup becomes much less risky once you separate three similar-looking actions.

An A record maps a hostname to an IPv4 address. Some platforms provide A records for an apex domain because standard DNS rules make the root domain different from an ordinary subdomain. An AAAA record does the same job for IPv6 and can conflict with an intended setup if it sends visitors elsewhere.

A CNAME record maps one hostname to another hostname. It is commonly used for subdomains such as go.example.com. If your landing page builder with custom domain support tells you to create a CNAME, use its supplied target exactly. Do not substitute an IP address from another vendor’s documentation.

Domain forwarding is a redirect service. It sends a visitor from one URL to another after they reach the forwarding provider. Forwarding is useful for a deliberate redirect, such as sending www.example.com to example.com. It is not a substitute for DNS mapping when your platform needs to verify and serve your domain itself.

Changing nameservers is different again. Nameservers delegate control of the entire DNS zone. Switching them just to connect one landing page can disconnect existing records unless you recreate every required record at the new provider.

The safe rule is simple: do not change nameservers and do not use a registrar redirect unless the platform’s current connection guide explicitly calls for it. Platform-provided instructions override generic examples because targets and verification methods can change.

4. Connect the preferred hostname, alternate hostname, and canonical redirect

Choose one public version of the address and make every other supported version redirect to it. This avoids split analytics, duplicate content, and paid clicks landing on different URLs.

For a root-domain launch, choose either example.com or www.example.com as the preferred hostname. Configure the other version as a permanent redirect where your platform supports it. For a campaign subdomain, do the same thinking: if go.example.com is the destination, do not also publish the same campaign at campaign.example.com unless you have a clear redirect plan.

Most platforms ask you to add the domain in their dashboard before DNS verification can begin. Complete that step first, copy the current records, and then add them at the authoritative DNS provider. Do not assume that a record set intended for one vendor works for another.

Webflow is the best general recommendation here if the landing page may become part of a broader marketing site. Its domain connection flow is designed around adding domains, entering the required DNS records, verifying the connection, and selecting a default domain. Use the current values shown in your project settings, particularly when connecting the apex and www versions.

After DNS resolves, set the canonical behavior in the platform rather than relying on accidental registrar forwarding. Check the final browser address after visiting both versions. The test passes only if each alternate version lands on the one URL you selected, over HTTPS, without a redirect loop.

5. Follow the platform-specific connection path, not a copied record set

Carrd, Unbounce, Webflow, and HubSpot all support custom-domain publishing through their own account and domain settings, but the supplied targets, verification steps, and URL behavior are not interchangeable.

Carrd is best suited to simple single-page campaign sites. You add the custom domain in the site’s publishing settings and manage the required DNS records at your own provider. It is a good fit for a compact page with a focused message, but the buyer still owns the DNS work: finding the live zone, entering the exact records, and checking the final hostname.

Unbounce connects domains and subdomains for campaign publishing. Before changing DNS or routing settings, map your intended campaign URL structure against the existing site. A collision between a new campaign hostname, an existing site route, and an old redirect can send traffic somewhere unexpected. Follow Unbounce’s current domain instructions for its supplied target records; generic targets from another platform may be wrong. Test the published page at its final path and confirm every redirect is deliberate.

HubSpot requires you to connect the relevant domain or subdomain in its domain and URL settings, then create the DNS records HubSpot provides and complete verification before assigning that domain to a landing page. A hubspot landing page custom domain setup should also be checked against existing website, blog, and email-related domain configuration in the account.

If you move a page between platforms, repeat or review domain setup. Removing an old record, changing the default domain, or carrying over a forwarding rule can break the new destination even after the page itself is published.

6. Treat verification and SSL as separate launch gates

A DNS lookup returning an answer does not mean your campaign is ready for paid traffic.

First, the platform must verify that it can serve the hostname. Depending on the provider, that may mean detecting the A or CNAME record, checking a TXT verification record, or both. Complete the verification in the page builder instead of stopping after you save the DNS change.

Second, wait for SSL provisioning and test the secure version of the URL. Type https:// explicitly on a phone and on a desktop browser. Look for these failure modes:

• •A certificate warning or browser privacy error.
• •HTTP working while HTTPS fails.
• •The root domain and www version resolving to different destinations.
• •A redirect loop between the registrar, CDN, and page platform.
• •The page loading at the hostname but not at the campaign path used in ads.

DNS propagation can be quick or take longer depending on record TTLs, cached resolvers, and a provider’s verification checks. Do not interpret one successful result from your own network as global confirmation.

Custom domains also do not create consent, tracking, or email-deliverability compliance. You still need to review your consent language and tracking configuration, make sure analytics tags are firing as intended, and verify any email follow-up system separately. A secure branded URL is useful, but it does not solve the legal or operational work around the campaign.

7. Run a staged launch checklist before you turn on ads

Do not connect a domain five minutes before a campaign starts. Use a staged launch, ideally with enough time to fix a DNS conflict without pausing media spend.

1. •Connect the domain in the platform. Copy its current record instructions, then save a record of what existed before the change.
2. •Add the required DNS records. Remove or replace conflicts only after confirming they do not serve a website, email service, or verification workflow.
3. •Wait for propagation and platform verification. Confirm the dashboard reports the domain as connected and SSL as active.
4. •Test the preferred URL and every alternate. Check HTTP to HTTPS behavior, apex-to-www behavior where relevant, campaign subdomain behavior, and the exact final path.
5. •Test on mobile and desktop. Open an incognito window as well. Cached browser sessions can hide redirect or certificate problems.
6. •Submit a real test form. Confirm the thank-you state, CRM destination, notification email, and any automation that should follow.
7. •Verify analytics and ad URLs. Confirm the ad destination matches the canonical live URL and that your analytics implementation records a test visit according to your own setup.
8. •Publish campaigns last. Only then enable ads, send email traffic, or update high-visibility links.

This sequence prevents the common failure where a page looks fine in the builder preview but fails at the public, paid-media URL. Keep a rollback plan: know which old record or routing rule restores the prior site if the cutover fails.

8. Fill the gap between a template builder and a full site rebuild

There is a distinct buyer need between “pick a template and publish” and “rebuild the whole marketing site.” You may want a page designed from a brief, not assembled block by block, while still needing a real domain and a repeatable content model.

floow.design fits that gap for teams creating a polished campaign page from a prompt, iterating it by chat, then publishing to a hosted subdomain or their own domain. Its built-in CMS can bind collections such as case studies, locations, or posts to a page template, so each item becomes its own page. Teams that need to host code themselves can export to React and Tailwind.

The SEO basics to check remain practical rather than magical: crawlable HTML headings, fast static pages, a unique title and meta description for each page, sensible canonical URLs, clean slugs, sitemaps, and CMS items that become separate indexable URLs. None of those guarantees rankings; they make it possible for search engines to access and interpret the page.

This is not the choice for every buyer. Pick Unbounce over a simpler new-site workflow if conversion testing is your main job. Pick Webflow if you need deeper CMS and interaction control. Pick WordPress when plugin breadth is the deciding factor.

If your actual need is a designed campaign page, a custom domain for landing page publishing, and repeatable content without assembling a full site stack first, floow.design is the more direct handoff.

Custom-domain setup differences for common landing page platforms

What it costs

A domain name, DNS hosting, and landing page publishing are separate purchases or plan entitlements. Many builders reserve custom-domain publishing for paid site plans, while domain registrars charge separately for registration and may bundle DNS management. A free landing page with custom domain is therefore uncommon: a free builder tier may publish to a branded subdomain, but your own domain usually requires a paid plan. Published plans and inclusions change, so check each vendor’s current pricing and domain documentation before buying.

Mistakes that cost you the most

Editing DNS at the registrar when a CDN or hosting provider is authoritative.

Check the domain’s nameservers and edit the DNS zone at the provider those nameservers use.

Deleting a conflicting record without identifying its purpose.

Check whether it serves an existing site, email authentication, inbox delivery, or a domain-verification workflow before replacement.

Using domain forwarding when the platform requires an A record or CNAME.

Use the record type and exact target supplied by the platform; use forwarding only for intentional URL redirects.

Launching ads as soon as the domain resolves.

Wait for platform verification and SSL, then test canonical redirects, the final path, forms, analytics, and ad destination URLs.

Frequently asked questions

Does a landing page need a domain?

A landing page does not technically need its own domain because most builders can publish it on a platform-provided subdomain. A custom domain is usually the better choice for paid campaigns, brand consistency, and control over the public URL. Use a subdomain when your main website must remain on its current platform, and use the root domain only when the landing page becomes the primary site.

How do I connect a custom domain to a landing page?

To connect a custom domain to a landing page, add the intended hostname in your landing page platform, copy its current DNS instructions, and add those records at the authoritative DNS provider. Then complete the platform’s verification and SSL steps, choose a preferred hostname, configure redirects from alternate versions, and test HTTPS, forms, analytics, and the final campaign URL before sending traffic.

Can I use a custom domain for a free landing page?

You can own and use a custom domain, but a free landing page with custom domain publishing is not always available. Many landing page builders allow free publishing only on a branded subdomain and reserve custom-domain connections for paid plans. You also need to pay separately to register and renew the domain. Check the vendor’s current plan rules because domain entitlements change.

How long does it take for a landing page custom domain to work?

A landing page custom domain can begin resolving quickly, but full readiness can take longer because DNS caches, record TTLs, platform verification, and SSL provisioning are separate steps. Do not launch based on one successful browser test. Wait until the platform reports the domain verified and SSL active, then test the canonical URL and redirects from multiple devices or networks.

How do I set up a HubSpot landing page custom domain?

To set up a HubSpot landing page custom domain, connect the relevant root domain or subdomain in HubSpot’s domain and URL settings, then create the DNS records HubSpot currently provides at the authoritative DNS provider. Wait for HubSpot to verify the connection and provision SSL, assign the connected domain to the landing page, and test the final URL, redirects, form submission, and tracking before publishing campaigns.

Should my landing page use a root domain or subdomain?

Use a subdomain for a landing page when your main website needs to remain on a different platform or when you want campaign isolation, such as go.example.com. Use the root domain only when the landing page should become the primary website. A dedicated campaign domain is useful for an isolated launch, but it adds another domain to manage, renew, secure, and measure.

Why is my custom domain not showing my landing page?

A custom domain may not show your landing page because DNS was edited at the wrong provider, a conflicting A, AAAA, or CNAME record still routes the hostname elsewhere, the platform has not verified the domain, or SSL is still provisioning. It can also be a routing issue: the hostname works but the intended campaign path redirects to an old site or a different page.

Where this leaves you

A custom domain connection is a launch workflow, not a copy-and-paste task. Choose the hostname strategy first, protect existing DNS services, use only current vendor instructions, and prove the live URL works before traffic arrives. If you need to create a designed campaign page from a prompt, publish it on your own domain, and manage repeatable content from the same page-template workflow, floow.design is built for that narrower job.

---

Design the page before you commit to a builder

You need to create a polished campaign landing page from a prompt, connect it to your own domain, and keep repeatable campaign content managed from the same page-template workflow without assembling a full site stack first.

If that is roughly your situation: describe the page in plain English and floow.design designs it as a full-height desktop layout, takes your changes by chat, keeps repeatable content in a built-in CMS, and publishes it to a floow.design subdomain or your own domain. You can still export the result to React and Tailwind if you would rather host it yourself.

Design your landing page now →

---

Free tools you can use right now

• •Font Pairing Tool — free, no sign-up
• •CSS Grid Generator — free, no sign-up
• •Type Scale Generator — free, no sign-up

Related reading

• •Free Landing Page Builder With a Custom Domain: The Catch
• •Best Landing Page Builders for SaaS Products
• •SEO Landing Page Best Practices and the Builder to Match
• •Best AI Landing Page Builders, Ranked by What Ships