Custom Domains and Subdomains for Multi‑Tenant SaaS

Why Custom Domain Architecture Matters for Multi‑Tenant SaaS

In a multi‑tenant SaaS, the way you design domains, subdomains, DNS, SSL and routing directly shapes your product’s UX, security, reliability and even support workload. Tenants expect their apps to live at branded URLs like app.customer.com or even just customer.com, with valid HTTPS and no scary browser warnings. At the same time, your engineering team needs a model that is predictable, automatable and safe to operate at scale.

In this article, we will walk through practical domain and subdomain architecture patterns for multi‑tenant SaaS: how to structure hostnames, which DNS records to use, how to automate SSL for hundreds or thousands of customer domains, and how to route traffic to the right tenant cleanly. We will combine high‑level decisions (tenant URL patterns) with low‑level details (ACME challenges, SNI, ALIAS records, proxy configuration) that we see in real projects we host at dchost.com.

The goal is simple: help you design a custom domain architecture for multi‑tenant SaaS that is technically solid from day one, but flexible enough to grow with your product.

Core Domain Models for Multi‑Tenant SaaS

Before DNS or SSL automation, you must decide how tenants will access your app. Most multi‑tenant SaaS platforms end up combining two or three of these URL patterns.

1. Tenant Subdomains on Your Main SaaS Domain

This is the classic pattern:

• Global app: app.yoursaas.com
• Per‑tenant subdomain: tenant1.yoursaas.com, tenant2.yoursaas.com

Pros:

• Fastest onboarding: you own yoursaas.com, so you control DNS from day one.
• Simple DNS: usually a wildcard record, e.g. *.yoursaas.com pointing to your load balancer.
• Straightforward SSL: a wildcard certificate for *.yoursaas.com often covers all tenants on your domain.

Cons:

• Tenants don’t get their own brand domain; for many B2B products that is acceptable, for white‑label use cases it is not.
• You cannot use one tenant’s subdomain directly as an email sending domain without extra DNS work (SPF, DKIM, DMARC) and clear separation from your main brand.

For early stages, this pattern is perfect: quick to implement, easy to maintain. Later you can add custom domains without breaking existing tenants.

2. Custom Domains and Subdomains Per Tenant (BYO Domain)

Here each tenant maps their own domain or subdomain to your SaaS:

• Apex: customer.com → your SaaS
• Subdomain: portal.customer.com → your SaaS

Pros:

• Best branding: tenants can use their own domain everywhere they link to your app.
• Cleaner integration with their main website and email.

Cons:

• Need a robust onboarding and verification flow for DNS records.
• Certificate automation becomes mandatory; manually managing SSL will not scale.
• You must handle tricky cases like apex domains that can’t use CNAME records at the root.

We will go deep into DNS and SSL for this pattern, because this is where most of the complexity lies.

3. Hybrid: Shared Domain + Optional Custom Domain

Most mature SaaS products end up with a hybrid model:

• Every tenant gets a default subdomain on your domain: tenant.yoursaas.com.
• They can optionally connect a custom domain, e.g. app.customer.com, which becomes canonical.

Advantages:

• Onboarding is instant with your subdomain; they can start using the app before configuring DNS.
• Your support team still has a known working URL for each tenant even if their custom domain is misconfigured.
• You can roll out custom domain support gradually, often starting from higher‑tier plans.

When we advise SaaS teams at dchost.com, this hybrid model is usually our default recommendation: simple, safe and flexible.

DNS Design for Tenant Subdomains and Custom Domains

Once you know your URL strategy, you can design DNS. The patterns are very different for your own subdomains vs tenants’ custom domains.

Wildcard DNS for Your Own Tenant Subdomains

For tenant.yoursaas.com style URLs, you typically use a wildcard DNS record:

• *.yoursaas.com → A/AAAA to your load balancer IP, or
• *.yoursaas.com → CNAME to a front‑end hostname like lb.yoursaas.net

Key points:

• Set TTL reasonably low (e.g. 300s) so you can change IPs or load balancer targets without long propagation delays.
• Keep a separate record for app.yoursaas.com if you have a marketing site or docs on www.yoursaas.com; don’t overload one wildcard for everything.

