White-Labelling and Custom Domains for SaaS

White-labelling a SaaS product means letting your customers present it as their own: their logo, their colours and, most importantly, their own domain. A custom domain like jobs.acme.com instead of acme.yourapp.com is the part their users notice first, and the part that's hardest to fake.

Imagine you've built a great platform, but when your clients share it with their users, it's under a domain that shows your brand, not theirs. It's like they're inadvertently promoting you more than themselves. A bit awkward, right? White-labelling and custom domains fix that. They let your clients present your platform as part of their own brand, while you keep running it.

In this guide:

• What white-labelling means for a SaaS product
• Why the custom domain matters most
• Two examples: storefronts and email links
• What to white-label, beyond the domain
• Should white-labelling be a paid feature?
• How to add custom domains to your SaaS

What white-labelling means for a SaaS product

White-labelling lets your clients rebrand your platform so it looks and feels like their own. Instead of your logo and branding, their users see theirs. Their users never have to wonder whose product they're using, and the client's brand stays front and centre.

It comes in degrees:

• Light branding: the customer uploads a logo and picks colours. Your name is still in the URL, the emails and the footer.
• Custom domain: the product runs on a domain the customer owns, with its own HTTPS certificate.
• Full white-label: nothing mentions you. Not the domain, not the emails, not the login page, not the "Powered by" link. Agencies and resellers need this, because their clients shouldn't know which vendor they use.

Most SaaS products start with light branding and add custom domains when bigger customers ask for them.

Why the custom domain matters most

Logos and colours change what users see. The domain changes what they trust. It's in the address bar, in every shared link and in every email, so it's the first thing that gives a vendor away.

A custom domain does a few things the other branding can't:

• It looks like their product. status.intercom.com reads as part of Intercom. intercom.statusvendor.com reads as a tool Intercom rents.
• It builds their brand in search, not yours. Pages on their domain help their own domain's presence, which is often why they want it.
• It survives a vendor switch. If they ever move off your product, the URLs their users know keep working, so they're more willing to commit to you in the first place.
• It's often required. Enterprise security teams, SSO setups and agencies' clients regularly insist on it.

Two examples: storefronts and email links

Example 1: an e-commerce platform

Let's take a hypothetical e-commerce platform named ShopStar. Before custom domains, a client named Elegant Styles has a store at shopstar.com/elegantstyles. Another client, Tech Haven, has shopstar.com/techhaven.

With custom domains, Elegant Styles switches to store.elegantstyles.com and Tech Haven to shop.techhaven.com. It looks cleaner, it puts their brand first, and the traffic builds their own domain instead of ShopStar's.

Example 2: link tracking for an email service provider

Imagine you run an email service provider, MailMagnet. Thousands of businesses send newsletters and transactional email through you, and you offer link tracking so they can see what recipients click. Every tracked link looks something like track.mailmagnet.com/xyz123.

That causes two problems. The links don't match your client's brand: every time a recipient hovers over one, they see mailmagnet instead of a name they recognise. And a link domain shared by thousands of senders shares their reputation too, good and bad.

With custom domains, those links become track.brandA.com/xyz123 for Brand A and links.brandB.com/abc456 for Brand B. Recipients see a domain they recognise. And each client's link reputation is their own: if one customer abuses the service, only their domain suffers, while everyone else keeps sending as usual.

Real examples

Here's how some of our customers use it:

• Dropboard, a hiring platform, offers branded hiring portals for recruiters and job board entrepreneurs. White-label domains are a premium feature for its higher-tier customers, on both subdomains and root domains.
• Memberstack, an auth and payments platform for Webflow sites, moved its sign-in screen from memberstack.com onto each customer's own domain, so users never leave the customer's brand to log in.
• Job Boardly lets entrepreneurs launch their own job boards on their own domains. After it moved custom domains to us, its co-founder says domain support requests went down by about 90%.

What to white-label, beyond the domain

Once the domain is theirs, the next thing that gives you away is usually an email. Here's the full list to work through:

You don't need all of it on day one. Do the domain and login pages first; they're what users see most.

Should white-labelling be a paid feature?

Usually, yes. Custom domains cost you something per domain (certificates, proxying, support), and the customers who ask for them are often the ones on bigger plans: agencies, enterprises and resellers. A common pattern is to include custom domains in a higher tier and save full white-labelling, with no mention of the vendor anywhere, for the top tier or an add-on.

Dropboard is a good example: it added white-label domains as a premium feature for its higher-tier customers.

Whatever you choose, make the setup self-serve. If every new domain needs your team on a call about DNS, the feature costs more in support than it earns.

How to add custom domains to your SaaS

Under the hood, a custom domain needs four things:

1. The customer points their domain at you, with a CNAME for subdomains or A records for root domains.
2. You verify they control it.
3. You issue and renew an HTTPS certificate for it.
4. Your app works out which customer each request belongs to, from the hostname.

Our guide to custom domains for SaaS walks through each step and what breaks in production. For code, see the walkthroughs for Ruby on Rails, Django and Node.js.

If you'd rather not run the certificate and proxy infrastructure yourself, SaaS Custom Domains does it for you. Your customers point their domain at us, and we issue the certificate and forward traffic to your app. We can also email your customers step-by-step DNS instructions, and you can white-label our CNAME target so it's on your domain too. Pricing is $0.29 per domain per month, with a $29/month minimum for your first 100 domains.

Frequently asked questions

What is a white-label SaaS?

A SaaS product that customers can rebrand and present as their own. At a minimum that's their logo and colours; a full white-label also runs on their own domain and removes every mention of the original vendor.

What's the difference between white-labelling and a custom domain?

A custom domain is one part of white-labelling: the product runs on a domain the customer owns. White-labelling also covers logos, emails, login pages and anything else that shows your brand.

Do custom domains help SEO?

They help your customer's SEO. Content on their own domain builds their domain's presence in search. On a subdomain or path of yours, it builds yours.

How much does it cost to offer custom domains?

Certificates from Let's Encrypt are free. The cost is the proxy infrastructure, monitoring and support. Building it yourself means servers and engineering time; managed services charge per domain, for example $0.29 per domain per month at SaaS Custom Domains.

Conclusion

Logos and colours are nice to have, but the domain is what your customers' users actually see and trust, whether you run a storefront builder, an email platform or a job board. That's why it's usually the first white-label feature worth building.

Ready to offer it? Start a 7-day free trial of SaaS Custom Domains, or book a 15-minute demo.