How to Change a cPanel Account's Primary Domain Safely

You built the site on a subdomain, or the account was provisioned under a placeholder domain during onboarding, and now the "real" domain needs to be the one cPanel treats as primary. It sounds like a text-field edit. Get it wrong and you can lose your SSL certificate, break email delivery, and wipe out custom DNS records you forgot you had.

What "Primary Domain" Actually Means in cPanel

Every cPanel account has exactly one primary domain, set when the account was created in WHM. It's easy to assume this is just a label, but it anchors several things at once:

• The default document root the account was built around (usually /home/username/public_html)
• Which domain cPanel treats as "main" versus addon, parked, or subdomain in the account's domain list
• The default identity used for AutoSSL's first certificate request and for the account's default email routing
• What shows up in WHM's account list, billing records, and support tickets referencing this account

Here's the part that trips people up: changing the primary domain does not rename the cPanel username or move the home directory. Your files stay exactly where they are — WHM just changes which domain points at that document root by default.

When You'd Actually Want to Change It

This isn't something you touch often, but a few situations come up regularly in support:

• A site launched on a temporary or staging domain and the real domain is only now ready to go live
• A rebrand — the company changed its name and the old domain needs to become secondary
• An addon domain has effectively become "the site" and the original primary domain is now unused or parked
• A reseller inherited an account where the primary domain was set incorrectly during a migration

What Breaks If You Just Change the Field and Walk Away

The WHM field looks harmless. The side effects aren't, if you don't plan for them.

SSL certificate mismatch

If AutoSSL issued a certificate for the old primary domain, that certificate doesn't automatically transfer its "primary" status to the new domain. Visitors on the new domain can hit a certificate name mismatch warning until AutoSSL runs again and reissues for the new set of domains.

Custom DNS records can get wiped

If the account uses a custom nameserver setup inside WHM (not just the default zone WHM generates), changing the primary domain can regenerate the DNS zone and drop custom records — MX overrides, TXT records for SPF/DKIM, verification TXT records, custom subdomains. If you've added anything by hand in Zone Editor, export it first.

Email routing gets confusing fast

Mailboxes are tied to the domain they were created under, not to "whichever domain is primary." Existing mailboxes on the old domain keep working, but new mail routing decisions (local vs. remote, the account's default catch-all behavior) follow the new primary domain. Test send/receive on both domains after the change — don't assume it inherited correctly.

Hardcoded absolute paths and site URLs

If the site is WordPress, WooCommerce, or anything with a stored site URL (wp_options, config files, absolute image paths), changing the primary domain in cPanel changes nothing there automatically. The application still thinks its home is the old domain until you update it — see our guide on fixing old URLs after a migration if that's the exact symptom you hit afterward.

How to Change It the Right Way

This requires WHM (root or reseller) access. If you're on managed Getwebup hosting without WHM access, open a ticket and we'll do this for you — it takes us a few minutes and we handle the SSL/DNS follow-up in the same pass.

Before you touch anything

1. In WHM's Zone Editor, export or screenshot any custom DNS records on the account — anything beyond the default A, MX, and NS records WHM generated.
2. Confirm the new domain's nameservers or A record already point at this server. If they don't, do that first and let it propagate — don't change the primary domain and fight DNS propagation at the same time.
3. Note whether the new domain currently exists on the account as an addon domain. If it does, you'll be promoting it; if it doesn't, WHM will just add it as the new primary.
4. Pick a low-traffic window. Email routing and SSL can both have a short gap while things settle.

Making the change

1. In WHM, go to List Accounts and click the pencil/edit icon next to the account, or search for Modify Account directly.
2. Find the Domain (Primary Domain) field near the top of the Basic Information section.
3. Replace it with the new primary domain.
4. Scroll down and click Save.

Right after the change

• Run AutoSSL for the account manually (WHM → SSL/TLS → Run AutoSSL → Run for a single user) instead of waiting for its next scheduled pass, so the certificate covers the new domain immediately.
• Reopen Zone Editor and re-add any custom DNS records that didn't carry over.
• Send a test email to and from both the old and new domain to confirm routing didn't silently break.
• If the old domain should keep working, add it back as a parked or addon domain pointing at the same document root — don't just let it dangle unconfigured.
• If it's WordPress, update the site URL and home URL (via wp-config.php or wp-cli, not just Settings → General, if the old domain is now unreachable) and search-replace any hardcoded old-domain URLs in the database.

Prevention: Set It Up Right the First Time

The cleanest fix is avoiding the change entirely. When you provision a new account, use the real, final domain as the primary domain from the start — even if the site isn't live yet — and point a temporary staging subdomain at it instead. Renaming a subdomain is trivial; renaming a primary domain touches SSL, DNS, and email all at once. If you're not sure which domain will end up being "the" domain long-term, that uncertainty is worth resolving before the account gets built, not after.