You migrated your website to SkyServer, everything loads fine, but your inbox is a different story. Maybe you want Gmail's interface for your staff, or your company already runs on Microsoft 365 and you just need the website's email to follow. The good news: your web hosting and your email don't have to live on the same server. The DNS zone lets you split them cleanly — SkyServer keeps serving your site, Google Workspace or Microsoft 365 handles the mail. Here's how to do that cutover without a day of bounced messages in between.
Symptom: Mail Breaks After Adding Google or Microsoft's MX Records
This usually shows up in one of these ways:
- You add Google's MX records, but mail still lands in the old cpanel" class="auto-link">wordpress-missing-a-temporary-folder-upload-error" class="auto-link">cPanel webmail inbox, or bounces with "mailbox unavailable."
- New mail delivers fine to Gmail, but replies from old contacts still hit the cPanel account and nobody checks it anymore.
- Google Workspace shows "MX record not found" or "pending" for days after you saved the records.
- Outgoing mail from Google gets marked as spam because SPF still lists SkyServer's mail servers instead of Google's.
Almost all of this traces back to one thing: cPanel's built-in mail server (Exim) doesn't automatically step aside just because you changed the MX record.
Cause: Two Mail Servers Fighting Over the Same Domain
By default, when a domain is hosted on cPanel, WHM treats the server as "local" for that domain's email — meaning cPanel's Exim will try to deliver mail for yourdomain.com locally even if your MX record now points elsewhere. This is controlled by the domain's entry in /etc/localdomains on the server. If it's still listed there, Exim intercepts mail meant for Google or Microsoft and either delivers it into the old cPanel mailbox or rejects it outright.
On top of that, your existing SPF record (if you set one up for cPanel's mail server) will still say only SkyServer's IPs are allowed to send mail "from" your domain. Once Google or Microsoft starts sending on your behalf, that mismatch tanks deliverability — messages either bounce or get flagged.
Fix: Cut Mail Over Cleanly, Keep Hosting Where It Is
Step 1 — Tell cPanel to Stop Handling This Domain's Email
In WHM, go to Home > Service Configuration > Mail Server Configuration (called MX Entry in some WHM versions, or use DNS Zone Manager), find the domain, and set it to Remote Mail Exchanger instead of "Automatically Detect" or "Local Mail Exchanger." This removes the domain from /etc/localdomains so Exim stops trying to deliver mail locally and just passes it along based on the MX records you set. If you're on shared hosting and don't have WHM access, ask SkyServer support to flip this for your domain — it's a one-line change on their end.
Step 2 — Replace the MX Records
In cPanel, open Zone Editor, delete (or lower the priority of) any existing MX records, and add the provider's records. For Google Workspace, that's a single record:
| Type | Priority | Destination |
|---|---|---|
| MX | 1 | smtp.google.com |
(Older Google Workspace setups use five separate ASPMX records — if your admin console still shows those, use them exactly as listed; new accounts only need the single smtp.google.com record.)
For Microsoft 365, it's usually one record tied to your tenant:
| Type | Priority | Destination |
|---|---|---|
| MX | 0 | yourdomain-com.mail.protection.outlook.com |
Both Google and Microsoft give you the exact hostname during domain setup in their admin console — copy it from there rather than guessing, since the subdomain includes an account-specific string.
Step 3 — Add the Verification and Authentication Records
Both providers ask you to prove you own the domain before activating mail. This is usually a TXT record they generate for you, something like:
Type: TXT
Name: yourdomain.com
Value: google-site-verification=abc123... (or MS=ms12345678)Add it in Zone Editor, wait a few minutes, then click verify in the provider's console. Once verified, update SPF to authorize the new sender and drop any old entries pointing at SkyServer's mail IPs:
Google Workspace SPF:
v=spf1 include:_spf.google.com ~all
Microsoft 365 SPF:
v=spf1 include:spf.protection.outlook.com ~allThen enable DKIM in the Google Admin Console or Microsoft 365 Defender portal — both generate a CNAME or TXT record for you to add. Finally, set (or update) your DMARC record so mail from the new provider is covered:
Type: TXT
Name: _dmarc.yourdomain.com
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.comStep 4 — Handle Old Mail Before You Cut Over
Anything sitting in the cPanel mailbox stays there until you move it — changing MX records doesn't migrate existing mail. Export it first with an IMAP client (Thunderbird works well for bulk copies) pointed at the old cPanel mail server, then import into the new Google or Microsoft mailbox. Do this before you change the MX records, while the old server is still reachable.
Common Mistakes That Cause Downtime
| Mistake | What Happens |
|---|---|
| Changing MX without setting the domain to "Remote" in WHM | cPanel keeps intercepting mail locally, some messages vanish into the old inbox |
| Leaving old SPF include for SkyServer's mail servers | New provider's mail gets soft-failed or spam-flagged |
| Forgetting to migrate existing mail before cutover | Old emails become unreachable once local delivery is disabled |
| Not disabling cPanel webmail links/autodiscover for the domain | Users still see two different "webmail" logins and get confused about which one is live |
Prevention: Keep the Split Clean Going Forward
Once mail is live on the new provider, leave a note in your DNS zone (a comment isn't possible in most zone editors, but a shared doc works) explaining that MX intentionally points off-server. That saves the next person — or future you — from "fixing" it back to SkyServer's mail server during a routine DNS audit. Also turn off any cPanel email accounts for the domain once migration is confirmed, so nobody accidentally sends from the dead mailbox and wonders why replies never arrive.
Check mail flow with a dig MX yourdomain.com and dig TXT yourdomain.com a day after the change to confirm the records have propagated and match what the provider expects — most propagation finishes in under an hour, but caching resolvers can hold the old MX for the TTL period you had set.
Frequently Asked Questions
Will changing MX records affect my website?
No. MX records only control mail routing. Your A record (or CNAME, if you're using one) still points to SkyServer, so the site keeps loading exactly as before — this change only affects where email is delivered.
Do I need to move my domain's nameservers to Google or Microsoft?
No, and you shouldn't. Keep your nameservers pointed at SkyServer (or wherever your zone is managed) and just edit the MX, SPF, DKIM, and TXT records inside that existing zone. Moving nameservers would also move control of your A record and everything else.
How long until mail actually starts flowing through the new provider?
Usually within an hour once the "Remote Mail Exchanger" setting is applied and DNS has propagated, but it depends on the TTL your old MX record had. If it was set to 24 hours, some servers may keep trying the old route until that TTL expires — lowering the TTL to 300 seconds a day before the cutover makes this much faster.
What happens to email accounts I still have in cPanel?
They stay put but stop receiving new mail once the domain is set to Remote Mail Exchanger and MX points elsewhere. You can still log into cPanel webmail to read anything already there, or export it via IMAP, but treat it as archive-only after the cutover.
Can I run some mailboxes on Google Workspace and others on cPanel?
Not cleanly on the same domain — MX records apply to the whole domain, so all mail for yourdomain.com goes to whichever server is listed. If you need a genuine split, use a subdomain (e.g. route support@help.yourdomain.com through cPanel while the main domain goes to Google) with its own MX records.
