# Custom domain security for multi-tenant SaaS
Canonical source: https://approximated.app/blog/custom-domain-security/
Author: Approximated
Published: 2026-09-23
Last reviewed: 2026-09-28
**Short answer:** secure custom domains at three boundaries: who may bind a hostname, which tenant a request may reach, and what happens when the binding is removed. Managed TLS protects the connection, but it doesn't decide whether the right customer owns a name or whether your application selected the right tenant.
## 1. Make hostname claims exclusive
Store one normalized hostname claim across the whole product, including after its active tenant route is disabled. Reject a second claim rather than silently moving traffic. Confirm that the requesting user can administer the target tenant, and define a separate transfer process for legitimate ownership changes. Require account-bound proof of control over the exact hostname for a new claim or transfer, such as a DNS challenge or a reviewed process; a shared CNAME target alone doesn't prove which account owns the name.
Keep the claim distinct from edge configuration. Our [Virtual Hosts API](https://approximated.app/docs/#virtual-hosts-api) maps the incoming address to a target, while your application supplies the tenant authorization and ownership record. The [onboarding checklist](https://approximated.app/blog/custom-domain-onboarding-checklist/) shows how to expose that separation to customers.
## 2. Fail closed on unexpected hosts
On every request, resolve a trusted, normalized hostname to one active tenant. Reject unrecognized hosts before rendering tenant content, sending an email link, or building a redirect. When a proxy supplies forwarded headers, accept them only from infrastructure you control; a client-provided header must not select a tenant by itself. Keep the host allowlist and the edge configuration in sync.
Test more than the homepage. A customer domain can affect absolute URLs, OAuth callback allowlists, cookie scope, password-reset links, and admin routes. Verify that one tenant's domain can't show another tenant's assets or session. Framework-specific guidance starts in the [integration guides](https://approximated.app/guides/).
## 3. Design removal as a security operation
A stale DNS record pointing at a released or claimable service is a known takeover path. [OWASP's subdomain takeover guidance](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) recommends tracking DNS records together with the resources they reference and changing DNS before decommissioning a resource. Customer-owned zones complicate this: you may be unable to remove their record yourself, so tell the customer what to delete and keep your shared DNS target under your control.
When a customer disconnects, disable the application's tenant route and remove the edge route in a controlled sequence, but retain a non-routing reservation for the hostname. A request to the old hostname must no longer reach the old tenant, even if DNS remains pointed at your edge. Release or transfer the reservation only after the new account proves control of that exact hostname through a verified process. Don't release a shared CNAME target or IP address while any customer record may still refer to it. Monitor for stale records and define what an unknown hostname receives.
## A compact review table
| Failure | Practical control | Proof to collect |
| --- | --- | --- |
| Two tenants claim one hostname | Exclusive database binding and explicit transfer approval. | A duplicate claim is rejected without moving live traffic. |
| Host confusion | Trusted proxy boundary and exact hostname lookup. | An unknown or forged host never renders tenant content. |
| Wrong origin or tenant | End-to-end HTTPS request after configuration changes. | The response identifies the intended tenant, including login and redirects. |
| Dangling DNS after churn | DNS removal instructions, a retained hostname reservation, proof before reassignment, and a controlled shared target. | With stale DNS, a second tenant can't claim the hostname without verification, and the old route serves neither tenant. |
## WAF and DDoS protection built for many tenant domains
A SaaS edge serves many customer hostnames through one product. We build our [WAF and DDoS protection](https://approximated.app/#waf) into your dedicated cluster, using request inspection, client fingerprints, and traffic analysis to identify common exploits, scanning, and abusive behavior. Threats seen across our network help inform the cluster's response alongside evidence from its own traffic.
Our edge can challenge suspicious traffic, block qualifying attacks, and restrict repeat offenders, with safeguards intended to keep legitimate traffic moving. That gives your team managed protection close to the customer-domain traffic, alongside the application's own authorization and input validation.
For browser forms, our [Edge Verify](https://approximated.app/docs/#edge-verify) adds domain-bound, short-lived, single-use tokens and checks submissions at the edge. The script is served from your own domain. Monitor mode records outcomes without blocking; enforce mode rejects submissions with missing or invalid tokens. It's a bot-abuse control; your application still verifies user identity, domain ownership, and permission to act.
## Keep security and operating changes visible
We monitor DNS, SSL, and proxy-hit status for configured domains. Our [webhooks](https://approximated.app/docs/#webhooks) can update your support tools and domain lifecycle when observations change. Validate webhook authentication, deduplicate event keys, and reconcile with the current API state before making a consequential change.
You can reach [real developers for technical support](https://approximated.app/#faq), including on-call emergency help. If your requirements call for traffic or certificates on your own infrastructure, our [hybrid and full self-hosted plans](https://approximated.app/self-hosted/) give you a path to evaluate with our engineers. We publish [cloud billing units and self-hosted prices](https://approximated.app/pricing/) up front; custom SLA terms have their own agreed scope, so production planning can happen without enterprise surprises.
## Use our edge protection with your application controls
We manage the custom-domain edge: routing, automated TLS, protection against abusive traffic, and domain monitoring. Your application keeps the hostname ownership record and decides which user may act for each tenant. Use these controls together; our [product overview](https://approximated.app/product/) and [documentation](https://approximated.app/docs/) explain the integration boundary.
Run the controls above with a domain you own before accepting customer traffic. If you're still choosing the edge layer, the [API comparison](https://approximated.app/blog/best-custom-domain-apis-for-saas/) includes deployment and onboarding questions that belong in the security review.
## Frequently asked questions
### Does automatic HTTPS prevent custom domain takeover in a multi-tenant SaaS?
HTTPS encrypts a connection to a hostname; it doesn't decide which tenant is allowed to use that hostname. Your application must authorize domain changes, enforce one active tenant claim per normalized hostname, and reject unknown hosts. We handle certificates and edge protection, while tenant identity, hostname ownership, and application authorization remain your controls.
### How do I prevent a disconnected custom domain from being claimed by another tenant?
Stop serving the old tenant but retain a non-routing hostname reservation while DNS can still point at your shared edge. Require fresh proof bound to the exact hostname and requesting account before reassignment. A stale A or CNAME record isn't sufficient proof for a different tenant. Tell the former customer to remove obsolete DNS and make transfer an explicit audited action.
### What security controls should a SaaS custom domain feature include?
Use authorized hostname claims, exact tenant mappings, trusted proxy headers, unknown-host rejection, and safe transfer and removal. Add edge request inspection, traffic-abuse controls, form protection, and ongoing domain monitoring. Our dedicated cloud clusters combine WAF and DDoS protection, Edge Verify, and operational signals for many customer domains; your app continues to enforce login, sessions, and tenant access.
### How does Approximated protect traffic across many tenant domains?
Our WAF and DDoS protection operates in the dedicated cluster serving your SaaS domains. It combines request inspection, client fingerprints, and traffic analysis, using shared threat intelligence alongside evidence from your own traffic. It can challenge suspicious clients and restrict qualifying attacks before they reach your origin. Monitor the outcome for legitimate customer flows as you introduce protection rules.
### How does Edge Verify protect forms on customer-owned domains?
Edge Verify serves its browser script from the customer's own domain and checks form submissions at the edge. Verification tokens are short-lived, single-use, and bound to the domain and visitor. Monitor mode records outcomes without blocking; enforce mode rejects missing or invalid verification. It complements our WAF and DDoS protection while your application still owns identity, authorization, and domain claims.