In cPanel's Email Routing tool, each domain has a routing mode: Automatically Detect Configuration, Local Mail Exchanger, Backup Mail Exchanger, or Remote Mail Exchanger. If email for a domain is bouncing, looping, or not arriving in the mailbox you expect, this setting is almost always the reason. For a domain hosted with us and using our mail servers, the correct mode is Local Mail Exchanger. If you're sending that domain's mail somewhere else (Google Workspace, Microsoft 365, another provider), it needs Remote Mail Exchanger.
What each mode actually does
Mail routing controls whether the server treats itself as the final destination for a domain's mail or hands it off elsewhere:
- Local Mail Exchanger: the server accepts mail for the domain and delivers it into local mailboxes on this account. Use this when your mailboxes live in cPanel and you access them via
mail.yourdomain.comor webmail. - Remote Mail Exchanger: the server does not deliver mail locally at all. It assumes another server (Google, Microsoft, or any other mail host) is the real destination and won't create local mailboxes for the domain, even if some exist.
- Backup Mail Exchanger: the server queues mail temporarily and tries to relay it to the domain's real mail server, for cases where you're running a secondary MX as a fallback. Most hosting customers never need this.
- Automatically Detect Configuration: cPanel looks at the domain's MX records and DNS to guess whether mail should be local or remote, and picks accordingly. It's the default and works fine most of the time, but it can guess wrong right after a DNS change, which is why manual override exists.
Why this breaks in practice
The most common failure case: a domain is hosted with us, but its MX records point to Google Workspace or Microsoft 365 for email, while the website stays on our server. If cPanel's automatic detection (or a stale manual setting) treats that domain as Local Mail Exchanger, incoming mail addressed to the domain gets delivered into local cPanel mailboxes that nobody checks, instead of reaching Google or Microsoft. The sender sees a successful delivery, but the recipient never sees the message, because it landed in a mailbox on our server instead of the one they actually use.
The reverse problem also happens: a domain using our mail servers gets set to Remote Mail Exchanger, usually left over from a previous external mail provider. Mail addressed to that domain then gets treated as someone else's responsibility and can bounce or vanish, since the server won't accept it as local delivery.
How to check and fix it
In cPanel, go to Email → Email Routing, and select the domain from the dropdown if you manage more than one. The current mode is shown with a radio button selected. To fix a mismatch:
- Confirm where the domain's mail actually should go. Check the MX records for the domain in
DNS Zone Editorunder your hosting service, or check your DNS provider if the domain's nameservers point elsewhere. - If MX records point to us (or you're using our provided mail service with default MX records), set the domain to
Local Mail Exchanger. - If MX records point to Google Workspace, Microsoft 365, or another external mail service, set the domain to
Remote Mail Exchanger. - Save the change. It takes effect immediately for new mail; anything already misrouted before the fix needs to be manually recovered from wherever it landed.
If you're not sure which MX records are currently live, check them in DNS Zone Editor under your hosting service. If they show your registrar's, Google's, or Microsoft's mail servers rather than ours, the domain's routing should be Remote Mail Exchanger.
Automatic detection isn't always wrong to rely on
Leaving a domain on Automatically Detect Configuration is fine as a default, and it re-evaluates when DNS changes propagate. But right after you switch a domain's MX records, whether toward us or away from us, there's a window where detection can lag or misread the state. If you just changed where a domain's mail is hosted and messages are behaving oddly, don't wait for auto-detection to catch up: set the mode explicitly to match where mail should actually land.
When to contact support
If you've confirmed the MX records and the routing mode is already correct but mail is still missing, bouncing, or delayed, open a ticket from the portal (Support → New ticket) or use live chat. A real person can dig into what happened with a specific message and help you sort it out.