Email Going to the Wrong Place After Moving to Google Workspace or Microsoft 365 Print

The symptom

Your domain's email is hosted with Google Workspace or Microsoft 365, but something is wrong with delivery. The usual signs:

• Some senders reach you fine, but emails sent from addresses on your own domain, or from other websites hosted with us, never arrive in your Workspace or 365 inbox.
• Contact form submissions from your own website never arrive.
• Mail seems to vanish without a bounce, or lands in an old cPanel mailbox nobody checks anymore.

If that pattern sounds familiar, the cause is almost always the same: our server still believes it is responsible for your domain's email, so any mail that originates on the server gets delivered locally into the cPanel mailboxes instead of being handed to Google or Microsoft.

Why it happens

Two separate settings control where your domain's mail goes, and they must agree:

1. Your MX records tell the rest of the world where to deliver mail for your domain. When you moved to Workspace or 365, these were pointed at Google's or Microsoft's servers, which is why most outside senders reach you fine.
2. The Email Routing setting in cPanel tells our server whether it should handle your domain's mail itself or pass it on. If this is still set to Local, the server ignores the MX records for any mail generated on the server, including your website's contact form and mail sent by other domains hosted on the same server, and delivers it into the local cPanel mailboxes instead.

This is why the problem looks so selective. Gmail users can reach you, but your own website's contact form cannot.

How to fix it

1. Log in to cPanel and open Email Routing (under the Email section).
2. Select your domain if you have more than one.
3. Change the setting from Local Mail Exchanger to Remote Mail Exchanger.
4. Save, the change takes effect immediately, no waiting period.
5. Test by submitting your own website's contact form and confirming it arrives in your Workspace or 365 inbox.

Leave the setting on Automatically Detect Configuration only if you understand its behaviour, it guesses based on the MX records, and an explicit Remote setting removes the guesswork. If your email is hosted with us, the setting should be Local. If your email is hosted anywhere else, it should be Remote.

Also worth checking after a move

• Old cPanel mailboxes. Any mail that was misdelivered locally is sitting in the cPanel mailboxes, log in to webmail and check before deleting the accounts, then remove them so this cannot recur silently.
• Your SPF record. If your website sends mail (contact forms, order confirmations from your online shop), your domain's SPF record needs to allow both your mail provider and our server, otherwise that website mail may be marked as spam. Open a support ticket if you are unsure, this is a one-line DNS fix on our side.
• The same applies in reverse. If you move your email back to us later, the MX records and the Email Routing setting must both change back, doing only one of the two recreates this problem in mirror image.

Good to know

If mail from your website worked for months after the move and then stopped, the likely trigger is that the hosting account was rebuilt, migrated to a new server, or had its domain re-added, all of which can reset Email Routing back to its default. It is worth checking this setting first whenever website-generated mail goes missing, before digging into anything more exotic.