When a customer connects their own domain to your white label product, someone has to decide which name they type: app.customer.example, www.customer.example, or customer.example itself. In a settings screen the three look interchangeable. They are not. The choice affects how far a session cookie travels, which other sites share a browser boundary with yours, who can claim the name if the customer leaves, which certificate authority the customer's DNS must allow, and whether sign-in keeps working when someone changes their mind later.
We make CustomDomain™, a product of EverJust Company in Minneapolis: a widget that SaaS platforms embed so their customers can connect their own domains, with DNS automation, certificate issuance and a reverse proxy edge behind it. This post is on our blog, so it may lean our way. Every number or rule below links to its source, and where we only have our own reading of a standard, we say so. For the wider picture, start with our white label domain pillar page. This post covers one narrow question.
Three hostnames, three different jobs
A subdomain is a name with a label in front of the customer's registered domain, like app.customer.example. The apex is the bare registered name with nothing in front. Our apex domain vs CNAME page covers the DNS mechanics: a subdomain can point at a platform with a CNAME, the apex cannot, and some DNS hosts offer a workaround of their own. We will not repeat it. The DNS difficulty is the least interesting difference; the security ones are larger, and people find them late.
Cookie scope: Domain attribute or host-only
Under RFC 6265 section 4.1.2.3, a cookie set with Domain=customer.example is sent to that domain and every subdomain under it. A cookie set without a Domain attribute is host-only, so it goes back only to the exact host that set it.
If your session cookie is host-only, the hostname you serve it from is the whole blast radius, whichever of the three names the customer chose. If your code sets a Domain attribute to the customer's registered domain, the cookie is also sent to the customer's marketing site, their blog, their support desk and any forgotten staging host under the same name. You do not control those systems and cannot audit them.
Our opinion: set session cookies host-only, and treat a Domain attribute on a customer's name as a bug. On the apex it is worse, because the apex is the parent of everything else the customer runs.
The Public Suffix List, if you hand out subdomains yourself
Many white label products also give each customer a name under the platform's own domain before they connect their own. The Public Suffix List exists so browsers can stop one party setting cookies that spill over to unrelated parties. Its guidelines let owners who issue subdomains to mutually untrusting parties request entries in the PRIVATE section. If customer-a.yourplatform.example and customer-b.yourplatform.example belong to different, untrusting customers, that is your situation, and we think it is worth requesting.
Same-site: less separation than it looks
A site is a scheme plus the registrable domain, which is a public suffix plus one label, per the MDN glossary and the HTML standard. MDN's own example is support.mozilla.org and developer.mozilla.org, which are same-site. By the same definition, app.customer.example and www.customer.example are same-site.
So if your product lives at app.customer.example and the customer's public site lives at www.customer.example, a browser does not treat them as separate sites. Any control you were counting on to keep those two apart will not keep them apart. The apex, customer.example, shares that registrable domain too.
The same logic applies to names you issue. The URL Standard table gives whatwg.github.io its own registrable domain, so platform subdomains share one site unless the platform is on the Public Suffix List. Customers on their own domains are better isolated from each other than customers on subdomains of yours. That is our inference, not wording from the standards, but it is a fair argument for steering production traffic to the customer's own name.
Dangling CNAMEs and subdomain takeover
A DNS record left pointing at a resource that no longer exists is a dangling entry, and another party can sometimes claim the resource and inherit the name. Microsoft's subdomain takeover guidance singles out CNAMEs and lists prevention steps: remove the DNS entry when you decommission a resource, use alias records, require TXT domain verification, watch for alerts, lock resources against deletion, and audit DNS regularly. It is written for Azure. We think the habits transfer, but we have not verified each one elsewhere.
Here is how that looks in a white label product. A customer points app.customer.example at your edge, then cancels, and the CNAME stays in their zone for months. Whether anyone else can claim that name on your platform depends on how your platform decides who owns a hostname. Ask that of any vendor, including us. We do not describe any product's behavior in this post.
A subdomain CNAME is the shape the guidance warns about most. Give customers a documented step for removing the record when they leave, and audit which hostnames still resolve to you.
CAA: whose records decide which CA may issue
Certificate Authority Authorization records live in the customer's DNS, not yours. RFC 8659 section 3 has the CA look up CAA for the exact name being certified, "chasing aliases" along the way, and then, if nothing is found, climb to the parent names until a record set appears. Our reading, which the Let's Encrypt CAA documentation agrees with, is that a CNAME target's CAA records apply first, and the customer's own CAA records govern only when the target has none.
Two consequences for hostname choice. With a subdomain pointed by CNAME, a customer with a locked down apex CAA may still get a certificate if the target publishes its own record set, and may be blocked if it does not. At the apex there is usually no CNAME to chase (the glossary page explains why), so the customer's own CAA records are what the CA reads. Either way, ask during onboarding whether the customer publishes CAA records at all, and tell them which CA your platform uses so they can allow it.
Rate limits at scale
Let's Encrypt's rate limits page, dated 5 August 2026, sets two limits worth knowing here. The first allows 50 certificates per registered domain per 7 days, refilling one every 202 minutes. The second allows 5 certificates per exact set of identifiers per 7 days, refilling one every 34 hours, with no overrides available. Renewals that use ARI are exempt. Check the page for current numbers before you build around these.
The first limit is why hostnames under your own domain are a scaling trap: they all share one registered domain, while a customer's own domain draws on that customer's registered domain. The second is a re-issuance limit. The page names reinstalling a client repeatedly and deleting its stored configuration on every deploy as common ways to hit it. A platform can hit it the same way if every reconnect, redeploy or retry for one customer hostname asks for a fresh certificate for the same names, so keep issued certificates and reuse them. Failed validations are counted separately, at 5 per identifier per account per hour.
OAuth redirect URIs: the reason hostname changes hurt
This is why a hostname tends to become permanent. RFC 9700 section 2.1 requires authorization servers to compare redirect URIs against pre-registered values using exact string matching, with an exception for port numbers in localhost redirect URIs of native apps. RFC 6749 section 3.1.2.3 requires simple string comparison, and section 3.1.2.2 requires public clients, and confidential clients using the implicit grant, to register their redirect endpoints.
In practice, https://app.customer.example/callback and https://www.customer.example/callback are different strings. If the customer's users sign in through an identity provider the customer configured, moving from one hostname to the other means updating the registration there, and until it is updated sign-in fails. Keep the old and new URIs registered together during a move, and avoid offering a hostname change as a casual setting. Treat the first choice as close to permanent.
Our opinion: which hostname to suggest when
This table is judgment, not a standard. Your product and your customers may justify different answers.
| Situation | Suggest | Why |
|---|---|---|
| Logged-in application area, dashboards, anything with sessions | A dedicated subdomain such as app.customer.example | Host-only cookies keep scope small; the CNAME path is simple; the customer's public site stays untouched. |
| The customer already runs a public site on the apex or www | A subdomain, never the apex | Taking the name breaks their site, and shared parent scope widens cookie exposure. |
| The product is the customer's public site (a storefront or site builder) | The apex plus www, one redirecting to the other | Visitors type the bare name. Accept the DNS work; see the apex page. |
| Customer has strict CAA records | Any, after checking CAA first | The CA must be allowed at the right level before the first issuance attempt. |
| Customer uses OAuth sign-in through their own identity provider | Decide once and register the exact URIs | Redirect URI matching is exact, so later changes break sign-in. |
| Trial or pre-connection state | A name under your own domain | Only if you have asked for a Public Suffix List entry, because those subdomains otherwise share a site. |
Two neighbouring decisions have their own posts. One is whether to host the customer's whole zone behind vanity nameservers, in which case the hostname question changes shape. The other is a branded link or tracking domain, which for the reasons above is almost always a subdomain.
How CustomDomain™ relates
CustomDomain™ is the widget, the DNS automation, the certificate issuance and the reverse proxy edge described on how it works. The hostname decision belongs to your product, and the sections above apply whichever vendor you use; we have not covered how any one product, ours included, handles each case. The free Domain Health Check is read only. If something goes wrong after a customer connects, our guide to a white label domain that is not working covers the common causes, and the white label domain overview places this choice among the others.
Frequently asked questions
Should a white label customer use a subdomain or the root domain?
For a logged-in application, we suggest a dedicated subdomain. It keeps the customer's existing site untouched and lets you use a plain CNAME. Use the root domain when the product is itself the customer's public site, and expect more DNS work there.
Are www and app on the same domain treated as the same site?
Yes. A site is the scheme plus the registrable domain, so app.customer.example and www.customer.example are same-site, just as MDN's example of two mozilla.org hosts is. Do not rely on the hostname split to separate them.
Does a CNAME target's CAA record or the customer's apex CAA record apply?
Our reading of RFC 8659 section 3 is that the target's records apply first, and the climb to the customer's parent domain only happens if there are none. The Let's Encrypt CAA page agrees. Ask each customer whether they publish CAA at all.
How many Let's Encrypt certificates can a platform issue per week?
The rate limits page, dated 5 August 2026, lists 50 per registered domain and 5 per exact identifier set, each per 7 days. ARI renewals are exempt. Hostnames on customers' own domains spread across many registered domains.