Custom Domain Client Portal for Clinics (2026 Guide)

Custom Domain Client Portal for Clinics (2026 Implementation Guide)

A client portal on a custom domain — portal.yourclinic.com instead of yourclinic.platform-vendor.com — presents two operational benefits: it strengthens trust at every patient-facing touchpoint, and it reinforces the clinic's brand in a channel where patients take meaningful actions (signing consent forms, reviewing invoices, making payments, accessing their clinical documents).

The technical setup for a custom domain portal is a DNS configuration step — typically completed by the clinic owner or IT contact in under 30 minutes. The operational value, once deployed, accrues continuously: every email containing a portal link, every SMS with a portal URL, every document request sent to a patient reflects the clinic's own domain rather than an unfamiliar vendor URL.

This guide covers why custom domain matters for patient trust, how to set it up correctly, and the security and operational controls that ensure the portal is both trustworthy and reliable.

Why Custom Domain Matters for Patient Trust

The trust threshold for patient actions

Patients take sensitive actions through client portals: they sign consent forms for clinical procedures, pay invoices, share health information on intake forms, and download clinical documents. These are high-trust actions. The context in which the patient takes these actions significantly affects their willingness to proceed.

A patient who receives an email from "no-reply@platform-vendor.com" asking them to visit "yourclinic.platform-vendor.com" to sign a consent form before their procedure is being asked to take a sensitive action in an unfamiliar brand context. Some patients will proceed without concern; others will hesitate, question whether the communication is legitimate, or call the clinic to confirm before clicking anything.

A patient who receives an email from "admin@yourclinic.com" with a link to "portal.yourclinic.com" is operating in a familiar brand context. The clinic's name and domain are consistent with every other communication they've received from the practice. The action feels like doing business with their clinic, not with an unfamiliar platform.

Consent form and document completion rates

There is a measurable relationship between communication brand consistency and patient task completion rates. When the portal link, the email, and the clinic branding are all consistent, patients are more likely to complete the task they were sent to complete — particularly for high-friction tasks like consent form completion and payment processing.

The custom domain is one element of this consistency. It works best when combined with: branded email notifications (sent from the clinic's domain, not the vendor's domain), the clinic's logo on the portal, and a consistent colour scheme that matches the clinic's other patient communications.

DNS Setup

The custom domain for a client portal is configured via a CNAME record in the clinic's domain DNS settings. The clinic needs:

• Access to their domain's DNS management (via their domain registrar or hosting provider control panel)
• The CNAME target provided by the portal software vendor

The setup process:

1. Log in to the domain registrar or DNS provider (Cloudflare, GoDaddy, Namecheap, or the clinic's web hosting provider's control panel)
2. Navigate to DNS settings for the domain
3. Add a new CNAME record:
   • Name/Host: The subdomain for the portal (e.g., portal for portal.yourclinic.com)
   • Value/Target: The hostname provided by the software vendor (e.g., custom.tregovia.com)
   • TTL: 300–600 seconds for initial setup (lower TTL means faster propagation)
4. Save the record
5. Wait for DNS propagation (typically 5–60 minutes for most providers; up to 48 hours in edge cases)
6. Return to the portal software and trigger domain verification

Common setup errors:

• CNAME pointing to the wrong target (typographical error in the target hostname)
• Cloudflare proxy enabled (orange cloud) — for most portal implementations, this must be set to DNS-only (grey cloud)
• Conflicting A record on the same subdomain (an A record for "portal" prevents the CNAME from working)

If the domain verification fails after DNS propagation, check these three issues before contacting support.

SSL/TLS Certificate

Once the CNAME is configured and propagated, the portal software provisions an SSL/TLS certificate for the custom domain. This is what puts the padlock in the browser and enables the HTTPS prefix on the URL.

Modern portal software (including Tregovia, which uses an automated reverse proxy) provisions this certificate automatically via Let's Encrypt. The clinic does not need to purchase or manage an SSL certificate separately.

Certificate renewal is also automatic. Let's Encrypt certificates are valid for 90 days and are renewed automatically at approximately the 60-day mark. If auto-renewal fails for any reason (the domain CNAME was removed, the renewal service was temporarily unavailable), the clinic should receive an alert before the certificate expires.

Security Controls

A custom domain portal handles patient health data. Basic security controls are not optional:

HTTPS enforcement: All HTTP requests to the portal domain should be automatically redirected to HTTPS. There should be no non-HTTPS access path to the portal.

Session management: Portal sessions should expire after a configurable inactivity period (typically 15–30 minutes for a clinical portal). Patients who leave a portal session open on an unattended device should not remain authenticated indefinitely.

Failed login monitoring: Repeated failed login attempts to the portal should trigger a lockout after a defined number of attempts (e.g., five failed attempts in 15 minutes triggers a 30-minute lockout). This prevents brute-force attacks on patient accounts.

Direct-access link security: Where patients access the portal via a direct link (magic link or pre-authenticated token) rather than a login, the link should:

• Be unique per patient and per access request
• Expire after a defined period (e.g., 48 hours)
• Be single-use (accessing the link once invalidates it for repeat access without re-authentication)

Patient data isolation: The portal must serve only the data of the authenticated patient. Cross-patient data access should be architecturally impossible — not just procedurally prevented.

Operational Monitoring

Once the custom domain portal is live, monitor:

Signal	How to monitor	Alert threshold
Portal availability	Uptime monitoring (e.g., Uptime Robot, Better Uptime)	Any downtime > 5 minutes
SSL certificate expiry	Certificate monitoring or vendor dashboard	Alert at < 14 days remaining
Form completion rate	Portal analytics	Drop > 20% from baseline
Failed login rate	Portal security dashboard	Spike in failed attempts
HTTPS redirect working	Manual check or monitoring tool	Any non-HTTPS access

If form or payment completion rates drop suddenly, investigate whether there is a portal availability issue, a DNS change that broke the custom domain routing, or a certificate error that is generating browser security warnings.

Setting Up in Tregovia

Tregovia's White Label module (EUR 99/month) enables custom domain client portals for clinics:

DNS setup: Enter custom domain in Settings → Branding → Custom Domain. Tregovia provides the CNAME target. One-click DNS verification after propagation.

SSL certificate: Provisioned automatically via automated certificate provisioning within 5 minutes of DNS verification. Auto-renewed; no manual management required.

Portal functions on custom domain:

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

Security controls:

• HTTPS-only enforcement (HTTP redirected to HTTPS)
• Session timeout: 30 minutes of inactivity
• Failed login lockout: 5 attempts per 15 minutes
• Direct-access links: 48h expiry, single-use
• Data isolation: row-level tenant scoping ensures cross-patient access is architecturally prevented

Branding on portal:

• Clinic logo in portal header
• Custom colour scheme (White Label module)
• "Powered by Tregovia" removed (White Label module)
• Email notifications sent with clinic name (not vendor brand)

Privacy posture: Custom portal workflows should be backed by a reviewed processor terms, hosting terms, access controls, and retention rules before patient data is exposed through the portal.

Pricing: White Label module EUR 99/month flat rate for all clinics on the plan. Base portal included in EUR 47/month base plan. 14-day free trial.

FAQ

Does a custom domain improve patient task completion rates?

It often improves initial trust, which can lift form and payment completion — particularly for first-time portal users who haven't previously used the practice's digital services. The custom domain reduces the "is this legitimate?" hesitation that some patients experience when they receive a link to an unfamiliar vendor domain. For established patients who have used the portal before, the custom domain has a smaller incremental effect — they've already established trust with the portal. For new patients completing their first intake form or first payment, the brand consistency of a custom domain is more influential.

What is the top technical risk with custom domain portals?

Misconfigured DNS causing intermittent access failures. The most common scenario: the clinic's IT contact or domain provider makes a change to DNS settings (updating hosting, moving domain, changing DNS provider) that inadvertently removes or overrides the CNAME record for the portal subdomain. The portal becomes inaccessible, patients receive DNS resolution errors, and the clinic receives complaint calls. Preventive measures: document the CNAME configuration clearly and store it with the clinic's IT records; set up uptime monitoring on the portal domain; and ensure any future DNS changes are reviewed against the portal CNAME before being applied.

Should portals use a subdomain or a root path?

Subdomain (portal.yourclinic.com) is the standard approach. It maps cleanly to a CNAME record, is technically simpler to route at the infrastructure level, and produces a clear URL that patients recognise as separate from the main clinic website. A root path approach (yourclinic.com/portal) requires the portal software to be hosted on the same infrastructure as the main clinic website, or requires a reverse-proxy configuration — more complex and less common for SaaS clinic software. If the clinic already has a complex website infrastructure, confirm with the portal vendor whether subdomain-based or path-based custom domain setup is supported.

Who owns portal reliability once it's live?

Operations and technical jointly, with clear split responsibilities. The portal vendor (Tregovia) owns: infrastructure uptime, SSL certificate renewal, routing correctness, and security monitoring. The clinic owns: DNS configuration correctness, clinical content accuracy (forms, documents), staff access management, and operational response when patients report access issues. The split is clean in normal operation. In incident scenarios — the portal is inaccessible — the first diagnostic question is whether the problem is DNS (clinic responsibility) or infrastructure (vendor responsibility). Good vendors provide diagnostic tooling (a "check domain health" function in the admin panel) that allows the clinic to self-diagnose before raising a support ticket.

What monitoring should a clinic run on its custom domain portal?

At minimum: uptime monitoring (a free tool like UptimeRobot can monitor the custom domain URL and send an email alert if it becomes unavailable) and SSL certificate expiry monitoring (most uptime tools also monitor certificate expiry). These two controls catch the two most common failure modes: portal downtime and certificate expiry. Beyond these basics, review the portal's form and payment completion rates monthly — a significant drop in completion rates, without a corresponding change in portal traffic, is often the first indicator of a partial availability issue (the portal loads but a specific function is broken) before it escalates to a full outage.