If you want a deep refresher on DNS record types and how they behave, our article explaining A, AAAA, CNAME, MX, TXT and SRV records step‑by‑step is a good background read.

DNS Requirements for Tenant Custom Domains (BYO Domain)

When tenants bring their own domain, you typically ask them to create one or two records:

• CNAME: For subdomains like app.customer.com, you usually require a CNAME pointing to a hostname you control, e.g. customer-domains.yoursaas.com.
• TXT (verification): To confirm domain ownership, you generate a unique TXT record value like _yoursaas.customer.com with a token your system checks.

For apex domains (just customer.com, no subdomain), traditional DNS does not allow a CNAME at the root. The usual options are:

• Tenants point A/AAAA to your IPs (less flexible for you, because IP changes hurt everyone).
• Use their DNS provider’s proprietary ALIAS/ANAME or flattened CNAME feature, if available.

If you are not yet comfortable with ALIAS/ANAME and CNAME flattening at the zone apex, our deep dive on CNAME at the apex and ALIAS/ANAME strategies explains practical options with real‑world gotchas.

Designing Your DNS Onboarding Flow

From the SaaS side, you want your system to:

1. Let the tenant enter app.customer.com (or customer.com).
2. Generate and show the required DNS record(s) clearly.
3. Continuously poll public DNS for those records (respecting TTLs) until they appear.
4. Mark the domain as “verified” and trigger SSL issuance once DNS is correct.

Implementation tips:

• Perform lookups against multiple public resolvers to avoid caching issues.
• Show real‑time status to the tenant: “record not found”, “found but wrong target”, “verified”.
• Use short‑lived verification tokens so you can safely expire unused requests.

At dchost.com we often see support tickets drop dramatically once the DNS onboarding screen includes a simple “we see this record / we expected that record” diff.

SSL and Certificate Automation at Scale

Custom domains are useless if browsers show a big red “Not secure” warning. The only sustainable answer is full SSL automation, wired into your SaaS.

Per‑Tenant Certificates vs Shared Certificates

You have three main options:

• Wildcard for your own domain only: *.yoursaas.com — great for tenant subdomains on your domain, but not for custom domains.
• SAN (multi‑domain) certificates: One certificate listing many tenant domains; works for smaller numbers but hits practical limits quickly (max names, rotation overhead).
• One DV certificate per tenant domain: The most scalable model for serious SaaS products.

In practice, “one DV certificate per custom domain” is the pattern that scales best. It aligns perfectly with SNI (Server Name Indication): your reverse proxy selects the right certificate based on the requested hostname.

ACME Challenges: HTTP‑01 vs DNS‑01 for SaaS

Most modern SSL automation is based on ACME (e.g. Let’s Encrypt, ZeroSSL). You must choose how to prove domain control:

• HTTP‑01: You serve a special token at http://domain/.well-known/acme-challenge/....
• DNS‑01: You publish a temporary TXT record under _acme-challenge.domain.

For multi‑tenant SaaS with custom domains, DNS‑01 has clear advantages:

• Works even if tenants use an external CDN or WAF in front of you.
• Works for wildcard certificates (e.g. *.customer.com, though you may not always need that).
• Decouples certificate issuance from your HTTP routing logic; easier to operate at scale.

We have a dedicated article on bringing your own domain with automatic SSL using DNS‑01 in a multi‑tenant SaaS, where we go much deeper into patterns, rate limits and real automation stories.

Automating Certificate Lifecycle

A minimal per‑tenant certificate workflow looks like this:

1. Tenant adds/verifies a domain in your app.
2. Your control plane triggers an ACME client (e.g. via job queue) to request a certificate.
3. The ACME client completes HTTP‑01 or DNS‑01 and obtains a certificate + private key.
4. You store the certificate (securely) and reload your reverse proxy / ingress routing for that domain.
5. A scheduled job renews certificates proactively (e.g. 30 days before expiry) and reloads the proxy again.

Important details:

• Keep private keys on encrypted storage with strict access controls.
• Watch ACME rate limits; if you have bursts of tenants, structure requests carefully.
• Make proxy reloads graceful to avoid connection drops (e.g. zero‑downtime reloads on Nginx).

