Custom Domains: Run empowsec Training on Your Own Domain

Why the Training Portal Address Matters
Security awareness training teaches employees one reflex above all others: look at the domain before you trust a page. So consider what happens when your own training program arrives on a domain nobody in the company has ever seen. Employees who have internalized that lesson hesitate, forward the invitation to IT as a suspected phishing attempt, or simply ignore it. The training platform ends up fighting the very instincts it is trying to build - and every extra moment of doubt costs completion rates.
empowsec resolves that tension by letting each company serve its training portal from a domain it already owns. Instead of asking employees to trust an external address, administrators point something like training.yourcompany.com at the platform, and every login page, course player, and reporting view answers on that familiar hostname. The address bar itself becomes a trust signal, and adoption follows naturally from recognition.
Setup: One CNAME Record on Your Own Domain
The technical model is deliberately simple. Your subdomain points at the empowsec ingress host - app.empowsec.com by default - with a standard CNAME record. Apex domains, which cannot always carry a CNAME, can use A or AAAA records against the platform's published ingress addresses instead. Everything you need is displayed directly in Settings - Branding: the record type, the host, the target value, and a suggested TTL of 3600 seconds, ready to paste into your DNS provider's console.
Before a domain is accepted, empowsec normalizes and validates the input. The platform lowercases the value, strips any protocol prefix or path fragments, and checks the result against a strict hostname pattern. Reserved names - the platform's own domains and infrastructure hosts - are rejected outright, and a domain that is already registered or requested by another company cannot be claimed twice. That validation happens at request time, so typos and conflicts surface immediately rather than after a day of DNS troubleshooting.
DNS Verification with a Live Status Badge
Adding a domain does not switch anything over by itself; proof comes first. empowsec asks for two DNS records. The first is an ownership proof: a TXT record on a dedicated verification host (prefixed with _empowsec-domain-challenge) carrying a unique token generated for your request. The second is the traffic record itself - the CNAME, or the A or AAAA entries for apex domains, that actually routes visitors to the platform. Ownership and routing are checked independently, which prevents anyone from pointing a domain they do not control at another organization's training portal.
The Settings - Branding page tracks the whole lifecycle with a live status badge. A domain moves from pending DNS through DNS verified and provisioning to active; a failed provisioning attempt is flagged clearly. Every verification click is recorded with a last-checked timestamp, and a successful check stores the exact verification time. If something is wrong, the failure reason states precisely which record is missing - the TXT proof, the traffic record, or both - so administrators know exactly what to fix without opening a support ticket.
From Verified to Live
Once DNS verification succeeds, the remaining step is provisioning: preparing the web server routing and TLS so the custom hostname serves the portal securely. empowsec supports two modes. In manual mode, the domain rests at DNS verified until the operations team activates it. With automatic provisioning enabled, a successful verification immediately queues a background job that provisions the domain and activates it without any further action from the administrator. Either way, activation switches the portal over cleanly and clears any cached domain lookups, so the branded experience is consistent from the very first request on the new hostname.
A Secure Login Handoff Between Domains
Certain sensitive flows - entering payment details through Stripe Elements, for example - are intentionally kept on the primary empowsec domain rather than replicated across every customer hostname. That raises an obvious question: how does a user who is signed in on training.yourcompany.com continue seamlessly on the primary domain without logging in twice?
The answer is a purpose-built cross-domain authentication handoff. When a user needs to cross over, empowsec shows a brief interstitial page explaining the redirect, then forwards the browser with a single-use token. On the primary domain, that token is consumed atomically: it expires quickly, can never be replayed, and the endpoint is rate limited to ten attempts per minute. The session is regenerated on arrival, and the user lands on the intended page already authenticated. If a token is expired or invalid, the flow fails closed to the login screen rather than guessing. Security is preserved on both sides of the boundary; the user simply experiences a smooth, explained redirect.
Custom Domains and the Rest of the White-Label Story
The custom portal domain is the company-level piece of a larger branding toolkit. It pairs naturally with empowsec's company branding settings - logo upload, accent color, and a forced light or dark theme - which we have covered separately. Resellers and MSPs have their own, deeper white-label layer for operating the platform as their own product across many client companies. A company that simply wants its employees to train under its own name needs exactly what is described here: one domain, two DNS records, one verify click.
Combined with security awareness training content, phishing simulation, and reporting dashboards, a familiar domain closes the loop: the platform that teaches employees to scrutinize addresses now lives at an address that passes that scrutiny.
Key Takeaways
- Serve the empowsec training portal from your own domain via a standard CNAME record; apex domains can use A or AAAA records.
- Domains are normalized, validated, checked against reserved names, and protected from duplicate claims across companies.
- Verification pairs a TXT ownership token with a traffic record check, backed by a live status badge, verified timestamp, and precise failure reasons.
- After verification, provisioning can run automatically as a background job or be activated manually by operations.
- A rate-limited, single-use token handoff keeps logins seamless and secure when users cross to the primary domain for sensitive flows.


