White-Label Client Portal with Custom Domain (2026 Guide)

White-Label Client Portal Software with Custom Domain (2026 Guide)

A white-label client portal with a custom domain presents your business to clients as a complete, professional digital experience — your name, your brand, your domain, without any visible trace of the underlying software platform. For service businesses building long-term client relationships — clinics, studios, agencies, professional practices — a portal that looks like yours builds trust and reinforces the brand investment you've made in the rest of your client experience.

The technical components of white-label portal software with custom domain support are well understood: DNS configuration, certificate management, hostname routing, and white-label UI controls. The business decision is more nuanced — which platforms deliver these capabilities reliably, at what price point, and with what impact on the client-facing workflows that matter most to your operations.

This guide covers how to evaluate white-label client portal software, what the custom domain setup process involves, the security considerations specific to white-label portals, and what operational metrics indicate that the setup is working.

What White-Label Client Portal Means

White-label means: no vendor branding visible to your clients. The full spectrum of white-label capability includes:

Basic white-label:

• Your logo in the portal header
• Your business name throughout the interface
• Your primary brand colour on key UI elements
• Subdomain at yourbrand.vendor.com (the vendor name is still visible in the URL)

Intermediate white-label:

• Custom domain: portal.yourbrand.com (your domain, no vendor URL)
• Branded email notifications (sent from your domain)
• Vendor logo removed from footer
• Custom colour scheme (primary + secondary + accent)

Full white-label:

• All of the above, plus:
• Custom favicon
• Custom typography (web fonts)
• No vendor branding in any client-visible surface (email, portal UI, PDF exports, SMS)
• Client has no way to identify the underlying software platform

Most clinics and service businesses need intermediate white-label. Full white-label is typically relevant for agencies reselling the portal as their own product.

Custom Domain Setup: What to Expect

The process for enabling a custom portal domain requires cooperation between the platform and the tenant:

Your responsibility (DNS):

1. Log in to your domain registrar or DNS provider
2. Add a CNAME record pointing your chosen subdomain (portal.yourdomain.com) to the target provided by the platform
3. Wait for DNS propagation (minutes to a few hours)
4. Return to the platform to trigger domain verification

Platform responsibility:

1. Verify that the CNAME record is correctly configured
2. Provision a TLS/SSL certificate for your custom domain (typically automated via Let's Encrypt)
3. Configure routing so that requests to portal.yourdomain.com serve your portal

From first DNS configuration to a live custom domain: typically 15 minutes to two hours when everything goes correctly. The most common delays are DNS propagation lag (nothing can accelerate this) and certificate provisioning retries (can take up to 30 minutes if the ACME challenge server is under load).

Security Considerations for White-Label Portals

White-label portals handle sensitive client data — medical records, financial documents, appointment history, payment information. Several security properties are specific to white-label environments:

TLS certificate management

Each custom domain requires its own TLS certificate. The platform must automate certificate provisioning and renewal. A certificate that expires causes a browser security warning that blocks client access — catastrophic for a client portal.

What to verify: Ask the vendor how certificate renewal is handled. Automated renewal (via ACME/Let's Encrypt or a CDN) is the correct answer. Manual renewal is a human reliability risk.

Tenant data isolation in routing

When a request arrives at the platform for portal.yourclinic.com, the routing layer must correctly identify your tenant context and serve your data — not another tenant's. Multi-tenant routing with custom domains is a more complex isolation challenge than subdomain routing, because the platform cannot rely on the subdomain pattern for tenant identification.

What to verify: Ask the vendor how tenant isolation is enforced for custom domain requests. The correct answer involves a domain-to-tenant mapping table consulted at the routing layer, with no possibility of cross-tenant data leakage.

Client session handling on custom domains

Login sessions established on portal.yourclinic.com should not carry over to other portals, and sessions from other portals should not be valid on your domain. Session scope must be domain-specific.

Data residency

If your client data is processed in the EU (as is required for most EU-based healthcare and professional practices under GDPR), the custom domain routing must not create a data transfer pathway to infrastructure outside the EU. Confirm that custom domain traffic is handled by EU-based infrastructure, not routed through a CDN or edge node in a non-EU country.

Tenant Customisation vs. Supportability

A common tension in white-label portal design is between branding flexibility and operational supportability. The more configurable the portal, the harder it is to support.

Recommended approach: Allow controlled customisation ranges:

Element	Recommended approach
Logo	Upload any image; enforce max dimensions and file size
Brand colours	Primary and secondary colour pickers; platform-enforced accessibility contrast check
Typography	Selection from a pre-approved font set (not arbitrary web font URLs)
Domain	CNAME-based custom domain; verify DNS before activation
Email sender	Custom sender name; custom reply-to; platform manages SPF/DKIM for deliverability
Portal layout	Configurable content blocks within a fixed layout — don't allow arbitrary layout changes
Footer	Toggle "Powered by [platform]" visibility; allow custom footer text

Arbitrary custom CSS or JavaScript injection into the portal is a security and supportability risk — it allows tenants to introduce XSS vectors and makes debugging client-reported issues significantly harder.

Platform Comparison

Criterion	EU CRM Platform	Cliniko	Jane App
Custom domain (CNAME)	Yes	No	Limited
White-label footer	Yes	No	No
Branded email (your domain)	Yes	No	No
Automated cert management	Yes	No	No
Tenant isolation on custom domain	Yes	No	Limited
Privacy controls	Review	Australia	Canada
Flat-rate pricing model	Yes	Per user	Per user

Verify current features and pricing at each vendor's website.

Setting Up Custom Domain White-Label

A modern CRM's White Label module (typically EUR 99/month) enables full intermediate white-label for the client portal:

Custom domain setup:

• Add your custom domain in Settings → Branding → Custom Domain
• Tregovia provides the CNAME target to configure in your DNS
• One-click DNS verification
• Automatic TLS certificate provisioning (typically within 5 minutes of DNS propagation)
• Automated certificate renewal — no manual intervention

Branding controls:

• Logo upload (displayed in portal header and email notifications)
• Primary and secondary brand colours
• Custom favicon
• White-label footer: vendor branding removed
• Branded email templates: notifications sent with your practice name; reply-to is your clinic email

Security:

• Custom domain requests isolated to your tenant context
• Session scope domain-specific
• All traffic handled by EU infrastructure in the EU (no non-EU routing for EU-hosted tenants)
• processor terms covers custom domain data processing

Portal functions available on custom domain:

• Client login (direct access link or account login)
• Appointment history and upcoming bookings
• Invoice viewing and payment (with Online Payments module)
• Document access and digital signature (with Contracts & E-Sign module)
• Form submission (with Forms Intake module)
• Gift card balance check (with Gift Cards module)

Pricing: White Label module typically EUR 99/month — flat rate. Added to the base plan. Most vendors offer a 14-day free trial.

Operational Metrics for Custom Domain Portal

Once the custom domain is live, track:

Metric	Definition	Target
Domain uptime	% of time the custom domain resolves and serves the portal correctly	99.9%+
Certificate validity	Days until certificate expiry	Alert at <14 days
Time from DNS setup to live	Duration from DNS configuration to first successful client access	Target: <2 hours
Client activation rate on custom domain	% of clients who access the portal at least once	Monitor vs. pre-custom-domain baseline
Support tickets about domain access	Tickets per month related to portal access issues	Target: <1% of active portal clients

FAQ

What is the biggest operational risk with custom domain portals?

Misconfigured domain routing — either CNAME configured incorrectly (pointing to the wrong target) or Cloudflare proxy mode enabled when the platform expects DNS-only mode. Both of these cause the portal to be inaccessible or to show a TLS error to clients. The second most common risk is certificate expiry due to failed automated renewal — typically caused by the ACME challenge server being unable to reach the custom domain (e.g., because the CNAME was accidentally deleted after initial setup). Monitor certificate expiry for all active custom domains.

Should white-label portals be fully tenant-customisable?

Controlled customisation ranges — yes. Arbitrary customisation — no. Allowing tenants to inject custom CSS and JavaScript into the portal is a security risk (XSS vulnerability surface) and a support burden (tenant-introduced bugs become support tickets). The correct model is: provide a rich set of branding controls within the platform's design system, and prevent modifications that bypass the platform's rendering controls. Tenants who need more than the platform's design system offers are typically agencies building their own product — a different use case with different requirements.

What metric proves custom domain launch quality?

Time from domain setup to first successful client action (login, form submission, payment, document access) — measured for the first client to access the portal after the custom domain goes live. A setup that takes 20 minutes from DNS configuration to first client action is a good result. A setup that requires multiple support interactions over several hours to resolve DNS or certificate issues is a signal that the platform's setup documentation, tooling, or automation needs improvement. Track this metric for each tenant activation and use it to improve the setup process over time.

How does white-label affect GDPR compliance?

The white-label presentation layer does not change the underlying data processing relationship. The platform remains the data processor; your clinic remains the data controller. GDPR requires processor terms regardless of whether the portal is white-label or not. One nuance for custom domains: if the platform uses a CDN to route custom domain traffic, and that CDN processes EU personal data on non-EU infrastructure, you may have a third-country transfer that requires a Standard Contractual Clause (SCC) or an adequacy decision. Confirm with your vendor that custom domain traffic is routed through EU-compliant infrastructure and that processor terms covers this routing path.

Who owns post-launch custom domain reliability?

The platform owns certificate lifecycle management, routing correctness, and infrastructure uptime. The tenant owns DNS configuration — if the CNAME record is modified or deleted, the platform cannot restore it without DNS access. The split ownership means that when a custom domain stops working, the first diagnostic step is always to check whether the DNS configuration is still correct. A good platform provides a "check domain health" diagnostic in the admin panel that verifies both DNS and certificate status, allowing the tenant to self-diagnose before opening a support ticket.