Subdomains and Custom Domains: How They Work in a SaaS Platform

A customer wants to feel at home in your product. A subdomain with their name does that. Their staff and clients also find it easier to remember.

Some customers go further. They want their own domain, such as portal.theircompany.in. This looks professional on emails and printed material.

Both options are common in a multi-tenant product. The platform serves them from one application.

A wildcard DNS record sends every subdomain of your domain to the same server. The application reads the host name on each request. It then looks up which tenant owns that name.

The tenant is found once, at the start of the request. Everything after that, such as data, settings and branding, is scoped to that tenant. A wrong lookup would show one customer another’s data, so this step needs careful tests.

A wildcard certificate covers all subdomains under one name. New customers can then start at once, without waiting for a new certificate.

A custom domain needs a few more steps. The customer owns the name, so they must change records at their own registrar. Usually they add a CNAME record that points to your platform.

Your platform then checks that the record exists. It also asks for proof of ownership, often through a verification record. Only after that does it accept traffic for that name.

A certificate must be issued for each custom domain. Many platforms automate this and renew it before expiry. Without automation, someone must track every renewal by hand.

DNS changes take time to spread, so a customer may keep seeing the old site for a while after they update their records with the registrar. Your help page should say this plainly and show the exact record to add.

Reserved names need care, because a customer who takes the name of a system page can confuse users and break links that the platform itself depends on. Words such as admin, api or www should not be given to customers. Names that look like another brand can also cause trouble.

Cookies are a quieter risk. A cookie set on the main domain can reach every subdomain. Session handling should be tested so one tenant’s session cannot cross into another.

Start with the customer’s view. Can they pick a name, see it work, and add their own domain without a ticket? A support-only process will not scale past a few customers.

Then test the edges of the flow, where most real problems appear once many customers have signed up and started using the platform each day. Try an unknown host name, a removed tenant and a domain whose record is wrong. Each should show a clear page, not an error or another tenant’s data.

Finally, plan for exit. When a customer leaves, the domain should stop resolving to their data and the name should be freed.