cPanel August 12, 2026 47 views

How to Use Vercel for Your Website and Keep cPanel for Email

There is a common misconception that moving a site to Vercel means abandoning cPanel. It doesn’t. The two are not competitors in this setup — Vercel serves your web traffic, cPanel keeps handling mail, and DNS is the seam between them.

The important thing to understand up front: you never install anything from Vercel inside cPanel. There is no plugin, no app, no upload. The entire connection happens through DNS records. You edit two records, leave the mail records alone, and the split is done.

Here is how to do it properly, including the parts that quietly break email if you rush.

Before you start: is cPanel actually your DNS?

This is the step people skip, and it’s the one that wastes an afternoon.

Editing records in cPanel’s Zone Editor only affects the real world if your domain’s nameservers point at your cPanel host. Check your registrar and look at the nameservers on the domain:

If they read something like ns1.yourhost.com / ns2.yourhost.com and belong to your hosting provider → edit DNS in cPanel.
If they read *.cloudflare.com, *.registrar-servers.com (Namecheap), *.domaincontrol.com (GoDaddy), or anything else → edit DNS there instead. Changes in cPanel will save happily and do absolutely nothing.

You can confirm from a terminal:

bash

dig NS example.com +short

Whatever comes back is where your records actually live.

Step 1 — Add the domain in Vercel

In the Vercel dashboard: Your Project → Settings → Domains → Add Domain.

Add both forms:

example.com
www.example.com

Vercel will then display the exact records your project needs. <cite index=”2-1″>Apex domains (example.com) are configured with an A record; subdomains such as www are configured with a CNAME.</cite> <cite index=”1-1″>The reason for the A record at the apex is RFC 1034 — if a CNAME record exists at a node, no other data can exist there, and an apex must carry NS records and usually MX records for mail, so a CNAME at the zone apex would break the zone.</cite>

Copy the values Vercel shows you. Do not copy them from a tutorial, including this one. <cite index=”3-1″>The long-standing general-purpose anycast address is 76.76.21.21, but newer projects draw from a pool of anycast IPs matched to the plan and project, so your domain card may show something different such as 216.198.79.1.</cite> The www target is similarly project-specific — often a hostname in the form cname.vercel-dns-xxx.com. Include the trailing dot if Vercel displays one.

Step 2 — Open the Zone Editor in cPanel

Domains → Zone Editor → yourdomain.com → Manage.

Before touching anything, take a screenshot or export the zone. If something goes wrong at 2 a.m., you want the original values.

Step 3 — Repoint the apex A record

Find the existing record:

Name	Type	Value
example.com	A	your cPanel server IP

Change the value to the IP Vercel gave you. Leave the name and type as they are.

Also delete any AAAA record on the apex. This one catches people. <cite index=”3-1″>Vercel does not support IPv6 for custom domains added through a third-party DNS provider, so an AAAA record pointing at another host splits traffic between providers and can stall SSL provisioning.</cite> If your cPanel server has IPv6 enabled, that record almost certainly exists.

Step 4 — Configure www

Delete any existing www A record or conflicting CNAME first — a stale A record pointing at the cPanel IP will keep serving the old site to a portion of visitors, and the symptom (site loads for you, not for the client) is maddening to debug.

Then create:

Name	Type	Value
www	CNAME	the value from your Vercel domain card

Step 5 — Leave the mail records completely alone

This is the whole point of the exercise. Moving the website does not move the mailbox. These stay exactly as they are:

Record	Type	Keep pointing at
example.com	MX	cPanel mail server
mail.example.com	A	cPanel server IP
webmail / cpanel / autodiscover	A or CNAME	cPanel server
DKIM	TXT	existing cPanel value
DMARC	TXT	existing value

MX records control where mail for the domain is delivered, and they are entirely independent of the A record that controls where the website lives. admin@example.com keeps working, webmail keeps working, your mail clients keep working.

The one email record you must review: SPF

Here is the trap that turns a clean migration into a deliverability incident a week later.

cPanel’s default SPF record looks like this:

v=spf1 +a +mx +ip4:123.123.123.123 ~all

The +a mechanism means “authorise whatever IP the domain’s A record resolves to.” You just changed that A record to Vercel. From this moment, your SPF record authorises Vercel’s anycast IP to send mail as your domain — and no longer authorises your actual mail server via that mechanism.

You may be saved by +mx or the explicit +ip4: entry, but relying on that is luck, not configuration. Fix it explicitly:

v=spf1 +mx +ip4:YOUR_CPANEL_MAIL_SERVER_IP ~all

Drop the +a. Add any third-party senders you use (include: for a transactional mail provider, a newsletter tool, etc.). Keep it to one SPF record — <cite index=”10-1″>two TXT records starting with v=spf1 cause both to fail</cite> — and <cite index=”10-1″>stay under the 10-lookup limit, since each include: or redirect: counts as a DNS lookup and exceeding it returns a permanent error</cite>.

After the change, cPanel’s Email Deliverability page should still show green for SPF and DKIM. Check it.

Step 6 — Verify in Vercel

Back in Vercel → Project → Settings → Domains, you’ll likely see Invalid Configuration at first. That’s expected while the old records are still cached.

Once DNS resolves to the new values, the status flips to valid and Vercel provisions the TLS certificate automatically. <cite index=”6-1″>Propagation can take anywhere from 30 seconds to 48 hours, though with a one-hour TTL most resolvers worldwide are usually updated within 5–15 minutes.</cite>

Verify independently rather than trusting the dashboard alone:

bash

dig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short

That third command is your safety check. If the MX answer still shows your cPanel mail server, email is fine.

If the certificate won’t issue

Two causes account for most cases:

A leftover AAAA record on the apex or www (see Step 3).
A CAA record restricting which certificate authorities may issue for your domain. If your zone has a CAA record from a previous SSL setup, it must permit Let’s Encrypt — add 0 issue "letsencrypt.org" — or Vercel’s issuance request will be refused.

Optional: keep part of the domain on cPanel

The split doesn’t have to be all-or-nothing. Because subdomains are just independent records, you can run a hybrid:

Hostname	Points to	Purpose
example.com	Vercel	Next.js / React front end
www.example.com	Vercel	same
app.example.com	Vercel	separate Vercel project
api.example.com	cPanel server IP	Laravel or PHP API
blog.example.com	cPanel server IP	WordPress
mail.example.com	cPanel server IP	mail

This is a genuinely useful pattern: a fast static or SSR marketing front end on Vercel’s edge network, with a WordPress or WooCommerce install still running on cPanel under a subdomain, and everything sharing one domain and one mailbox.

If you do this, remember that the cPanel account still needs the subdomain created under Domains → Subdomains, and it will need its own AutoSSL certificate — Vercel only issues certificates for the hostnames it serves.

The summary version

Name	Type	Value	Who owns it
example.com	A	Vercel-provided IP	Vercel
www	CNAME	Vercel-provided target	Vercel
example.com	MX	existing mail server	cPanel
mail	A	cPanel server IP	cPanel
SPF	TXT	rewritten without `+a`	cPanel
DKIM / DMARC	TXT	unchanged	cPanel

Two records changed, one record reviewed, everything else untouched. Deploy from Git on Vercel, keep your mailboxes, backups, cron jobs and databases in cPanel, and let DNS handle the handoff.

Was this article helpful?