Set up Google Workspace for a domain hosted on cPanel

You can keep the website at Hostsuar and handle email with Google Workspace. The change affects the email records and cPanel's routing, not the records that serve the website.

Before you change the MX records

1. Create in Google Workspace every user, alias and group that needs to receive email. Once the MX records change, messages will stop arriving in the cPanel mailboxes.
2. Keep a copy of the messages you need and plan their migration if there is email stored with the previous provider.
3. Find out where the authoritative DNS zone is managed. If the domain uses our DNS servers, you can edit it from Zone Editor in cPanel; if it uses Cloudflare or another provider, the change is made there.

Verify the domain with Google

Go to the Google Workspace Admin console, add the domain and copy the verification record the wizard shows you. It will usually be a TXT record with a unique value like google-site-verification=....

Create it in the DNS zone without changing its value and go back to the Google console to complete the verification. This record proves you control the domain, but it does not yet change where email is received.

Set up the current MX record

Delete the previous provider's MX records and create the MX record Google currently gives for new Workspace sign-ups:

Use the zone's default TTL. cPanel accepts the name and destination with the trailing dot; other providers may add it automatically.

Older organisations may keep the five destinations ASPMX.L.GOOGLE.COM and ALT*.ASPMX.L.GOOGLE.COM: Google still supports them. For a new setup always use the value shown in the Admin console, as that is the source for that organisation.

Do not keep Google's MX records and the previous provider's at the same time as a supposed fallback. Priority does not create a copy: secondary servers are only used when the preferred ones do not respond, and they can deliver messages to the wrong system.

Change email routing in cPanel

If the domain is still added to the hosting, open Email Routing in cPanel, select it and choose Remote Mail Exchanger. That way websites and applications on the server itself will look up Google instead of trying to deliver locally to a cPanel mailbox.

This step does not replace the public MX record: both must point to the same destination.

Authenticate outgoing email

Also set up the records that authenticate outgoing email:

• SPF: authorise Google with include:_spf.google.com. There must be a single SPF record; if the website or other providers also send email, combine all the authorisations in the same TXT record following the SPF guide.
• DKIM: generate the key from the Google console and publish the TXT record with the exact selector and value it gives you. Then turn on DKIM authentication in the Google console; publishing the key does not, on its own, start signing messages.
• DMARC: publish it after checking SPF and DKIM, starting with a monitoring policy if you do not yet know every legitimate sender.

Activate and check

Go back to Google Workspace and click Activate Gmail. Propagation can be gradual; during that time some senders may still look up the old MX records.

Finally, test sending in both directions, including aliases and groups, and check in the headers of an outgoing message that SPF, DKIM and DMARC pass for the domain. Moving historical messages is a separate task from changing the MX records.

If it does not work after the change

Check receiving and sending separately. If external messages arrive but a form on the hosting cannot write to your domain, review the remote routing and the SMTP server the application uses. If you receive but your sending fails, look at Google's rejection and authentication before changing the MX records again.

Do not replace an old five-MX setup that works just to use the new format. Follow Google's current MX guidance and the values in your console. To prepare other records, use the DNS assistant.