How to add a custom domain to a static website preview

To add a custom domain to a static website preview, create a CNAME record at your DNS provider that points a subdomain such as sites.example.com at the host's target, then wait for the host to verify the domain and issue a TLS certificate. Once both the hostname and its certificate are active, the branded address serves the same preview as the host's default URL.

For a subdomain, the usual setup is a CNAME followed by the host's verification process. The host gives you the target and manages the certificate.

How a custom domain reaches a static host

A custom domain is a name you own that resolves to someone else's server. You keep the domain at your registrar or DNS provider; you just add a record that hands off one hostname to the host.

The record you add is a CNAME. A CNAME aliases one domain name to another, so sites.example.com becomes an alias for the host's target. When a browser looks up your subdomain, DNS follows the alias to the host, and the host answers for that name. That is why you can serve a preview on your own brand without moving your whole domain anywhere.

Every DNS record carries a TTL, the time resolvers are allowed to cache the answer. TTL is why DNS changes are not instant: after you add or edit a record, resolvers that already cached the old answer keep using it until the previous TTL runs out, and some networks hold a copy longer than that. A lower TTL set ahead of a change shortens the wait; it does not eliminate it.

Serving over HTTPS needs a certificate for the hostname, and the host issues one only after it confirms you control the name. Hosts do this with domain control validation. HTTP validation is common and requires the hostname to already point at the host before the certificate can be issued, which is the practical reason the domain shows "verifying" for a while after you add it: the record has to resolve first.

Use a subdomain unless your DNS provider supports apex routing

This guide uses a subdomain, sites.example.com, rather than the bare example.com. A subdomain takes a plain CNAME cleanly, and it keeps the preview separate from whatever runs on your main site. PreviewSend accepts custom hostnames, but root (apex) DNS routing depends on your provider: some support CNAME flattening, ALIAS, or ANAME records, while others do not. Use an apex hostname only if your DNS provider can route it to the target; otherwise pick a subdomain you can dedicate to client previews.

Add a custom domain to a static website preview in PreviewSend

PreviewSend follows that same model with a fixed target. Before you start, make sure the site you want to brand is already live as an active project; the domain has to attach to a real preview, so turn your build into a hosted URL first if you haven't.

1. In your DNS provider, add a CNAME record for the subdomain you chose (for example sites) pointing at cname.previewsend.com. Save it, and if your provider lets you, set a shorter TTL while you're setting up.
2. In PreviewSend, open Settings → Domains, add the full hostname (for example sites.example.com), and select the active project it should serve. A workspace owner has to do this, the domain and project must be in the same workspace, and the hostname has to be one you own; PreviewSend and reserved hostnames are rejected.
3. Let it verify. PreviewSend registers the hostname with Cloudflare for SaaS, which validates control over HTTP and issues a certificate at a minimum of TLS 1.2. The domain serves only once both the hostname and its certificate report active.

While that runs, the domain status reads "verifying," and a request to the custom address can return a not-found response until it flips to active. That can be normal during propagation. If it persists, check the DNS values below.

The DNS values at a glance

Verify the domain and troubleshoot

Confirm the setup the way a client will reach it, not just that PreviewSend shows a green status.

When it's still not serving, check the CNAME first. A stray www, a typo in the target, or a record created at a different hostname will not configure sites.example.com. The value has to be exactly cname.previewsend.com on the subdomain you added in PreviewSend. Remove any conflicting A or AAAA record at that same name; a CNAME cannot share a hostname with another record. If you intentionally use the root domain, follow your DNS provider's instructions for CNAME flattening, ALIAS, or ANAME routing instead.

If you edited an existing record, resolvers may still return the previous answer until the old TTL expires. Recheck with dig, wait according to the TTL and your network's caching, then retry rather than adding more records.

If PreviewSend shows the domain as failed rather than verifying, remove it and add it again. If it fails again with the DNS record already correct, contact support rather than waiting on the TTL; the hostname did not register successfully with the certificate provider.

The certificate can only be issued after the hostname resolves to the target. PreviewSend re-checks a given domain at most about once a minute, but DNS timing varies, so there is no useful fixed promise such as "ready in 60 seconds." Give DNS time, then reload.

Check the plan and project before adding the domain

A custom domain is an additional route, not a replacement for the PreviewSend URL, which keeps working.

Custom domains are on paid Starter, Pro, and Agency plans. The 14-day Pro trial does not include them, so you need to move to a paid plan before adding one. Starter includes one custom domain, Pro twenty-five, and Agency fifty. Free has none.

Only a workspace owner can add or remove a domain. The selected project must be active, unexpired, and in that same workspace.

Because the custom domain serves through the same pipeline as the slug URL, the controls you already set travel with it. The password gate, project expiry, the account-free review overlay and its endpoints, stable same-project updates, SPA fallback, and the noindex, nofollow header all apply on the branded address too. Two caveats: a restrictive Content Security Policy in your own uploaded site can block the review overlay, and noindex asks supporting search engines not to list the page, which is not access control. A branded domain doesn't make a preview private, so keep a server-side password on anything that shouldn't be public.

Where a custom domain fits in the workflow

A custom domain is the last polish on a preview you're already running, not a new place to host. It points at the project you set up when you turned a ZIP or build folder into a live URL, and it rides along with the address you keep when you update the static site in place without changing its URL. Ship a new build to the same project and the custom domain serves it next, no DNS changes and no re-verification.

Set the CNAME once, let it verify, and the client sees sites.example.com while you keep uploading revisions behind it. If you want a branded preview to hand to a client, create a PreviewSend project on a paid plan and add the domain from Settings once the site is live.