Skip to main content

WHM Transfer Tool breaks Google MX records after migration

Rafael

Hello,

I just ran into a really frustrating issue while using the WHM Transfer Tool. When moving accounts, it does copy the DNS zones over to the new server, but it doesn’t keep the custom MX records. For example, if a domain is using Google Workspace (G Suite), those MX entries get wiped and replaced with the default cPanel MX (mail.domain.com pointing to the local server).

This basically means that after every migration, email for domains using Google (or any external mail service) breaks until you manually fix the MX records and set the email routing back to Remote Mail Exchanger. Honestly, this is a big pain and something the Transfer Tool really should handle better.

Comments

2 comments

Date Votes
  • Rubfy

    You’re right—this can happen if the destination rebuilds the zone from its default template during transfer. Two quick ways to fix it and keep Google MX + Remote routing:

    A) Fastest UI fix (per domain)

    1. WHM » DNS Functions » Import DNS Zone

      • Export the zone from the source (or open /var/named/DOMAIN.db) and import it on the destination.

      • This restores the exact MX set (ASPMX / ALT*.google.com).

    2. Email Routing → set to Remote Mail Exchanger for that domain (in cPanel » Email Routing).

    3. Verify:

       
      dig +short MX example.com exim -bt user@example.com | egrep 'remote|routers'

    B) Re-sync just the DNS zone (multiple domains)

    If you still have the source online, you can re-run a transfer of only DNS zones (no home dirs/databases), or use WHM » DNS Functions » Restore/Import DNS Zone in bulk. This overwrites the newly created zone with the source’s zone that already contains Google MX.

    CLI (optional, one domain example)

     
    # Set routing to Remote uapi --user=CPUSER Email set_email_routing domain=example.com mxcheck=remote # Add a Google MX if needed (repeat with priorities 1,5,10,20,50) whmapi1 addzonerecord domain=example.com name='example.com.' type=MX ttl=14400 priority=1 exchange='ASPMX.L.GOOGLE.COM.'

    Preventable next time

    • Before migrating, confirm the source zone has the correct Google MX and that Email Routing is Remote.

    • After migration, always do a quick post-check on MX + routing (the two commands above) before switching nameservers or going live.

    This approach avoids mail falling back to local delivery and has been reliable for us in many transfers.

    0
  • cPRex Jurassic Moderator

    Hey there!  I wasn't able to immediately reproduce this on my end, so I would likely need more specific details on how I can recreate this issue before I can make a case with our developers.

    On the Source server I created domain.com and adjusted the MX record to use mail.randomdomain.com.  I then performed the migration and confirmed the custom MX record was in place on the destination machine.  This was without using Live Transfer.

    If you can get me more specifics on how I can replicate this issue I'd be happy to do some more testing for you!

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post