Pointing your MX records at Microsoft 365 or Google Workspace

This guide shows you how to keep your website on Hostworld while moving email to Microsoft 365 or Google Workspace. You change only the MX records so new mail goes to your chosen provider, add their supporting DNS records for deliverability, then switch cPanel Email Routing to Remote so our server does not accept your mail locally. Do it in that order to avoid lost messages.

This picks up from a working website on Hostworld cPanel hosting and an admin account in Microsoft 365 or Google Workspace.

Before you start

What you will need

• Access to your domain’s DNS zone. If your DNS is hosted with Hostworld, you will edit it in cPanel. If your DNS is elsewhere, you will edit it at your registrar or DNS provider.
• Admin access in your chosen platform:
  • Microsoft 365: the Microsoft 365 admin center for domain verification, user creation and DNS values.
  • Google Workspace: the Admin console for domain verification, user creation and DNS values.

Know where your DNS lives

If your domain uses Hostworld DNS, your registrar’s nameservers will be set to our cluster: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk. You will edit DNS in cPanel. If your nameservers point anywhere else, your authoritative DNS is external and you must change records at that provider.

Provision users before you change MX

• Microsoft states to add users and set up mailboxes before updating MX. Google states to create accounts before changing MX. If you switch MX first, mail to unprovisioned addresses will bounce.
• Verify your domain in Microsoft 365 or Google Workspace before you touch MX.

Why Email Routing in cPanel matters

• In cPanel, Email Routing controls whether our server treats your domain as local mail. Remote Mail Exchanger tells the server not to accept mail for this domain and to route all mail to the lowest numbered MX.
• Auto-detect in cPanel Email Routing only inspects the local zone file. It does not query public DNS. If your authoritative DNS is elsewhere, set routing manually or the server may swallow mail as if the domain were local.

Risks and how to avoid them

• Do not set Email Routing to Remote too early. While MX still points at the Hostworld server, switching to Remote will make our server refuse mail that is still pointed at it.
• Do not leave Email Routing on Local after moving MX away. Our server will keep delivering locally for site generated messages, so they will not reach Microsoft or Google.
• Have exactly one SPF TXT record per name. If you add a second SPF TXT, SPF fails with a PermError. Merge includes into one SPF line.
• Remove or de‑prioritise old MX records at cutover. Leaving them can split delivery or keep mail flowing to the old host.
• Follow DNS formatting rules in your editor. Some UIs require a trailing dot on the target, or combine priority and target. Enter the value in the format your DNS host expects.
• Propagation is not instant. Google notes MX changes can take up to 72 hours to be seen everywhere. Microsoft’s guidance uses TTLs under 6 hours, commonly 3600 seconds, for new records.

Step 1: Confirm where to edit DNS

This step avoids changing DNS in the wrong place.

1. Check the domain’s nameservers at your registrar. If they are ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk, your DNS is on Hostworld. You will use cPanel’s Zone Editor and Email Routing.
2. If your nameservers point elsewhere, sign in to that DNS provider or registrar. You will add the same MX, SPF, DKIM and other records there. You will still set Email Routing in cPanel to Remote after MX cutover so our web server does not treat the domain as local.

Step 2: Prepare Microsoft 365 or Google Workspace

This ensures the new provider can accept your mail the moment MX changes.

Microsoft 365 preparation

• Verify your domain in the Microsoft 365 admin center.
• Create all user mailboxes and aliases. Match every active address you currently receive.
• Note the exact MX value for your tenant in the admin center. It has this form:

  <domainKey>.mail.protection.outlook.com
  Example: contoso-com.mail.protection.outlook.com

• Note the two DKIM CNAME targets shown in the admin center. You will publish both selectors before enabling DKIM.
• Plan to add the Autodiscover CNAME for Outlook profile auto configuration:

  autodiscover CNAME autodiscover.outlook.com

• Plan your SPF merge. Microsoft’s include is:

  include:spf.protection.outlook.com

Google Workspace preparation

• Verify your domain in the Admin console.
• Turn on Gmail for the domain if prompted.
• Create all user accounts and aliases. Match every active address you currently receive.
• Note the MX value Google documents:

  smtp.google.com

  Google states the legacy ASPMX and ALT records are still supported. Use the value your Admin console provides.
• Plan your SPF. Google’s include is:

  include:_spf.google.com

• Plan DKIM. After turning on Gmail, you create a TXT record at google._domainkey with the key shown in Admin console, then enable DKIM. Google notes you may need to wait 24 to 72 hours after enabling Gmail before you can generate the key.

Step 3: Publish supporting DNS records first

This prepares mail authentication and client discovery ahead of cutover. You can add these before changing MX.

If your DNS is on Hostworld

1. Sign in to cPanel for the domain and open Zone Editor.
2. Add or update the SPF TXT at the root name. There must be one SPF TXT only.
   • Microsoft only:

     v=spf1 include:spf.protection.outlook.com -all

   • Google only:

     v=spf1 include:_spf.google.com ~all

   • Sending from both Microsoft 365 and Google Workspace:

     v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

   Keep one record and merge includes. Do not create a second SPF TXT.
3. For Microsoft 365, add the Autodiscover CNAME:

   Name: autodiscover
   Type: CNAME
   Target: autodiscover.outlook.com

   Microsoft labels this optional but highly recommended because it helps Outlook configure accounts.
