Custom domains for MENA SaaS: setup to safe removal

A customer's branded portal can load over HTTPS and still be attached to the wrong workspace. A certificate answers a domain-control question. Your application must separately decide which tenant may use that hostname, which deployment serves it and what happens when the customer leaves.

For a SaaS team serving Saudi and UAE customers, custom domains deserve a release process rather than a single settings field. This guide proposes a lifecycle for customer-owned portal hostnames, from the first claim through removal. It is an engineering design, not a claim that a domain suffix establishes hosting location or regulatory compliance.

Cover: original SultanByte artwork showing a customer hostname passing through verification before reaching a tenant portal.

Make the hostname a managed record

Start with a deliberately narrow product offer: an exact customer subdomain, such as portal.customer.example, attached to one workspace. Treat apex domains and wildcards as separate capabilities with their own tests. Do not enable them accidentally because the input field accepts an asterisk.

Store the canonical hostname, tenant identifier, deployment, provider resource identifier and lifecycle state. Record who requested the attachment, when control was verified, and which configuration version is active. Keep pending requests distinct from active mappings. An abandoned request should not reserve a hostname forever.

Enforce uniqueness on the canonical hostname across your service. Two concurrent requests from different tenants must not both become active. Use a database constraint and an explicit transfer procedure rather than relying on an availability check in the browser.

For Arabic domain names, make the DNS-facing representation consistent across validation, storage, certificate requests and routing. SultanByte's IDNA and internationalized-email guide covers that conversion boundary. The onboarding screen should let an administrator inspect both the approved display form and the DNS form without confusing a translated label with a different hostname.

Keep country and deployment explicit. A Saudi customer workspace and a UAE customer workspace may share software while using different approved infrastructure. Attaching a branded hostname must not silently move either workspace to the application's default deployment.

Separate the customer claim from certificate issuance

Require an authenticated workspace administrator to request the hostname. Then obtain fresh evidence of domain control before activating the application mapping. In this proposed design, a DNS challenge is scoped to the exact hostname, tenant and pending request, with an expiry. A successful check for an old request cannot authorise a new tenant's attachment.

Use the hosting provider's supported validation mechanism where available. Keep your tenant-assignment decision separate from its certificate workflow.

Cloudflare's hostname-validation documentation makes that separation visible: hostname ownership affects status, while certificate validation affects ssl.status. Its documented production conditions require both to be active and DNS to point at the SaaS target. One green status field is not the complete readiness test.

Do not generalise that provider model to every CDN. Amazon CloudFront's alternate-domain requirements require a trusted certificate covering the requested name. They also prevent the same exact alternate name from appearing on two distributions. Overlapping wildcard names have different routing rules: the more specific name wins, regardless of which distribution the DNS record targets.

Those differences change migration planning. Before promising a seamless transfer, identify the actual provider operation, who controls the existing configuration and how the destination will be checked. Do not solve a hostname conflict by deleting a resource whose owner you have not established.

Prepare HTTPS before moving production traffic

Choose the validation path before sending DNS instructions to the customer.

Cloudflare's certificate guidance describes methods that can issue and deploy a certificate before cutover. It also warns that automatic HTTP validation requires DNS to point at the SaaS target first, creating a period when traffic may arrive before the certificate is active. That distinction belongs in the onboarding plan, not in a support reply after the customer changes DNS.

For teams operating ACME themselves, Let's Encrypt's challenge documentation explains that HTTP-01 uses port 80 and cannot issue wildcard certificates. DNS-01 uses a TXT record and can validate wildcards. It also warns against placing broad DNS API credentials on a web server, recommending narrower credentials or a separate validation service.

Prefer a documented, renewable validation arrangement over a one-off manual success. Record who owns renewal failures and which customer DNS changes can break the arrangement. Monitor the deployed certificate, not merely the job that requested it.

Give the customer exact record names and values, with a clear distinction between traffic-routing records and validation records. Avoid a blanket instruction to delete every TXT record after setup; some arrangements depend on retained validation configuration. Test the instructions in the customer's DNS interface, including whether it automatically appends the zone name.

