Custom Domains

A tenant is not required to use a custom domain — the self-service portal works identically on BYOVault's own shared domain. A custom domain (for example restore.acme-mfg.com) is an optional, per-tenant substitution, added by an operator and verified automatically before it goes live.

Default behavior

Without a custom domain, an end user reaches the portal at BYOVault’s shared production host, and the specific tenant is identified from the URL rather than by which domain was requested. This is the default for every tenant, not a fallback for tenants that skipped custom-domain setup — most tenants never configure one.

Adding a domain

An operator submits the client’s domain once, and BYOVault begins checking whether it is correctly set up. The client’s only action is adding one DNS record at their own DNS provider, and BYOVault surfaces the exact record to add so the client always knows what to create at their own registrar.

Which record type depends on the domain:

  • A CNAME record, for a subdomain such as restore.acme-mfg.com.
  • An A record instead, if the domain being used is a bare apex domain — an apex domain cannot be pointed at another host with a CNAME record.
DNS propagation takes real time
DNS propagation can take up to 24–48 hours. Immediately after a domain is submitted, it is normal — not an error — for the domain to be added but not yet routed. BYOVault provides a repeatable “check status” action for exactly this waiting period, rather than treating the domain as failed.

Ownership vs. actually routed

Adding a domain establishes that its ownership checks out — for example, that its DNS zone is delegated to a nameserver BYOVault recognizes.

That alone does not confirm that any DNS record actually routes traffic to the portal. Ownership can be confirmed within seconds even when no CNAME or A record for the domain has ever been added and no request has ever reached the portal.

BYOVault does not treat ownership as sufficient on its own. Whether a domain is genuinely serving the portal is confirmed separately, with a live DNS and routing check independent of whether the domain has merely been added.

A domain is recorded as verified for a tenant, and its verified timestamp is set, only once that routing check passes. Submitting a domain and manually re-checking its status both apply this same rule.

A previously-working domain can be un-verified automatically
If a domain that was routing correctly stops being correctly configured — for example, its DNS record is later changed or removed at the client’s own DNS provider — the next status check clears the tenant’s stored verified timestamp. BYOVault does not continue treating a domain as live once its actual DNS configuration no longer supports it.

What changes once a domain is verified

Every notification a self-service end user receives — a request submitted, decided, or completed — contains a link back to the portal. That link uses the tenant’s custom domain only once it is verified in the sense above; until then, notifications continue linking to the shared default domain.

Removing a custom domain from a tenant reverts it to the shared default domain immediately.

The portal will not function until verification completes
Until a custom domain finishes verification, the portal will not function on that domain. Keep using the shared default domain during this window; once verification completes, the custom domain works fully.

Removing a domain

An operator can detach a tenant’s custom domain at any time — for instance, if the client no longer wants to use it, or to clear a domain stuck in a misconfigured state.

Removal clears both the stored domain and its verified timestamp for the tenant, and the portal immediately falls back to the shared default domain with no other change in behavior.

For the roles that can be granted access to the portal at all, see Roles & Approvals. For what happens after a request is submitted, regardless of which domain it was submitted from, see Request Lifecycle.

PreviousRequest LifecycleNextOverview