# Custom domains for SaaS: a production guide
Canonical source: https://approximated.app/blog/custom-domains-for-saas-guide/
Author: Approximated
Published: 2026-06-30
Last reviewed: 2026-09-28
**Short answer:** a SaaS custom-domain feature is a lifecycle, not a DNS field. You need to decide which customer may claim a hostname, give them the right DNS record, prepare HTTPS, route the request to the correct tenant, and keep checking the connection after launch. A domain is ready only when the application answers on that hostname over valid HTTPS. We built Approximated to make this production path easier to ship and operate, from your first customer domain to a large SaaS fleet.
## The request path you're building
A visitor types `shop.customer.example`. DNS sends the request to an edge proxy. The proxy selects a certificate for that hostname, terminates TLS, and sends the request to your application. Your application resolves the hostname to a tenant and renders that tenant's content. The edge doesn't replace your application's tenant authorization.
1. **Customer claim:** your application records the hostname, the tenant that requested it, and the person allowed to change it.
2. **Edge configuration:** register the exact hostname and its application target with your proxy or custom-domain API.
3. **DNS change:** the customer publishes the record your onboarding flow specifies.
4. **TLS and routing:** wait for a certificate, then verify a real request reaches the intended tenant.
5. **Ongoing care:** detect DNS drift, certificate trouble, ownership changes, and deletion.
These steps can finish in different orders. A successful API response means the configuration was saved; it doesn't prove DNS, a valid certificate, or a working origin. We expose those concerns separately through our [virtual-host monitoring](https://approximated.app/docs/#virtual-host-statuses), so your product can explain exactly what is ready and what needs attention.
## Choose a DNS path customers can actually use
For a subdomain such as `shop.customer.example`, a CNAME to a stable hostname you control gives you flexibility to move the proxy behind that target later. For the apex `customer.example`, a standard CNAME can't coexist with the zone's required records. That restriction comes from the [DNS specification](https://www.rfc-editor.org/rfc/rfc1034). Use an A record to a stable address, a DNS-provider ALIAS or flattening feature where supported, or an HTTPS redirect from the apex to `www`.
Don't give every customer the same generic instructions. Ask whether they're connecting an apex or a subdomain, then show the record name and value exactly as their DNS provider expects. Our [DNS widget and headless API](https://approximated.app/dns-widget/) give you provider-specific instructions and record checks inside your product. Your application keeps control of the tenant ownership decision.
## Treat certificate readiness as its own gate
Automated HTTPS still requires domain validation. With ACME HTTP-01, a certificate authority requests a token from the hostname over port 80. DNS-01 uses a TXT record and is the option needed for wildcard certificates. The choice affects how much DNS access or edge control you need. [Let's Encrypt documents the challenge types](https://letsencrypt.org/docs/challenge-types/); its [rate-limit guidance](https://letsencrypt.org/docs/rate-limits/) matters if you're operating issuance yourself at scale.
A customer seeing the correct DNS answer may still see a certificate delay. Don't present “connected” until an HTTPS request for the actual customer hostname succeeds. Keep a separate “securing domain” state and a retry path. If you use a managed custom-domain service, confirm who owns renewals, failure alerts, and certificate storage.
## Route by a trusted, exact hostname
Keep a table that maps normalized hostnames to one active tenant. Resolve that mapping before rendering content or issuing tenant-scoped redirects. Unknown hosts should fail closed. Behind a proxy, decide which forwarded-host headers are trusted from your own infrastructure; accepting an arbitrary client's header as the tenant key can misroute requests. Test login, email links, OAuth redirects, and cookies on a real customer domain as well as the homepage.
The [framework integration guides](https://approximated.app/guides/) cover host-based routing in several stacks. Our virtual hosts map incoming addresses to application targets, giving you one API for the edge configuration while your app selects and authorizes the tenant at that target.
## What changes when you build or buy the edge?
A self-managed proxy gives you direct control over certificates, IP addresses, geographic placement, and request handling. It also makes issuance retries, shared certificate storage, monitoring, on-call response, and capacity your responsibility. Managed services move some or all of those jobs outside your team. The right choice depends on the operational boundary you want, not only the number of domains.
With Approximated Cloud, we operate your dedicated proxy cluster, automate certificates, and give each customer cluster its own dedicated anycast IPv4 address for apex A records. You can start managed and keep a path to [hybrid or full self-hosting](https://approximated.app/self-hosted/) if your infrastructure requirements change. Hybrid keeps our cloud API and dashboard while traffic and certificates run on your infrastructure; full self-hosting provides a local API and dashboard with its own feature scope.
## The production tools we include around custom domains
We build for SaaS products with many tenants and customer hostnames. Getting a certificate is one part of that job; protecting and observing the traffic is what keeps the feature dependable after launch.
- **WAF and DDoS protection for SaaS traffic.** Our [managed edge protection](https://approximated.app/#waf) combines request inspection, traffic analysis, and shared threat intelligence with evidence from your dedicated cluster. It can challenge suspicious traffic and block qualifying attacks before they reach your app.
- **Edge Verify for forms.** Our [form protection](https://approximated.app/docs/#edge-verify) checks submissions at the edge using a script served from your own domain. Start in monitor mode, then enforce once legitimate submissions are passing.
- **Monitoring and webhooks.** We monitor domain DNS, SSL, and proxy-hit status. Our [webhooks](https://approximated.app/docs/#webhooks) let your app react to changes without building a separate monitoring service for those signals.
- **A path to your own infrastructure.** Our [published self-hosted plans](https://approximated.app/self-hosted/) give you an operating model to move toward when traffic, certificate storage, or control-plane requirements change.
- **Real engineering support and clear costs.** You can talk to [developers who understand the edge](https://approximated.app/#faq), including on-call engineers for emergencies. Our [cloud rates, minimum, bandwidth allowance, and self-hosted prices](https://approximated.app/pricing/) are public, so you can plan without enterprise pricing surprises.
Cloudflare for SaaS uses a Cloudflare zone and fallback origin; see its setup guide. Our [API selection guide](https://approximated.app/blog/best-custom-domain-apis-for-saas/) compares these paths by the production work each team needs to own.
## A production launch checklist
- Claim one hostname for one tenant; reject duplicate claims and make reassignment explicit.
- Test a CNAME subdomain and an apex domain at DNS providers your customers use.
- Confirm certificate readiness and a real HTTPS response independently.
- Exercise unknown hosts, login and redirect flows, origin failures, and domain removal.
- Keep the DNS target under your control, and tell customers how to remove stale records when they disconnect.
For a customer-facing flow, the next design step is to turn these checks into clear states. The [onboarding checklist](https://approximated.app/blog/custom-domain-onboarding-checklist/) gives a practical model. For the risks behind hostname claims and removal, read the [security guide](https://approximated.app/blog/custom-domain-security/).
## Frequently asked questions
### What is a custom domain for a SaaS application?
A custom domain lets a customer use a hostname they own, such as app.customer.example, to access their workspace in your SaaS. DNS sends traffic to your edge, HTTPS secures the connection, and your application maps the hostname to the correct tenant. We handle the custom-domain proxy infrastructure while your app keeps control of tenant identity and authorization.
### How do I add custom domains to a multi-tenant SaaS?
Record the hostname against one authorized tenant, create its edge mapping, and show the customer the exact DNS record to publish. Check DNS and certificate readiness separately, then make a real HTTPS request that confirms the expected tenant answers. Our API, DNS onboarding, monitoring, and webhooks cover the edge workflow; your application owns the tenant association.
### Can SaaS customers connect both root domains and subdomains?
Yes, if your edge supports both hostname types. Subdomains usually use a CNAME. Root or apex domains need an A record, a supported DNS-provider alias or flattening feature, or a redirect to a subdomain. Our cloud provides a dedicated anycast IPv4 address per customer proxy cluster, shared by the tenant hostnames configured in that cluster. Your customers can connect apex domains with an A record at their existing DNS provider.
### Does managed SSL mean a custom domain is ready to use?
A certificate is only one readiness check. The hostname must also resolve to the intended edge, reach a working origin, and render the correct tenant over HTTPS. We expose DNS, SSL, and proxy-hit observations separately. Use those signals for the onboarding UI and complete the check with an actual application request before marking the domain connected.
### Can I start with managed custom domains and later self-host?
We offer cloud, hybrid, and full self-hosted deployment paths. Hybrid keeps our cloud API and dashboard while traffic and certificates run on your infrastructure. Full self-hosting provides a separate installation with a local API and dashboard, and its feature scope differs. Plan the deployment, address changes, and any customer DNS migration with our engineers before moving traffic.