If you are choosing tooling, our article on SSL certificate automation tools and DNS‑01 strategies compares popular approaches and how they integrate with hosting panels and APIs.

SNI: Serving Many Certificates on One IP

To serve hundreds of different certificates from the same load balancer, you rely on SNI (Server Name Indication). The TLS client tells the server which hostname it wants, and the server returns the matching certificate.

This has two big consequences for your hosting design:

• You do not need one IP per tenant domain, which keeps IPv4 usage and cost under control.
• Your web server or proxy must be configured with one TLS “server block” (or equivalent) per domain, or a dynamic lookup mechanism keyed by hostname.

We explore SNI in detail in our guide to hosting multiple HTTPS websites on one IP address with SNI, which maps nicely to multi‑tenant SaaS use cases.

Routing Architecture: From Hostname to Tenant

Once DNS resolves and TLS terminates correctly, you still must route each request to the correct tenant. In a multi‑tenant SaaS this typically involves three layers: load balancer / reverse proxy, application router and data access layer.

Host‑Based Routing at the Edge

Your front‑end proxy (Nginx, HAProxy, Envoy, etc.) usually makes the first decision based on the Host header and SNI:

• Terminate TLS using the certificate that matches the host.
• Forward the HTTP request to your app cluster (often the same upstream for all tenants).

At this stage, you rarely separate tenants by upstream unless you have very large enterprise customers that require dedicated infrastructure. Most SaaS platforms share application nodes, and tenant isolation happens inside the app and database layers.

Tenant Resolution Inside the Application

Inside your app, you need a fast way to map Host to a tenant ID. Common approaches:

• A domains table containing host → tenant_id, cached aggressively in Redis or shared memory.
• Special‑case handling for your own subdomain pattern (e.g. parse tenant from tenant.yoursaas.com) plus lookup for custom domains.

Typical request flow:

1. Read Host from the HTTP request (app.customer.com).
2. Look up host → tenant_id in a local cache; on miss, query the database and refill the cache.
3. Attach tenant_id to the request context; all business logic and DB queries use this to enforce isolation.

Your multi‑tenant data design (shared tables vs schema per tenant vs database per tenant) is a separate big decision. If you are still weighing those options, our guide on multi‑tenant database architectures and hosting options for SaaS covers realistic models for small and medium projects.

Multi‑Region and Failover Considerations

For most early‑stage SaaS products, a single region with good backups is enough. As you grow, you may want:

• Regional clusters (e.g. EU and US) with separate app and DB stacks.
• GeoDNS or latency‑based routing to direct tenants to the nearest region.
• Automatic failover if one region goes offline.

Your domain architecture should not block this evolution. Using CNAME targets that point to regional load balancers or anycast frontends makes it easier to steer traffic later without forcing tenants to change DNS again.

When planning this step, our article on multi‑tenant architecture choices for SaaS and the right hosting infrastructure is a useful companion. It connects domain/routing decisions with actual server topologies on VPS, dedicated and hybrid setups.

Designing a Smooth BYO Domain Onboarding Flow

The technical pieces (DNS, ACME, routing) only pay off if tenants can successfully connect their domains without a long support conversation. A polished BYO domain flow includes:

1. Clear Domain Input and Validation

When a tenant types a domain:

• Normalize it (lowercase, strip protocol and trailing slashes).
• Validate format (IDN/punycode if you support non‑ASCII domains).
• Enforce rules: you might disallow certain public suffixes or dangerous patterns.

2. Precise DNS Instructions Per Case

Based on what they entered, show different instructions:

• For subdomains like app.customer.com: “create a CNAME from app.customer.com to customer-domains.yoursaas.com”.
• For apex domains like customer.com: choose whether you support A/AAAA, ALIAS/ANAME or both, and explain with examples.

Show the exact records as copy‑paste snippets; that alone tends to cut misconfigurations dramatically.

3. Live DNS Status and Error Feedback

Instead of a binary “Verified / Not verified”, give tenants more context:

• Whether the record exists at all.
• What target you see vs what you expect.
• Rough advice if another service (e.g. a previous host) is still answering for that domain.

Poll DNS asynchronously and update the UI, but also provide a “Recheck” button so advanced users feel in control.

