Understanding Email Routing in cPanel (and Why Mail Fails When It's Set Wrong)
Quick Answer: If your domain's email is hosted somewhere other than this server (Google Workspace, Microsoft 365, etc.), go to cPanel → Email → Email Routing, select the domain, and set it to Remote Mail Exchanger — not Local Mail Exchanger. Automatically Detect Configuration often fails to pick the correct setting, so don't rely on it alone; set Remote explicitly for any domain using an outside email provider. If it's left on Local while your email lives elsewhere, mail sent from this server (contact forms, other mailboxes on the account, etc.) will bounce or vanish into an unused local mailbox instead of reaching you.
What Is Email Routing?
Every domain on your hosting account has a setting in cPanel called Email Routing, found under the Email section. It answers one question: when someone sends a message to an address at your domain, should this server deliver it into a mailbox right here — or hand it off to wherever your email actually lives?
That question matters because plenty of domains don't use the hosting server for email at all. A domain might use Google Workspace, Microsoft 365, or another outside provider, while the website itself stays hosted here. Email Routing is what keeps the website and the email working together, instead of working against each other.
The Three Routing Options
| Setting | What It Does | When To Use It |
|---|---|---|
| Automatically Detect Configuration | cPanel checks your domain's MX records and picks the correct setting automatically. | This is the default, but it frequently gets it wrong — especially after MX records change. Don't assume "Auto" is actually routing correctly; verify it or set Remote explicitly. |
| Local Mail Exchanger | Forces the server to treat itself as the final destination and deliver mail into a local mailbox. | Only when this hosting account is genuinely where your mailboxes live. |
| Remote / Backup Mail Exchanger | Forces the server to look up your real MX records and relay mail out to your actual provider. | When you want to explicitly confirm email is hosted elsewhere (Google, Microsoft, etc.). |
Why "Local" Breaks Mail When You're Using a 3rd-Party Provider
Here's the scenario behind almost every confusing "my email just disappeared" ticket: a domain has its email hosted elsewhere — most often Google Workspace or Microsoft 365 — but Email Routing on the hosting account is still set to Local Mail Exchanger.
Mail arriving from the outside world usually reaches Google or Microsoft just fine, because outside mail servers look up your MX records directly and never touch this hosting server at all. Nothing looks wrong from the sender's side.
The trouble starts with mail that passes through this server:
- A WordPress contact form
- A shopping cart order notification
- A PHP script's
mail()function - One mailbox on the account emailing another address at the same domain
Because Email Routing says "Local," the server assumes it owns that domain's email and tries to deliver the message into a local mailbox instead of relaying it out to Google or Microsoft. From there, one of two things happens:
- No matching mailbox exists on the server: the message bounces outright, usually with an error like "user unknown" or "mailbox does not exist" — even though that same address works perfectly well over at Google Workspace.
- A mailbox with that name does exist (often left over from before the domain switched providers): the message gets delivered into that old, unmonitored mailbox instead. It doesn't bounce, it doesn't error out — it just quietly vanishes, since nobody checks it anymore.
This is why the complaint usually sounds like:
"People outside can email me fine, but my website's contact form emails never arrive."
"I can't send myself a test message from another address on the account."
Both point to the same root cause.
Why This Happens Even When "Nothing Was Changed"
Most of the time, nobody flipped a switch by mistake. It happens because Automatic Detection only checks your MX records at the moment it runs — usually when the domain was first set up. If email was hosted on this server originally and later moved to Google Workspace or Microsoft 365, cPanel doesn't automatically notice and re-check. The domain is left set to Local from before the move, quietly conflicting with the new MX records ever since.
Even re-running Automatic Detect isn't a guaranteed fix. In practice, it often misreads the MX records and leaves (or resets) the domain to Local even when the correct MX records are in place — particularly if there's more than one MX entry, if DNS changes haven't fully propagated, or due to how cPanel caches the domain's mail configuration. Because of this, the most reliable fix for any domain using an outside email provider is to set Email Routing to Remote Mail Exchanger explicitly, rather than leaving it on Auto and assuming it detected correctly.
How To Check and Fix It
- In cPanel, go to Email → Email Routing.
- Select the domain in question and note which option is currently selected.
- If the domain uses an outside provider (Google Workspace, Microsoft 365, etc.), set it to Remote Mail Exchanger directly. Don't rely on Automatically Detect Configuration to catch this correctly — it frequently doesn't.
- Never leave it on Local Mail Exchanger while a 3rd-party provider is handling that domain's mail.
- Send a test message from a mailbox on the same hosting account to an address at the affected domain, and confirm it lands in the 3rd-party inbox rather than bouncing.
Quick Way To Tell Which One You Need
| Your MX Records Point To… | Correct Email Routing Setting |
|---|---|
Google (aspmx.l.google.com and similar) |
Remote Mail Exchanger |
Microsoft 365 (*.mail.protection.outlook.com) |
Remote Mail Exchanger |
| This hosting account itself | Local Mail Exchanger |
