With the function Email routing In cPanel, you define how the mail server of your CURIAWEB hosting handles emails for a specific domain.
This setting is especially important if your website is hosted with CURIAWEB, but your emails are handled by an external provider such as Microsoft 365, Google Workspace, or another mail service.
In this guide, we will show you how to control email routing in cPanel, when Local Mail Exchanger or Remote Mail Exchanger is required and why an incorrect setting can lead to delivery problems.
Important: Do not change the email routing on suspicion. An incorrect setting can cause messages within the server to be delivered to the wrong location or prevent local senders from correctly reaching an external mail service.
When do you even need to change the email routing? #
If your website and email are run entirely through your CURIAWEB hosting and everything is working, you normally do not need to change the routing setting manually.
It becomes especially relevant when the services are separated.
A classic example:
Your website your-domain.ch is hosted at CURIAWEB, but the domain's email accounts are hosted at Microsoft 365.
In this case, the CURIAWEB server must know that emails for @your-domain.ch should not be delivered locally, but belong to the externally responsible mail server.
MX Record and Email Routing: The Important Difference #
Before changing a setting, you should distinguish between two things.
The MX records in the DNS, specify which mail servers are responsible for receiving emails for a domain.
The Email routing in cPanel, on the other hand, determines how the local mail server should handle emails for this domain.
Briefly explained: MX records publish in the DNS where emails for a domain should be delivered. cPanel email routing determines whether the local mail server treats the domain itself as a local destination or forwards emails to an external mail server.
You can manage the MX records yourself via the cPanel Zone Editor. We show how this works under Using the DNS Zone Editor in cPanel.
1. Open email routing in cPanel #
Log in to your CURIAWEB cPanel.
Scroll to the section Email and click on Email routing.
If there are multiple domains in your hosting account, you must first select the domain whose routing you want to check or change.
Attention: Be sure to check the selected domain. The routing setting applies to the respective domain and not globally to all domains in your hosting account.
2. Check current routing settings #
cPanel shows you the routing configuration available or detected for the selected domain.
Depending on the interface and server configuration, options such as the following may be displayed:
- Auto-detect configuration
- Local Mail Exchanger
- Backup Mail Exchanger
- Remote Mail Exchanger
Before you change anything, you should know where the email accounts of the domain in question are actually hosted.
3. Decide where your domain's emails are hosted #
The crucial question is:
Should the CURIAWEB mail server manage the mailboxes for this domain itself, or are the mailboxes located on an external mail server?
If you cannot answer this question with certainty, you should not change the routing setting manually.
Local Mail Exchanger – E-mail is hosted at CURIAWEB #
Local Mail Exchanger means that the local mail server treats emails for the selected domain as messages to be delivered locally.
This setting is generally appropriate if the domain's email accounts are set up on your CURIAWEB hosting.
For example, the following mailbox exists in cPanel:
info@deine-domain.ch
and CURIAWEB is responsible for the email service of this domain.
Then the server must send emails for your-domain.ch be able to process locally.
Rule of thumb: If the actual email mailboxes of the domain are hosted on your CURIAWEB hosting, the domain is considered a local mail destination from the perspective of this server.
Remote Mail Exchanger – E-mail is hosted externally #
Remote Mail Exchanger means that the local server should not treat emails for the domain in question as locally deliverable messages.
This setting is typically required when the website is hosted on CURIAWEB, but the domain's email services are operated on external mail servers.
This can be the case, for example, with services like Microsoft 365, Google Workspace, or another external mail platform.
In this case, the CURIAWEB server should not look for messages for the domain in local mailboxes, but should use the external mail route.
Important: Simply entering external MX records is not always sufficient in certain local delivery situations if the hosting server continues to treat the domain as a local mail destination. DNS and local email routing must match the actual mail architecture.
Backup Mail Exchanger – only for corresponding mail configurations #
The option Backup Mail Exchanger is intended for configurations where the server acts as a backup mail server for a domain.
The primary mail server is located at a different destination. The backup mail server can take over messages when primary delivery is temporarily unavailable and forward them later.
This is not a normal setting for the „My emails are hosted externally“ scenario.
Attention: Choose Backup Mail Exchanger not simply as an interim solution between local and remote. This option requires a dedicated mail server configuration.
What does „automatically detect configuration“ mean? #
cPanel can try to detect the appropriate routing type based on the existing mail or DNS configuration.
That is convenient, but it does not replace an understanding of where your email is actually hosted.
Especially during a domain migration, a DNS change, or a switch to an external email provider, you should check whether the detected configuration matches the desired setup.
4. Configure Local Mail Exchanger #
If the email accounts of the selected domain are hosted on your CURIAWEB hosting and manual setup is required, proceed as follows:
- Open Email -> Email Routing.
- Select the correct domain.
- Choose Local Mail Exchanger.
- Save the change using the designated button.
The server subsequently treats the domain accordingly as a local mail destination.
5. Configure Remote Mail Exchanger #
If the email accounts of the domain are operated entirely via an external mail provider and manual setup is required:
- Open Email -> Email Routing.
- Select the relevant domain.
- Verify that the MX configuration points to the designated external mail service.
- Choose Remote Mail Exchanger.
- Save the change.
This tells the local mail server not to treat the domain as a local mail destination.
Important: Remote Mail Exchanger does not replace correct MX records. If emails are hosted externally, the DNS settings of the external mail service must also be configured correctly.
6. Check the MX records after a change #
If you changed the routing because of an external mail service, you should also check whether the domain's MX records actually point to the correct mail servers.
The respective email provider specifies which MX values are required.
Adopt these values exactly. Do not invent your own hostnames and do not replace given mail servers with the IP address of your website.
Processing is done via the DNS Zone Editor in cPanel, provided that your domain's DNS zone is managed via the corresponding CURIAWEB environment.
7. Send test message from an external address #
After a change, you should test the reception practically.
Send a message to an existing mailbox in the domain from an independent external address.
In the case of externally hosted email, the message should arrive at the external mail provider. In the case of locally hosted email, it should arrive in the corresponding CURIAWEB mailbox.
8. Also test shipping #
Then test the opposite direction.
Send a message from the mailbox in question to an independent external email address and check whether it arrives there.
A complete test therefore includes both:
- external → your domain
- your domain → external
This makes it much easier to assess whether the email configuration is working in principle.
Why does email work externally, but not from my own website? #
A particularly typical routing problem occurs when external senders can reach a domain without any issues, but messages from a website on the same hosting do not arrive at the external mailbox.
For example:
www.deine-domain.ch
at CURIAWEB, while:
info@deine-domain.ch
is operated via an external mail service.
Now, does a contact form on the website send a message to info@deine-domain.ch, the local server must know that this mailbox is not local.
If the domain is incorrectly treated as a local mail destination, a delivery issue can arise precisely here.
Practical Tip: If normal external email traffic works, but messages from a website hosted on the same server to your own domain are missing, email routing is one of the settings you should check.
Why do external senders still work? #
External mail servers rely on the publicly accessible DNS and MX information of the domain for delivery.
A web server that is simultaneously configured as a mail server, on the other hand, must additionally decide whether a domain known to it should be handled locally or externally.
Therefore, correct MX records and an incorrect local routing setting can exist at the same time.
This explains why an issue may occur only with messages originating directly from the same hosting environment.
Local mailbox despite remote mail exchanger? #
If you Remote Mail Exchanger you use, you should not assume that a local mailbox with the same name that may still exist in cPanel is still the desired destination for normal emails of this domain.
If the domain has been switched to an external mail service, old local mailboxes should therefore not be considered as proof that emails must continue to arrive there.
Before a migration, you should back up existing email data and clearly define the planned mail flow.
Local Mail Exchanger despite external MX records #
This combination can be problematic.
Publicly visible MX records may direct external senders to the external mail provider, while the CURIAWEB server itself continues to treat the domain as a local destination.
This can result in a different delivery path than expected, particularly for locally generated messages.
If the email services are operated completely externally, not only the MX records but also the local routing configuration should match the external operation.
Remote Mail Exchanger despite local mailboxes #
The reverse misconfiguration can also cause problems.
If the email accounts are actually hosted on CURIAWEB, but the server treats the domain as an external mail destination, the routing configuration does not match the intended setup.
Therefore, always check first, where the real mailboxes are operated, before you select Local or Remote.
Email routing after changing email providers #
When you move your emails from CURIAWEB to an external provider or vice versa, routing is part of the migration planning.
When switching to an external mail provider, its DNS specifications typically need to be implemented and the local routing configured accordingly.
When returning to local email hosting, the corresponding settings must once again match the new target environment.
Attention: Do not hastily delete existing mailboxes during a mail migration. First, ensure that required messages have been backed up or transferred and that the new mail flow is working.
DNS changes may take some time #
If MX records were changed at the same time, it can happen that various DNS resolvers temporarily still use cached older values.
This depends, among other things, on the TTL of the DNS records in question and the resolvers involved.
Immediately after a DNS change, different delivery routes may therefore be observed temporarily.
Changing the local cPanel routing and globally updating cached DNS information are two different processes.
Email routing does not fix incorrect SPF, DKIM, or DMARC settings #
Email routing determines whether a domain is handled locally or externally. It does not replace the remaining configuration for email authentication and deliverability.
For example, if messages are classified as spam by the recipient or rejected due to authentication issues, email deliverability should also be investigated.
We show how to check the corresponding information in cPanel under Check email deliverability in cPanel.
Email routing doesn't fix a full mailbox either #
If messages cannot be accepted because the destination mailbox is full, changing from local to remote or vice versa is not a solution.
Routing should only be changed if the current setting actually does not match the location of the mail servers.
Investigate delivery error tracking #
If the routing setting looks correct, but emails are still not being delivered as expected, you should investigate the actual delivery path.
cPanel provides the function for this Track delivery Ready.
There, information on email processing can help determine whether a message was delivered, forwarded, or processed with an error.
We explain the exact procedure under Track email delivery in cPanel.
Typical errors in email routing #
A common mistake is assuming that external MX records automatically make every local mail server setting obsolete.
Equally problematic is, Remote Mail Exchanger to select, just because a single email is forwarded. Normal email forwarding does not mean that the entire domain is hosted externally.
Also Backup Mail Exchanger should not be used as a supposedly safe middle ground.
What is always decisive is the actual architecture: Where are the mailboxes located and which mail server should be responsible for the domain?
Basic rule: Locally hosted mailboxes require local mail handling. Fully externally hosted mailboxes require a corresponding external mail route. DNS, MX records, and local routing must match.
Summary #
The Email routing can you find in your CURIAWEB cPanel under Email -> Email Routing.
If the email accounts for a domain are hosted directly via your CURIAWEB hosting, the server must treat the domain accordingly as a local mail destination. If the mailboxes are operated entirely by an external mail provider, the routing configuration must match the external mail operation.
Local Mail Exchanger and Remote Mail Exchanger should therefore not be chosen based on intuition. First, check where the actual mailboxes are located.
Please also note that cPanel email routing is not the same as the MX configuration in DNS. When using externally hosted email, both levels must work together correctly.
After making a change, test receiving and sending with an independent external email address. If problems persist, then investigate the actual message path using cPanel Track Delivery.
