The white-label checklist: what to ask a vendor after the logo upload

White-labelling fails in the places nobody demos. The logo upload always works. What decides whether a client's staff can use a platform for a year without meeting your vendor's name is the host inside the password-reset link, the domain that signed the notification email, the text in the browser tab, and the login page someone lands on cold at 8am before any session exists. Ask about those four before you ask about colours.

Every vendor says yes to "do you support white-labelling". The word covers everything from a hex code to a tenant that is genuinely yours, and both answers arrive in the same confident tone. What follows is a checklist for the call, written as questions rather than features: a feature list invites a yes, a question invites a demonstration.

What white-label means once you get past the logo

The useful test is not whether a client's logo appears. It is whether any moment in an ordinary week — signing in, resetting a password, opening an email, pasting a link into a ticket — surfaces the vendor's name. Walk that week out loud on the call.

The domain, and the parts of a session that leave it

A custom domain is the load-bearing piece; everything else is decoration on top of it. Five questions get you most of the way.

• Is a custom domain in the tier we are being quoted, or an add-on? Ask for the line item. Domains are a common upsell, and on older platforms a professional-services task rather than a setting.
• Who issues the TLS certificate, and what happens when it renews? Automatic issue and automatic renewal, or a ticket every few months. Ask what a learner sees the morning a renewal fails.
• One domain for the account, or one per organisation? If you run several client academies or campuses, ask at what depth a separate hostname stops being possible.
• Can we set it up ourselves? The good answer is a screen showing the exact DNS records for your registrar, and a live status while the certificate issues. The tell is an email thread with a support desk.
• Which parts of a session leave our domain? Downloads, video, the assessment player, certificate verification, an embedded help widget, the sign-on handoff. Ask them to open the network tab on a live tenant and read the hostnames out.

Email, and the link where the mask slips

Email is the half of white-labelling that quietly stays with the vendor. A From address is a display string and anyone can set one. What a mail client reads underneath is the domain that actually signed the message.

From: Northbridge Academy <no-reply@learn.northbridge.edu>   <- the display line
Return-Path: bounces@mail.vendor-lms.com                     <- the envelope sender
DKIM-Signature: ... d=vendor-lms.com ...                     <- the signing domain

Gmail puts a small "via vendor-lms.com" beside the sender when the signing domain does not match the From domain. Your client's IT department knows what that means. So ask:

• Which messages come from our domain, and which from yours? Ask for the full list — invitation, welcome, password reset, enrolment, reminder, grade released, certificate issued, digest, admin alert — then which of them can carry our sender.
• The From line only, or the signing domain too? The follow-up is which DNS records you publish. If none of them go at your registrar, the mail is not really leaving your domain.
• Our own sending account and key, or your shared pool? On a shared pool another tenant's bounce rate becomes your deliverability problem, invisibly.
• Per organisation, or once at the top? One sender for the whole account undoes the independence at the first email.
• Which logo does the email use, and where is it hosted? A vendor-hosted image shows its URL in the alt text whenever a mail gateway blocks remote images.

Then the link inside the message, where most evaluations find out the truth. The body can carry your logo, colours and sender, and the button in the middle of it can still point at the vendor's host — because invitation and reset links are usually minted by the authentication layer, configured once, globally, with a single site URL.

The login page, the tab and the two logos

The login page is the hardest page to brand and the first one every learner sees. Before anyone authenticates, the platform knows nothing about the visitor except the hostname they arrived on. If branding loads from a signed-in user's organisation, a cold visitor gets the vendor's default. Ask it in exactly these words: does branding resolve from the hostname alone, before any session exists?

• What renders at our domain for a visitor with no session? Logo, product name, colours, background, the wording on the sign-in button.
• Is there a "powered by" line, and what removes it? A toggle, a higher tier, or a clause in the contract. All three exist, and they cost different amounts.
• What do the error states look like? Wrong password, expired invitation, locked account — the pages most likely to be the vendor's default templates, and the ones a frustrated user reads most carefully.
• What is in the browser tab? The page title on every route, and the favicon. Ask whether the favicon is per organisation or one file for the whole platform; serving it from a single static path is a common shortcut.
• Are there two logos? A light-mode logo, a dark-mode one, usually a square mark as well. Ask what happens if you upload one and a user switches to dark mode.
• What is in the documents that leave the platform? Certificate PDFs, exported reports, transcripts. Check the footer, then the file metadata, where a vendor name survives longest.

Inheritance, and at what granularity

