Custom domain
A domain a customer points at a SaaS product so their content serves under their own brand instead of the SaaS's default URL.
A custom domain is any hostname your end-user controls (shop.acme.com, hello.janesbakery.com) that resolves to your SaaS rather than a generic subdomain you assigned them (acme.yourapp.com).
Why SaaS products offer custom domains
Three reasons that come up over and over:
- Branding. Your users want their URL to look like their company, not yours.
janesbakery.comreads as Jane's site.janesbakery.yourapp.comreads as a tenant on someone else's platform. - Email and SSL parity. Custom domains make customer-facing emails (
hello@janesbakery.com) match the URL. Browsers show a clean lock icon for the customer's domain, not yours. - Trust signal. Letting customers use their own domain says you trust them with their identity, and counterintuitively keeps them around longer because leaving is cheaper.
What's involved technically
For each custom domain you accept, you typically need:
- DNS routing. The customer adds a CNAME (or A record) pointing their domain at your edge.
- TLS certificate. You issue + auto-renew a cert for their hostname so HTTPS works.
- Request routing. When a request comes in for
janesbakery.com, your edge looks up which customer owns it and serves their content. - Monitoring. DNS records change. Certs expire. You need to know when a customer breaks their own setup before they email support.
Most SaaS teams build the first version of this themselves with Let's Encrypt and a custom proxy, then realize they're maintaining a CA-adjacent project, and either keep grinding or hand it off to a custom-domain API.
See it in practice
Domainee's custom-domain API handles all four of those concerns behind one REST call. Customer hands you a hostname, you POST it, we hand back a single CNAME for them to set. Cert is minted on the first request to the domain.