cPanel Email Routing Explained: Fix Mail Loops and Bounces

You moved mail to Google Workspace or Microsoft 365, the MX records look correct in the zone editor, and yet mail either bounces with a weird "host unknown" error or loops back into the same inbox twice. Nine times out of ten, the MX records aren't the problem — cPanel's Email Routing setting is quietly overriding them.

What Email Routing Actually Does

Every cPanel account has a per-domain setting called Email Routing (find it under cPanel → Email → Email Routing, or in WHM under Server Configuration → Mail Routing for a whole server). It tells Exim, the mail server cPanel runs, whether it should treat itself as the final destination for a domain's mail or just pass it along somewhere else.

This setting sits on top of your MX records. DNS tells the sending mail server where to deliver a message. Email Routing tells the receiving server — your cPanel box — what to do once mail arrives, or whether it should even expect to receive it in the first place. When the two disagree, that's when things break.

The Symptom: Bounces or Duplicate Mail Despite Correct MX Records

Customers usually describe one of these:

• Mail sent to you@yourdomain.com bounces with 550 5.1.1 User unknown or relay not permitted, even though the mailbox exists on Google Workspace.
• Every email arrives twice — once in Workspace/M365, once in an old cPanel webmail inbox nobody uses anymore.
• A backscatter storm: your server keeps generating bounce-backs for mail it never should have accepted in the first place.

In every one of these cases, running dig MX yourdomain.com shows the correct records. The DNS is fine. The routing setting isn't.

The Three Routing Modes

Backup Mail Exchanger exists too, but it's rarely what you want unless you're deliberately running a secondary MX for queueing during outages.

Cause 1: Stuck on Local After Migrating to Google Workspace or Microsoft 365

This is the most common version. Someone points MX records to Google Workspace or Microsoft 365 but never revisits Email Routing. Because it was set to Automatically Detect back when cPanel was still handling mail, it locked in as Local and never re-evaluated. The result: Exim believes it's the final destination, accepts the message, delivers it into a local mailbox that no one checks, and Workspace never sees it — or in some setups, both do, hence the duplicates.

Worse, if a local mailbox with the same name doesn't exist, Exim generates a bounce, and depending on the sender's own security settings that bounce can turn into a backscatter loop.

Cause 2: Stuck on Remote While Still Hosting Mail on cPanel

The opposite problem. Email Routing is set to Remote, but the MX records still point at the cPanel server itself. Exim assumes some other host is going to handle the domain and refuses to accept mail as local, so anything sent to a mailbox that genuinely lives on cPanel bounces with relay not permitted or lands in the mail queue and eventually times out.

How to Check and Fix Email Routing

1. Log in to cPanel and open Email → Email Routing.
2. Select the domain from the dropdown at the top if you manage more than one.
3. Look at which radio button is selected, and compare it against where the mailboxes actually live:
   • Mail lives in Google Workspace / Microsoft 365 / another external provider → set Remote Mail Exchanger.
   • Mail lives in cPanel webmail → set Local Mail Exchanger.
4. Click Change. This takes effect within a few seconds — no propagation wait, since it's a local Exim config, not a DNS record.
5. If you manage several accounts on the same server, check WHM's Server Configuration tools for bulk local/remote domain management, or SSH in and grep the raw config:

grep -A1 "yourdomain.com" /etc/localdomains /etc/remotedomains

A domain listed in /etc/localdomains is treated as Local; in /etc/remotedomains, as Remote. If a domain you migrated away from cPanel is still sitting in localdomains, that confirms the diagnosis without needing to open cPanel at all.

Verifying the Fix

After switching to Remote, send a test message from an external account (Gmail works fine) to the mailbox on the new provider. Watch the mail log on the cPanel server while you do it:

tail -f /var/log/exim_mainlog

You want to see the message get accepted and immediately handed off — not queued, not bounced, and not appearing in a local Dovecot mailbox. If you switched to Local because mail genuinely lives on cPanel, send a test to confirm it lands in the cPanel webmail inbox rather than erroring out.

Give it five to ten minutes before declaring victory — some senders retry a failed delivery for a while, so an old bounce might still be working its way through even after you've fixed the setting.

Prevention: Revisit Routing Every Time Mail Hosting Changes

• Any time you move mail on or off a domain — to Workspace, M365, a different mail server, or back to cPanel — check Email Routing in the same session. It's easy to remember the MX record and forget the routing flag.
• Don't leave everything on "Automatically Detect" long-term. It only evaluates once, at save time, so it gives a false sense of "it'll sort itself out."
• If you manage many domains on one WHM server, periodically diff /etc/localdomains against your actual list of domains that should be hosting mail locally. It's a five-second sanity check that catches drift early.
• Document which domains use which provider somewhere your team can see — routing mistakes usually happen because the person changing MX records months later doesn't know mail was ever local in the first place.