Original infographic: SultanByte. Proposed lifecycle informed by Cloudflare, AWS, Let's Encrypt, Microsoft and OWASP guidance, October 2026. The gates describe an engineering design, not measured service availability.

Route only through an approved binding

At the application boundary, resolve the incoming hostname against the active mapping registry. Reject unknown, pending and suspended names. Do not render the first tenant, a default customer or a newly inferred workspace when lookup fails.

Define which proxy supplies the external hostname and which headers the origin trusts. An arbitrary forwarded-host header from an untrusted request must not override the verified route. Restrict direct origin access as part of the deployment design, then test the actual ingress path rather than only a local development server.

A matching hostname selects a workspace context; it does not grant the visitor permission to its records. Keep authentication and record-level authorisation in the request path. The tenant-isolation guide covers those broader checks.

Cache behaviour needs an explicit test. If two customer hostnames request the same path, neither may receive the other's branding or private content. Review edge rewrites and application cache keys, and keep authenticated responses out of shared caching unless the complete design safely accounts for identity and permissions.

Before activation, exercise HTTPS, the expected tenant, login and a harmless authenticated read through the real hostname. Test an unrecognised hostname too. Preserve the result against the binding version so a later configuration change cannot inherit an earlier approval without review.

Keep login and recovery tied to trusted destinations

Custom domains complicate authentication because the application now has several possible browser origins. Choose a supported login model deliberately. A central identity service with explicit redirects is different from independently logging in on every customer hostname.

OWASP's session-management guidance recommends restricted cookie scope and warns about permissive parent-domain cookies. It documents the __Host- prefix, which requires Secure, Path=/ and no Domain attribute. Use an appropriate host-bound session design rather than broadening cookie scope to make an integration appear to work. Test the chosen SameSite behaviour through the actual login flow.

Password-reset links need particular care. OWASP's forgot-password guidance says not to construct them from an untrusted Host header; use a fixed destination or validate against trusted domains. For this lifecycle, generate security-sensitive links from approved server-side configuration, and stop issuing them for a suspended binding.

When a hostname is removed or reassigned, invalidate sessions and outstanding links whose authority depends on that old binding. A suggested implementation binds them to a mapping generation as well as the tenant. Merely deleting the hostname row leaves old browser and email artifacts unexplained.

Design offboarding before the first customer leaves

Microsoft's dangling-DNS guidance describes the takeover risk when a DNS record continues pointing at a deprovisioned resource that another party can claim. A valid TLS certificate does not eliminate that risk. Resource deletion and DNS cleanup need a coordinated owner.

The proposed offboarding sequence starts by disabling tenant service at the application layer and stopping new links to the hostname. Keep a safe rejection path while the customer removes or redirects DNS. Then remove the provider binding and associated configuration according to the provider's procedure, and verify the old hostname no longer serves the tenant.

Cloudflare's removal guidance explicitly tells SaaS providers to remove churned customers' custom hostnames. Its provider-side cleanup is a separate task from the customer's DNS change. Do not mark offboarding complete because only one party finished.

Retain an auditable tombstone with the old binding generation and removal outcome, subject to your retention policy. A later attachment should require fresh verification and fresh approval. An old CNAME still pointing at your service must not be enough for another workspace to claim the name.

Use a release record that support can understand

For each hostname, keep a compact decision record: workspace, canonical name, deployment, verification evidence, certificate state, observed route, binding generation and responsible owner. Separate customer action required from provider processing and application rejection. Give Arabic and English instructions the same technical values and status meanings.

The acceptance pack should include concurrent claims by two tenants, an expired challenge, a certificate that is not ready, a wrong deployment, an unknown Host value and a stale mapping cache. Exercise login after a domain change, a reset link created before suspension and an attempted reattachment after offboarding. These are proposed tests; passing a DNS lookup alone cannot substitute for them.

Buyers should ask a SaaS vendor to demonstrate removal as well as setup. Engineering teams should start with exact subdomains, make the lifecycle observable, and add apex or wildcard support only when their operational contract is equally clear. A custom domain is ready when the right customer can use it safely and the service can later stop serving it without leaving an unintended route behind.