Custom Domain vs Subdomain: What's the Difference?

A subdomain is a section of a domain you already control, such as app.example.com. A custom domain is a separate domain your customer owns and points at your product, such as portal.customerbrand.com. Subdomains are free and instant but carry the parent brand. Custom domains take a little more setup and put the owner's brand front and center.

The two terms, defined

A subdomain is a prefix on an existing domain. If you control example.com, you can create blog.example.com, docs.example.com, or anything.example.com with a single DNS record. There is nothing to register and nothing to renew. The subdomain inherits the parent domain's ownership, reputation, and constraints.

A custom domain is a domain someone registers and controls themselves, then connects to a product that hosts the actual content. In SaaS, the phrase almost always means this: your customer owns customerbrand.com and wants your product to answer at shop.customerbrand.com instead of customerbrand.yourplatform.com. The same pattern is often called bring your own domain.

The confusion comes from the fact that a custom domain is frequently itself a subdomain. shop.customerbrand.com is, technically, a subdomain of customerbrand.com. What matters is not the shape of the name but who owns the parent: your platform, or your customer.

Custom domain vs subdomain at a glance

	Subdomain	Custom domain
Branding	The parent brand appears in every URL, invoice, and shared link.	The owner's brand is the address. The platform disappears.
SEO	Links and authority accrue to the parent domain. Reputation is shared with every other tenant on it.	Authority accrues to a domain the owner keeps, even if they change platforms later.
Trust	Reads as hosted. Fine for docs and internal tools, weaker on a checkout page.	Reads as an established business with its own address.
Cost	Free once the parent domain exists.	A domain registration, typically 10 to 20 dollars a year for common TLDs.
Control	DNS, TLS, and policy belong to whoever owns the parent domain.	The owner controls DNS and can point the name anywhere, at any time.
Setup effort	One DNS record, created by whoever runs the parent zone. Instant.	Ownership verification, DNS records, and TLS. Seconds with managed tooling, hours by hand.

When a subdomain is fine

Subdomains earn their keep when the audience already knows whose product it is, or does not care:

• Internal and supporting surfaces. docs., status., staging., and admin. belong on your own domain. Nobody expects a status page to have its own brand.
• Default tenant addresses. Giving every new signup name.yourplatform.com gets them live immediately, before they have bought a domain or thought about one.
• Experiments and prototypes. A weekend project does not need a registrar account and a renewal reminder.
• Structuring a single brand. blog., shop., and app. on one domain keep concerns separate without splitting the brand.

When a custom domain wins

The moment a page represents someone else's business, the calculus flips:

• Storefronts, portals, and published sites. A visitor who sees your platform's name in the URL is being told, correctly, that this business runs on rented infrastructure. The customer's own domain removes that signal.
• Anywhere money changes hands. Checkout pages, invoices, and client portals convert better when the address matches the brand the buyer already trusts.
• Durable content. Links, bookmarks, and citations accumulate over years. On a custom domain, the owner keeps all of that equity even if they move platforms.
• White label work. Agencies and resellers cannot put a client's site on the agency's domain, let alone the platform's. Their whole model depends on custom domains. See Custom Domain for agencies.

What this means for SaaS platforms

For a platform, this is not a choice between the two. Mature platforms run both, in sequence.

Tenant subdomains are the default. Every signup gets name.yourplatform.com from a wildcard DNS record and a single wildcard certificate. It costs nothing per tenant and works before the customer has decided whether they are serious. The tradeoff is concentration: every tenant shares your domain's reputation, so one tenant who attracts a phishing report or a spam flag can weigh on the domain that every other tenant sits on.

Customer custom domains are the upgrade. As tenants grow into real businesses, they want their own name on the door. Technically this is a different problem from the wildcard case. Each domain needs ownership verification, its own DNS records (a CNAME for subdomains, an apex strategy for root domains, covered in apex domain vs CNAME), and its own certificate, issued and renewed per domain rather than from one wildcard. Serving thousands of these from shared infrastructure is its own discipline; see multi-tenant TLS.

The hard part is not deciding to offer custom domains. It is the operational tail: walking customers through DNS instructions for dozens of registrars, catching typos, retrying verification, and renewing certificates forever. That tail is what managed custom domain infrastructure exists to absorb. Custom Domain detects the customer's DNS provider (63 providers supported), configures records through one-click provider authorization, an API token, or a guided manual flow that verifies automatically, then issues and renews TLS on its own. A domain typically goes live in about 30 seconds. Under the hood, a control plane handles verification and DNS while a reverse proxy edge terminates TLS with strict tenant isolation; the details are on how it works.

The migration path: subdomain to custom domain

Moving a tenant from name.yourplatform.com to their own domain is routine when you sequence it correctly:

1. Keep the subdomain live. It becomes the fallback during the switch and the redirect source afterward. Do not tear it down.
2. Verify ownership of the new domain. Proof, usually a TXT record or provider authorization, prevents anyone from claiming a domain they do not control.
3. Point DNS at the platform. A CNAME for subdomains. Apex domains need ALIAS, ANAME, or A records depending on the provider.
4. Issue TLS before switching traffic. The certificate should exist before the first visitor arrives, not after. See automating TLS for customer domains.
5. Redirect the old subdomain. A permanent redirect from the subdomain to the custom domain keeps old links working and passes most search equity. Leave it in place indefinitely.
6. Update canonicals and sitemaps. Search engines should see exactly one authoritative address: the new one.

Done in this order, the switch is invisible to visitors. Done out of order, you get certificate warnings, broken links, and split indexing while search engines decide which address is real.

The short version

Use subdomains for your own surfaces and for day one tenant addresses. Offer custom domains the moment your customers' brands are on the line, and treat the upgrade path as part of the product. If you are weighing how to build that, start with adding custom domains to your SaaS, browse the API docs, or start free.