4. For Microsoft 365 DKIM, add the two CNAMEs that the admin center shows. Use the exact selector names and targets for your tenant. You will enable DKIM in Microsoft 365 after these resolve.
5. For Google Workspace DKIM, when the Admin console provides the key, add:

   Name: google._domainkey
   Type: TXT
   Value: <long DKIM key from Admin console>

   Then enable DKIM in the Admin console once DNS is live.
6. Optionally publish DMARC at _dmarc.yourdomain. Microsoft recommends using SPF, DKIM and DMARC together. Google advises enabling SPF and or DKIM before enforcing DMARC. Choose a policy appropriate to your mail streams.

If your DNS is external

• Add the same SPF, DKIM and Autodiscover records in your DNS host’s UI. Follow its formatting rules. Some systems require a trailing dot on targets or combine priority and target in one field.

Step 4: Change MX to your provider

MX tells the world where to deliver new mail for your domain. You will point it at Microsoft 365 or Google Workspace and remove or lower any old MX entries.

Microsoft 365 MX

1. Create or update the MX record so the highest priority points to your Microsoft 365 value:

   Name: @  (or your root)
   Type: MX
   Priority: 0  (lowest number is highest priority)
   Target: <domainKey>.mail.protection.outlook.com
   Example target: contoso-com.mail.protection.outlook.com

2. Remove any MX records for the previous provider, or set them to a lower priority than the Microsoft 365 record. Leaving old MX with higher priority will keep mail flowing to the old host.
3. Set a TTL that suits your change window. Microsoft’s guidance supports TTLs under 6 hours and commonly uses 3600 seconds for new records.

Google Workspace MX

1. Create or update the MX record so the highest priority points to Google:

   Name: @  (or your root)
   Type: MX
   Priority: 0  (or the lowest number your editor allows)
   Target: smtp.google.com

   If your Admin console shows the legacy ASPMX and ALT set, those are still supported. Use the value Google indicates for your domain.
2. Remove old or incorrect MX entries. Google explicitly advises removing them to avoid split delivery.
3. Observe any formatting requirements in your DNS UI. Some editors require the MX target to end with a trailing dot. Others combine priority and host in a single line. Follow your provider’s notes.

Verify what is live

• Microsoft: the domain setup wizard in the admin center will verify your MX after you add it.
• Google: use Admin Toolbox Dig to confirm your MX is visible on the public internet.
• Propagation time varies by caches and TTL. Google notes MX changes can take up to 72 hours to be seen globally.

Step 5: Switch cPanel Email Routing to Remote Mail Exchanger

This stops our server treating your domain as a local destination after MX moves off server. Do this after the MX change, or at the same time if you are updating both in one session.

1. In cPanel, open Email Routing for the domain.
2. Select Remote Mail Exchanger, then save. This makes our server route mail to the lowest numbered MX, rather than accepting it locally.
3. If your DNS is external, do not use Auto detect. It only inspects the local zone file. Set Remote explicitly.

Be careful with the timing. If you set Remote while your MX still points at the Hostworld server, our server will stop accepting mail destined for it. If you leave it on Local after MX moves away, messages generated on the website can be delivered to local mailboxes that you are no longer using.

Step 6: Enable DKIM and confirm authentication

SPF, DKIM and DMARC help your messages reach inboxes and protect your domain from spoofing.

• Microsoft 365:
  • After the two DKIM CNAMEs resolve, enable DKIM in the Microsoft 365 admin center. Microsoft requires both selectors. Microsoft updated DKIM record formats for new domains in 2025. Always copy the exact targets from your tenant.
  • Publish DMARC at _dmarc.yourdomain when SPF and DKIM are in place.
• Google Workspace:
  • After you add the TXT at google._domainkey and it resolves, enable DKIM in the Admin console. Google notes you may need to wait 24 to 72 hours after turning on Gmail before the key can be generated.
  • Publish DMARC at _dmarc.yourdomain. Ensure SPF and or DKIM is on before enforcing a policy.

Step 7: Clean up and test delivery

• Remove any remaining MX records for the previous provider, or ensure they are at a lower priority than your new MX. Keeping them active risks future split delivery.
• Review your SPF TXT. There must be one record only. If you used to include another provider and no longer send from it, remove that include. If you send from more than one provider, merge the includes in one line.
• Send test mail both ways:
  • From an external account to your domain. Confirm it lands in Microsoft 365 or Google Workspace.
  • From your domain to an external mailbox. Check the headers to confirm SPF and DKIM pass once enabled.
• If a test fails or you see unexpected delivery to old mailboxes, review Email Routing in cPanel and confirm it is set to Remote.

If you want us to check your zone and routing settings, open a support ticket. Include your domain and where your DNS is hosted.

Using Hostworld DNS in cPanel versus an external DNS host

Our method above focused on cPanel when your domain uses Hostworld DNS. If your DNS is not with us, apply the same records in your DNS provider’s editor, then set Email Routing to Remote in cPanel so our server does not treat the domain as local.

• cPanel Zone Editor lets you add MX, TXT and CNAME records when DNS is on Hostworld. If your host limits record types, you may need to manage DNS externally to publish everything required by Microsoft or Google.
• When managing DNS externally, remember cPanel’s Auto detect for Email Routing only inspects the local zone file. Set Remote manually so mail does not get swallowed by the web server.

What next

• Migrate historic mail and local PSTs to your new platform, then update user devices and mobile clients. If you need help assessing your current setup on our hosting, open a support ticket.
• If your website runs on a VPS and you plan further changes, see our VPS guides.
• Looking at server resources for growing sites or applications alongside your new mail platform, explore our Linux VPS options.