cPanel Email Routing: Local vs Remote Mail Exchanger

Web Hosting & Domains / cPanel / Mail routing

Choose Local Mail Exchanger when this cPanel server should receive the domain’s mail into its local mailboxes. Choose Remote Mail Exchanger for a straightforward setup where the domain’s mailboxes live at another provider. Confirm the receiving design before changing anything: where the website lives does not decide where email belongs.

This guide helps you choose the cPanel setting and investigate messages that take the wrong route. It is especially useful when outside email arrives normally but messages sent through the web host to your own domain fail or appear in an old inbox.

Compare Local, Remote, Backup, and Automatic

cPanel’s Email Routing documentation defines the receiving behavior below. Treat these as domain-level decisions, rather than a preference for a particular mail application.

“Remote” does not mean that staff work remotely. “Local” does not mean the business is in the same country as the host. The relevant location is the receiving mail service relative to this server.

A website and a mailbox can use the same domain name while relying on different services. Write the two responsibilities on separate lines in your notes. This prevents an apparently reasonable but incorrect shortcut: choosing Local solely because the website is on the cPanel account.

Confirm where the domain’s mail should arrive

Before opening the setting, gather a small, concrete record of the setup. You should be able to name the receiving provider, the affected domain, and at least one real address that must work.

• Identify the exact domain, including any separately configured mail subdomain.
• Confirm the mailbox provider with the person who manages business email.
• Record the current public MX answers and the provider’s required destinations.
• Save the current cPanel routing selection and a dated copy of the relevant local MX entries.
• List an individual mailbox and any important alias or shared address for testing.

cPanel’s Zone Editor shows DNS records for the selected domain and lets permitted users manage them. The presence of a record in that interface is evidence of what is stored there; also establish which service actually publishes the domain’s authoritative DNS.

Do not edit records simply to make two dashboards look alike. First explain any difference. Your host may need a local configuration adjustment while the public receiving records are already correct. Keep website DNS changes outside this troubleshooting step unless evidence identifies a separate website problem.

Automatic detection is not continuous public DNS monitoring

cPanel labels Automatically Detect Configuration as recommended, but its documentation says detection uses the local zone-file entry, without a live public DNS lookup. It also says the setting does not automatically change after an update. An Automatic label therefore needs checking after a mail-service change.

The WHM routing documentation explains the decision more precisely: a primary MX pointing here selects Local; this server appearing as a secondary receiver selects Backup; no MX pointing here selects Remote. If the MX destination cannot resolve, detection can retain the last known setting with a warning.

The practical implication is straightforward: a public DNS screenshot cannot tell you what the server selected from its local information. Compare the saved selection with the intended receiver. If they disagree, preserve both pieces of evidence before asking the host to correct the setup.

Avoid repeatedly switching Automatic off and on as a general repair ritual. You need a reason to expect the detected result to be correct. For an externally hosted mailbox service, ask the host whether an explicit Remote selection is appropriate for your particular configuration.

Change only the confirmed domain’s setting

cPanel’s support procedure directs users to open Email Routing, select the domain, choose the appropriate option, and click Change.

1. Capture the starting state. Save the domain name, selected option, time, and reason for the proposed change.
2. Open cPanel → Email → Email Routing. Check the domain selector, even if the account contains several similar names.
3. Select the confirmed mode. For a simple external mailbox arrangement, use the agreed Remote configuration; for mailboxes on this server, use the agreed Local configuration.
4. Click Change and reopen the interface. Verify the saved selection for that same domain.
5. Run fresh delivery checks. Keep the before-and-after record so you can distinguish improvement from an unrelated delayed message.

Schedule this work when someone can check the receiving inbox immediately. If the result contradicts the documented design, stop making additional changes and involve the host. Restoring the previous selection may be appropriate only if it is the known working configuration, rather than the configuration that caused the original fault.

Do not delete old mailbox data as part of changing a route. Decide separately what information must be retained and how it will be recovered. A successful new message is a useful acceptance check, but it is not a historical-data audit.

Test external and server-originated mail separately

Use a unique subject for each test and note the sender, recipient, and timestamp with timezone. Avoid customer data in test messages. The following matrix is a suggested diagnostic method, not a report of tests performed for this article.

If only same-domain notifications fail, investigate the host’s route without treating that pattern as proof. If all application messages fail, look at the application’s submission or SMTP connection too. If the application sends directly through an external service, inspect that service’s logs instead of assuming cPanel handled the message.

For a WordPress form failure after the routing checks, our Contact Form 7 delivery guide covers sender settings and the application-to-mail-service connection.

Use Track Delivery to identify the actual destination

Where your host provides it, open cPanel → Email → Track Delivery. Enter the recipient and run a report. The Track Delivery documentation describes recipient filtering and fields such as Result, Router, Transport, Delivery Host, and Delivery IP Address.

Match the record to your test time and address. Read the result and inspect the destination, rather than relying only on a success icon. A successful delivery into an unwanted old mailbox still fails your business requirement.

Record three separate observations: the application submitted a message, the mail system reported a delivery outcome, and the intended recipient found the message. Keep those observations separate when explaining the result to support.

Track Delivery is limited to stored Exim statistics; availability and retention depend on the host. cPanel also warns that third-party mail processing can make its results invalid. An empty report is therefore a reason to ask which logs cover your sending path.

cPanel documents one undeliverable-recipient case caused by incorrect routing. Preserve the exact error, but do not diagnose every similarly worded rejection as a routing fault.

Escalate gateways, split delivery, and unexplained routes

This simple Local-versus-Remote decision assumes one clear mailbox destination. A filtering gateway in front of local mailboxes, split delivery between systems, or an intentional backup receiver needs the administrator’s full routing design. Ask where a message should go at each stage before choosing a mode.

Your host can use WHM’s Mail Troubleshooter to trace a route to a specified address. A trace helps examine the path, but follow it with a real message and an inbox check.

Send support a compact evidence package: domain, intended receiver, saved routing choice, local and public MX observations, test timestamps, sender and recipient, message identifier if available, and the exact failure or unexpected destination. Ask which component needs changing and how the correction will be verified.

Frequently asked questions