4. Automatic SSL Issuance and Status

Once DNS looks correct, your control plane should:

• Kick off ACME certificate issuance immediately.
• Show status: “Issuing certificate”, “Active”, “Error (rate limit, invalid DNS, etc.)”.
• Only mark the domain as fully active when a valid certificate is in place and the proxy is reloaded.

This is where good observability helps. Monitoring certificate expiration, ACME errors and proxy reload failures will save you from quiet outages. Our article on monitoring SSL certificate expiry across many domains and automating renewals shows patterns that fit nicely into a SaaS custom domain stack.

Operational Concerns: Logging, Monitoring and Migrations

Custom domain support changes how you operate your SaaS. A few areas deserve special attention.

Logging by Hostname and Tenant

Always include the requested hostname and resolved tenant ID in your logs. Helpful patterns:

• In web server logs (Nginx, Apache), log $host plus a tenant ID header your app adds.
• In application logs, always include tenant_id and primary domain in structured fields.

This makes it much easier to debug “only this customer’s domain is slow” or “only this domain returns 404” style issues.

DNS and SSL Monitoring

At a minimum, you should watch:

• SSL certificate expiry and renewal failures per tenant domain.
• DNS resolution errors from your side (e.g. your proxy cannot resolve a CNAME target).
• Spike in 4xx/5xx errors for a specific hostname.

On top of that, a public status page with per‑region or per‑component health is reassuring for your tenants. We have a practical guide on setting up your own status page with Uptime Kuma that many SaaS teams adapt directly on a small VPS.

Zero‑Downtime DNS and Hosting Migrations

As your SaaS grows, you will eventually:

• Move from one VPS to a dedicated server or to a larger multi‑node cluster.
• Change load balancer IPs or front‑end hostnames.

With thousands of tenant domains depending on your CNAME target, DNS planning becomes critical for zero‑downtime moves. Two simple rules:

• Keep your tenants pointing to a stable hostname you control (e.g. customer-domains.yoursaas.com), not directly to an IP.
• Manage TTLs proactively: lower them before a migration, then raise again after you are stable.

We explain this in detail in our TTL playbook for zero‑downtime DNS migrations, which is particularly relevant when your SaaS is the origin behind many customer domains.

Where Hosting Fits: VPS, Dedicated and Colocation for SaaS

Domain and routing design is only half the story; you still need servers that can handle TLS, routing and application load reliably.

At dchost.com, we typically see this progression in multi‑tenant SaaS projects:

• Early stage: One well‑sized VPS running the app, database and reverse proxy with wildcard SSL for *.yoursaas.com.
• Growing stage: Separate VPS for application and database, plus a front‑end VPS acting as a dedicated TLS terminator and reverse proxy for both your own subdomains and tenant custom domains.
• Mature stage: Dedicated servers or colocation with redundant load balancers, multiple app nodes and managed storage or replication for the database.

Because SNI lets you serve many certificates from one IP, you can keep IPv4 usage efficient while still growing your custom domain offering. Our comparison of dedicated servers vs VPS for different business stages can help you decide when it is time to move up a tier for your SaaS.

Summary and Next Steps

A solid custom domain and subdomain architecture for multi‑tenant SaaS is not just a DNS or SSL decision; it is a product decision that affects every tenant’s first impression of your platform. The most robust pattern in practice is a hybrid approach: give every tenant a default subdomain on your own domain, offer optional BYO custom domains, and back it all with automated DNS verification, ACME‑based SSL and SNI‑driven routing.

If you design the layers carefully — domain patterns, DNS onboarding, certificate lifecycle, host‑based routing and logging — supporting hundreds or thousands of tenant domains becomes an operational routine rather than a fragile custom integration each time. The earlier you standardize this flow, the fewer support tickets and emergencies you will face later.

If you are planning or refactoring a multi‑tenant SaaS, our team at dchost.com can provide the underlying infrastructure: from performant VPS plans to dedicated servers and colocation, with the network, IPv4/IPv6 and SSL tooling you need to run your domain architecture safely. Start small, design with scale in mind, and let DNS, SSL and routing work quietly in the background while you focus on your product.