Portal Domain Setup Guide for SaaS (DNS, SSL, QA)

Portal Domain Setup Guide for SaaS Products

Custom portal domains sound like a small branding feature until they break.

A client expects to send customers to portal.theircompany.com, not a vendor subdomain. That one detail makes the portal feel native to their business. It also introduces DNS setup, certificate handling, hostname routing, support checks, and launch QA. If any part is wrong, the portal does not load, shows a browser warning, or opens the wrong tenant experience.

This guide is written for two audiences: SaaS teams building or supporting custom portal domains, and business owners following a vendor's setup instructions. The technical language matters, but the practical goal is simple: get the right customer to the right portal, on the right domain, over HTTPS.

How A Custom Portal Domain Works

A custom portal domain usually has four moving parts.

Step	Owner	What Has To Be True
Choose the hostname	Customer	The portal uses a subdomain such as portal.example.com
Add DNS	Customer	The hostname points to the SaaS platform's target
Match the tenant	SaaS platform	The incoming hostname maps to the correct account
Serve HTTPS	SaaS platform	The browser receives a valid certificate for that hostname

The support problem is that the customer usually controls DNS, while the SaaS platform controls routing and certificates. A good setup process makes that split obvious.

For Tregovia-specific positioning, see white-label client portal software with a custom domain.

The DNS Record Most Portals Use

Most SaaS portal setups ask the customer to create a CNAME record.

Example:

Type:  CNAME
Name:  portal
Value: target-hostname-provided-by-vendor.example
TTL:   300 to 3600 seconds, or provider default

The exact target must come from the SaaS vendor. Do not guess it from marketing pages or old support screenshots. A single typo can make the portal fail while still looking "almost right" in the DNS panel.

Common DNS mistakes:

• The customer creates an A record instead of the requested CNAME.
• A conflicting A or AAAA record already exists for the same subdomain.
• The record points at the apex domain instead of the portal target.
• The customer includes https:// or a path in the DNS value.
• A DNS proxy/CDN setting changes how traffic reaches the SaaS platform.

If the vendor gives a diagnostic page, use it. If not, a simple dig portal.example.com CNAME or DNS propagation checker can show whether the public record matches the expected target.

HTTPS Is Not Optional

Portal domains carry login links, form submissions, invoices, documents, or client account details. They need HTTPS from day one.

From the buyer's side, the launch check is straightforward:

• The portal opens with https://.
• The browser shows no certificate warning.
• The certificate is valid for the exact portal hostname.
• HTTP redirects to HTTPS.
• Login links and portal emails use the custom domain where expected.
• Key portal actions still work after the domain changes.

From the SaaS side, certificate provisioning and renewal must be owned operationally. Customers should not have to manually renew portal certificates every few months.

Hostname Routing Is The Part Users Do Not See

When a request reaches the SaaS platform, the platform has to answer: "Which tenant owns this hostname?"

If the routing layer cannot answer that reliably, bad things happen. The customer might see a generic error page. Worse, the wrong tenant's portal could load if hostname matching is loose. For a multi-tenant system, custom domains are not just branding. They are part of tenant routing.

A safe implementation needs:

• A stored custom domain value per tenant.
• Hostname validation before saving.
• Exact matching on incoming hostnames.
• A fallback for unknown hostnames.
• Tests or monitoring that catch routing misses before customers do.

Launch QA Checklist

Before sending the portal link to customers, run a small launch checklist.

Check	Pass Condition
DNS record	Public DNS points to the vendor-provided target
HTTPS	The portal loads without certificate warnings
Tenant routing	The correct business name, logo, colours, and data context appear
Login flow	Magic links, login forms, or access links still work
Portal task	At least one real task works end to end
Mobile test	The portal works on mobile data, not only office Wi-Fi
Old links	Any old portal links redirect or remain documented

The end-to-end task matters. A domain can load correctly while invoice payment, form submission, or login callbacks still use the wrong base URL.

Setting Up A Custom Domain In Tregovia

Tregovia's White Label & Branding add-on is the relevant module for custom portal domains. The module is EUR 99/month and includes custom domain, logo, brand colours, portal branding, and the option to remove the "Powered by Tregovia" badge from client-facing pages.

The verified implementation stores a custom domain on the tenant's branding settings and validates that the value is a proper fully qualified domain name: no protocol, no path, and no trailing slash. The settings area exposes custom-domain and branding fields when the White Label module is enabled for the tenant.

A conservative setup flow is:

1. Choose a portal subdomain, such as portal.yourbusiness.com.
2. Add the domain in Tregovia's branding settings.
3. Configure the DNS record using the target provided by the current deployment or support instructions.
4. Wait for DNS propagation.
5. Test the portal on the custom domain.
6. Confirm branding, login/access flow, and at least one portal task.

Do not assume automatic DNS verification, automatic certificate timing, or certificate-expiry monitoring unless those operational controls are confirmed in the running deployment. The codebase verifies domain shape and stores the branding configuration; production infrastructure still has to be checked before promising exact DNS or TLS behaviour publicly.

What To Ask A Vendor Before Launch

If you are buying SaaS with custom portal domains, ask the vendor:

• What exact DNS record should I create?
• Should the record be proxied or DNS-only?
• How is HTTPS provisioned and renewed?
• How do I know the domain has been verified?
• What happens if I later change DNS providers?
• Will portal emails and login links use the custom domain?
• Is the custom domain included, or is it a paid white-label add-on?

These are not edge-case questions. They are the questions support teams get after launch if the setup page is vague.

The Bottom Line

A custom portal domain is part brand experience and part infrastructure. Buyers see a cleaner portal URL. SaaS teams inherit DNS support, HTTPS reliability, and tenant routing responsibility.

For Tregovia, the safe public claim is that the White Label & Branding module supports custom domains and branding at EUR 99/month. Avoid promising automatic TLS timing, DNS verification buttons, or certificate monitoring unless those behaviours are verified in production infrastructure. That keeps the article useful without turning operational assumptions into product claims.

FAQ

What is the most common cause of custom domain setup failure?

Incorrect DNS. The CNAME target might be mistyped, the wrong record type might be used, or another record might already exist on the same subdomain.

Should I use the root domain or a subdomain?

Use a subdomain such as portal.example.com unless the vendor explicitly supports apex-domain setup. Subdomains are usually easier to route and less risky than moving the main website domain.

Who owns custom domain health?

The customer owns their DNS account and DNS records. The SaaS platform owns hostname routing, certificate handling, and portal availability once DNS points to the correct place.

What should I test before sharing the portal link?

Test HTTPS, branding, login or access links, mobile access, and one real portal task such as a form submission or invoice payment.

What does Tregovia support here?

Tregovia's White Label & Branding module supports custom domain and branding settings. The module costs EUR 99/month. Exact DNS targets and certificate operations should be checked against the active deployment instructions before rollout.