If you run more than one organisation — client companies, schools in a group, country subsidiaries — "does branding inherit?" is a granularity question rather than a yes-or-no one, and the granularity is where the work either disappears or multiplies.

• If a child organisation sets nothing, what does it get? The parent's brand, or the vendor's default. For a group the second is wrong: every new school starts life looking like the vendor.
• All-or-nothing, or field by field? A school that wants the group's palette and its own crest needs field-level fallback. Block-level inheritance makes every child restate fourteen colours to change one logo.
• Do the light and dark logos fall back as a pair? If they fall back independently, a child that uploads only a light logo strands the parent's dark logo against its new palette. A small question that produces an informative pause.
• Who is allowed to change it? The child's own administrator, or every change routed through your central team. The second is a support queue you will still be running in a year.
• How deep does it go? Two levels is common. A publisher with schools that have campuses needs more.
• Does terminology inherit as well as design? If you can rename "student" to "trainee", ask whether that cascades, and whether it is set separately per language.

Tests to run yourself

The mobile experience

First establish which thing you are being sold, because "we have mobile" covers two products with different branding stories. If it is a native app, the questions are commercial rather than cosmetic. Whose name is on the store listing? Who owns the developer account, and who submits releases? Is there a separate build per client, and a separate review cycle with it?

If it is a responsive web application, branding runs through the same code path as the desktop site, which is usually the better answer here. Ask to see it at phone width on your own domain, then ask what name and icon appear when a learner adds it to their home screen.

The page source

Someone will eventually open view-source — a client's IT team, a curious learner. You are not hiding anything; you are checking whether the platform was built to be served under someone else's name. Two commands answer most of it.

# Whose name is on the certificate served at your domain?
openssl s_client -connect learn.yourbrand.com:443 \
  -servername learn.yourbrand.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

# What do the HTML and the response headers say?
curl -sL https://learn.yourbrand.com | grep -io 'vendorname' | wc -l
curl -sI https://learn.yourbrand.com | grep -iE 'server|x-powered-by|content-security-policy'

The certificate check is the interesting one. Some platforms issue a certificate per customer hostname; others put many customers on one multi-name certificate. If the alternative-names list on your client's domain names other customers, that is public information about who else the vendor serves, and a security review will find it.

In the HTML, read the page title, the `og:site_name` tag, the web manifest, the hostnames the scripts and images load from, and the analytics and error-reporting endpoints in the content security policy header. Those endpoints are the most common giveaway, because nobody thinks of them as branding.

How to run the call

1. Ask for a live tenant on a domain you control, not a recorded demo. A day of DNS work is a cheaper test than a year of contract.
2. Have them send a real invitation and a real password reset to an address you control. Read the link target and the headers.
3. Open the login page cold, in a private window, in dark mode, on a phone.
4. Run the two commands above against your own hostname.
5. Collect the answers in a shared document, dated. "In development" is a fine answer written down and a poor one discovered in month four.

Press on the questions that produce a demonstration of a screen instead of an answer. That reaction is rarely evasion — it usually means nobody has asked before.

Where Lurno sits

Our own answers, including the unfinished parts. Domains are per organisation at any depth of the tree, set up from that organisation's own settings: type the hostname, publish the DNS records the screen shows you, watch the status until the certificate reads active, then flag it primary. Hostnames run through Cloudflare; TLS issues and renews automatically. The login page resolves logo, title, slogan, theme and background from the hostname alone, before anyone authenticates. Once a domain is primary, invitation links for that organisation are built on it.

Branding is seventeen fields — fourteen colour tokens, the display font, the body font, the corner radius — plus a light logo, a dark logo, a favicon, a title and a slogan. Inheritance answers the granularity question above: a sub-organisation with no theme takes the parent's whole theme, the logo pair inherits as a unit so you cannot strand a dark logo on a light background, and title, slogan and favicon fall back field by field. Terminology is renameable per language, and notification email leaves from the organisation's own subdomain. The full model is on the white-label page; who sends the mail is in the subprocessor list on security.

The gaps, plainly. There are no native mobile apps — Lurno is a responsive web application, so mobile carries the same branding as everything else, but there is no app in your name in a store, and native apps are on the roadmap rather than shipped. SAML and OIDC single sign-on are roadmap too; what exists today is partner sign-on, where your backend hands over a signed assertion for a learner it has already authenticated. Payments and checkout are in development.

White-labelling is not a feature switched on at signup. It is a property of where a vendor drew its boundaries years before you called, and those boundaries are readable in the address bar, the mail headers and the page source of a live tenant. Half an hour with a real domain settles more of this list than an afternoon of calls — ours included, which is what a demo is for.