Split delivery: combine Hostsuar and Google Workspace mailboxes

Split delivery lets you work together, under a single domain, with email accounts on two different services: Google Workspace and our cPanel hosting.

This guide describes one specific design: Hostsuar receives first and distributes by recipient. Google also documents other split-delivery designs; do not mix their routes or MX records with this one without adapting the whole setup. It is not duplicate delivery of every message to two mailboxes.

Critical points before you start

Delicate setup: a mistake in the process can cause lost email or delivery loops. Following each step correctly is essential.

Server dependency: once set up, your cPanel hosting acts as the central distribution point.

Google internal route required: the cPanel steps are not enough for two-way split delivery. Google Workspace needs a rule that sends recipients on the domain who do not exist in Google to the Hostsuar gateway. The rule must apply only to internal outbound messages, not to inbound messages, because those already come from cPanel and sending them back would create a loop. Without that route, a Google user may get an error when writing to an account that exists only in cPanel. Ask support for the hostname with a valid certificate and the gateway details before you continue; do not use an IP address or a hostname you have guessed.

How it works and technical requirements

How email flows

In this design, external email addressed to the public MX records is delivered first to your hosting. From there, our server automatically decides: if the account exists in cPanel, it is delivered locally; if there is no applicable local destination and you have created the domain forwarder, it is forwarded to Google Workspace.

For outgoing email, cPanel sends to the recipient as usual. From Google Workspace, external recipients are sent directly from Google. Recipients on the same domain who do not exist in Google will only reach cPanel if you set up the internal route described in the previous section.

DNS setup for this design

MX records: the design uses only Hostsuar's MX records, with the values provided for your service. Prepare and test the routes before the switch; do not remove MX records that are handling email during the preparation.

Correct setup (Hostsuar only):

example.com MX 0 HOST_MX_FACILITADO_POR_HOSTSUAR

Incorrect setup (Google + Hostsuar at the same time):

example.com MX 1 smtp.google.com
example.com MX 0 HOST_MX_FACILITADO_POR_HOSTSUAR

or with Google's legacy records:

example.com MX 1 ASPMX.L.GOOGLE.COM
example.com MX 5 ALT1.ASPMX.L.GOOGLE.COM
example.com MX 0 HOST_MX_FACILITADO_POR_HOSTSUAR

HOST_MX_FACILITADO_POR_HOSTSUAR stands for the MX host Hostsuar gives you.

SPF record: there must be a single SPF record that authorises both services. If there are no other sending sources, you can use this value; if an SPF record already exists, add both mechanisms before the final all following the SPF record guide:

v=spf1 +a:spf.theservercluster.com include:_spf.google.com -all

Google Workspace: the domain must be verified and the service working, but without its MX records set up.

Step-by-step setup

Step 1: prepare Google Workspace

1. Verify domain ownership in the Google Admin console.
2. Do NOT set up the MX records when Google asks you to.
3. Note down the test domain linked to the primary Workspace domain (for example, yourdomain.com.test-google-a.com). Do not assume every secondary or alias domain has an equivalent one.
4. In Google Admin, set up the route for inactive and unknown accounts to the Hostsuar gateway provided by support. Enable the rule only for Internal - Sending, leave Inbound unticked and require a TLS connection. If it also applies to inbound messages that cPanel forwards to Google, the two services will bounce the email back and forth and create a loop.
5. Also set up Google's inbound gateway with the exact public IP addresses support gives you and turn on detection of the original external IP. Before enabling it, confirm with support that the gateway checks DMARC and applies the sender's policy to external email: Gmail does not necessarily enforce that policy on messages received through an inbound gateway. Do not copy IP addresses from another server or client; a wrong list can change spam and authentication checks.

Step 2: set up the domain forwarder

Go to cPanel → Email → Forwarders and click Add Domain Forwarder. Select your domain as the source and enter the Google Workspace alias as the destination (yourdomain.com.test-google-a.com).

The domain forwarder applies when cPanel cannot deliver the message to an existing address or autoresponder. So a local account or autoresponder for the same recipient takes priority and prevents forwarding to Google.

Step 3: manage the accounts

For Google Workspace accounts: do not create the account in cPanel, so that the forwarder works automatically.

For hosting accounts: create the accounts in cPanel as usual without setting up any forwarder.

Common problems and solutions

Error "Too many Received headers - suspected mail loop"

Do not infer the cause just because there are MX records for both services. Open the Received headers of the bounce and check whether Google and cPanel are sending the same message back to each other through reciprocal routes. Fix the route that sends it back, check which MX records should be the only public ones in the design, and keep cPanel on Local only if its MX records are the ones that receive email first.

Internal email does not arrive

If there are problems between services, review the domain forwarder settings, check there are no duplicate accounts and confirm the Google Workspace alias works properly.

Deliverability problems

Check that the SPF record includes both services, set up DKIM for both services and make sure the MX records are only the hosting's.

Technical details of the forwarder

cPanel's domain forwarder is used for recipients the server cannot deliver to a local account or autoresponder. If user1@yourdomain.com exists in cPanel it is delivered locally; if user2@yourdomain.com has no local destination, the forwarder to Google Workspace applies.

Test each path before closing the change

Use your own test accounts and check, separately:

• An external sender to a local mailbox and to a Workspace one.
• A local mailbox to a Workspace one on the same domain.
• A Workspace mailbox to a local one on the same domain.
• External sending from both services.
• A non-existent recipient, which must end with the intended handling and not circulate between servers.

Review headers, authentication and logs at both ends. An external test reaching Gmail is not enough: the domain's internal email could still be failing.

Save the previous MX records and rules and agree how to go back to the previous state if the checks fail. An accidental duplicate of a user, an alias or an autoresponder can change which server receives. Keep an inventory of where each address lives and review both configurations when adding or removing users.