Private nameservers are the most visible part of a white-label hosting business. Clients point their domains at ns1.yourbrand.com instead of a generic host's nameservers, and that instruction is the very first thing you ever send them, so if it carries someone else's domain, everything you do afterwards is decoration.
Setting them up takes two steps in two different places, which is exactly why so many resellers abandon it halfway and never notice.
The two halves, and why one alone does nothing
At your registrar you register the hostnames themselves and attach IP addresses to them. This is called creating glue records, and without it ns1.yourbrand.com does not exist anywhere on the internet.
In WHM you tell the server those are your nameservers, so new accounts get DNS zones pointing at them.
Doing only the WHM half is the common failure. The panel accepts the values, everything looks configured, and client domains fail to resolve because the nameserver names they were told to use resolve to nothing.
Step 1: glue records at the registrar
Log in where your own brand domain is registered, not the client's domain. Find the section called Host Records, Register a Nameserver, Glue Records or Child Nameservers; every registrar names it differently and hides it somewhere different.
Create two entries:
ns1.yourbrand.com → first IP from your welcome email ns2.yourbrand.com → second IP from your welcome email
Two nameservers is the minimum. Use both addresses if your plan provides two; if it provides one, both entries point at the same address, which works but gives no redundancy.
Registrar changes here can take a few hours to appear. That is normal and not something to retry repeatedly.
Step 2: tell WHM
In WHM, open Server Configuration then Basic WebHost Manager Setup. Enter the same two hostnames in the nameserver fields and save.
Type them identically to the glue records. A typo here produces zones pointing at a name that does not exist, and the symptom (a client's domain not resolving) gives no hint that a nameserver field is the cause.
Step 3: verify before telling anyone
This is the step that separates a working setup from one that silently is not.
dig ns1.yourbrand.com dig ns2.yourbrand.com
Each should return the expected IP address. If either returns nothing, the glue record has not been created or has not propagated yet: wait, then check again.
Then test the whole path with a real domain:
dig NS clientdomain.com
That should list your nameservers, and a lookup of the domain itself should return your server's address.
Do all of this before sending nameservers to a client. Debugging with a live client site is considerably less pleasant than debugging with your own test domain.
Existing accounts do not update themselves
Setting nameservers in WHM affects accounts created after the change. Accounts that already exist keep the zone values they were created with.
If you set this up after taking on clients, their zones still reference the old nameservers, and they will keep working, which is why this goes unnoticed, but the arrangement is inconsistent.
Update those zones through DNS Functions then Edit DNS Zone, changing the NS records to your hostnames. Do it one at a time and check each afterwards; a wrong NS record takes a domain offline until the correction propagates.
What clients need from you
Send exactly this, in the welcome message:
Nameserver 1: ns1.yourbrand.com Nameserver 2: ns2.yourbrand.com
Plus one sentence saying they set these at their domain registrar, and that changes take up to 24 hours to take effect everywhere.
That last sentence prevents most of the support messages this step generates. Without it, a client changes their nameservers, reloads twice, and contacts you fifteen minutes later convinced something is broken.
When it does not work
The nameserver name does not resolve. The glue record is missing or misspelled at the registrar. Nothing in WHM can fix this.
Nameservers resolve but the client's site does not load. The domain's nameservers have not been changed at the client's registrar, or the change has not propagated. Check with dig NS clientdomain.com.
Some visitors reach the site, others do not. Normal mid-propagation. It resolves on its own.
The domain resolves to the wrong site. DNS is correct but the account does not hold that domain properly. Check the account's document root rather than editing DNS further.
Everything works but email fails. The zone's MX record points somewhere else. Editing the zone is the fix, not the nameservers.
Where this sits in the setup
Private nameservers are the first of four places a client can see who your upstream host really is. The others are the cPanel interface, the automated emails the server sends, and the suspension page. Customising branding goes into all four.
Do this one before creating a single client account. Changing nameservers after clients have configured their domains means asking every one of them to change something, which is a conversation you would rather not have.
On a dedicated server you may be running the nameservers as well. For that side, see DNS and Nameserver Configuration on Dedicated Servers.
The server's own hostname has requirements of its own, and getting it wrong breaks mail clients rather than websites. Service Certificates and the Server Hostname has the detail.