[REQUEST] Edit: Forwarding email to new Google Workspace accounts before re-pointing MX records.

[Blue House Computer Help]

I'm in the process of moving a customer from an IMAP web host to Google mail workspace. Their workspace email accounts (e.g. sales@customername.co.uk) have been created on Google workspace but I haven't changed the MX records over yet.

I'm sure I read somewhere that there was a way to send test e-mail to these new accounts using something like sales@customername.co.uk.googletest.com or something, before we switch over.


Can anyone point me in the right direction?

 

[Sky-Knight]

You're wasting time, Google isn't going to FUBAR your mail unless you FUBAR your DNS.

 

[Blue House Computer Help]

Reading back, I see I wrote that post a little bit hastily and didn't fully explain.

The company I'm working with is a small 10 employee business that has been using aliases to personal Gmail accounts instead of proper mailboxes. I thought I could turn this into an opportunity to do a "soft migration" by re-pointing their aliases to Google one at a time as I run them through the set up. But to do that, I need a wee to point the aliases at the Google mail boxes before the MX record change.

Any other ideas how I might go about this? And any cautionary tales about what you have seen go wrong when changing MX records?

 

[YeOldeStonecat]

And any cautionary tales about what you have seen go wrong when changing MX records?

Many different methods of moving "old mail from old mailbox" to "new mailbox".

Basically just choose a method you're good with. Those of us that do a lot of these usually get familiar with a migration tool, such as BitTitan, SkyKick, etc. Migration tools basically work along the lines of a split pane window. On the left half...is your "old source server"...where you define its settings and have each mailbox with credentials. And on the right side...the new destination server...settings, mailboxes/creds.

What's nice about migration tools is....you can "pre-seed" the new server by doing some pre migration uploads. Typically it'll be some setting you can vary...say, "all email older than the past 30 days...move it". You do this a week ahead of time. What that allows you to do, is greatly shorten the time of completely moving the mailboxes at the time of cutover...since..the "full migration" now only has to grab the past ~30 days worth of email and move it. Migration tools also usually allow you to do "post cutover delta passes"....meaning, say you cut over on Friday at dinnertime...chances are some "straggler emails" still landed in the old servers mailboxes Friday evening, possibly even Sat morning. Since...not all email servers are proper and tidy keeping up with their DNS records..they may not know about the "new server" for a while after you flip the MX records.

Another thing I like to do a week (or at LEAST a few days) before cutover date....I log into the client domains CPanel...DNS management...and I go to the mail related DNS records (MX, autodiscover, SPF, etc)...and I lower the TTL. At least get it down to 1 hour...if not as little as 15 minutes if possible. This makes things happen quicker for the cutover time.

 

[John Kennedy]

I don't think he's asking about migrating data so much as asking about doing testing prior to the cutover. Unfortunately, I have not seen a special/hidden domain for Google Workspaces before where you could do as you are asking Blue House. However, I would trust that as long as you set up the MX record properly during the transition, email will flow properly with defaults on Google Workspaces.

There also is NO WAY to migrate one mailbox at a time as you are hoping. The MX record repoints where all email for the domain is delivered, so without some temporary domain on the Google Workspaces accounts that has proper MX records for itself, there's no way to test those mailboxes for mail flow.

If you're really worried, I'd suggest exactly that. Buy a different domain for super cheap, add it to Google Workspaces with all the defaults and the MX records, then test whatever you want to test about mail flow with the temporary domain.

As for the actual MX record change, I've done this loads of times and generally it just works properly if you do the following:

1) change all the existing MX records to a really short TTL ahead of time: 30 minutes or less if you can, shortest available if you can't get that quick
2) copy/paste what Google or whatever service you're using gives you rather than typing it in yourself
3) check to see if the DNS service uses any funky notation (some servers make you put the . at the end of records for instance) ahead of time

Google and Microsoft do an excellent job of giving you all the right info for DNS moves for their services. I wouldn't sweat it too much. As long as you make sure your clients understand there will be down time and you do it when that can be acceptable (even if there isn't actually any down time because you've rigged it that way or something), then failing back in the case of catastrophic failure isn't a problem either.

 

[Blue House Computer Help]

So, it turns out you can send e-mail to Google workspace accounts before the MX records are migrated.

I knew I head read it somewhere: https://support.google.com/a/answer/56835

In summary, all you have to do is send email for user@customername.com to user@customername.com.test-Google-a.com and it works. However, it doesn't work for calendar invites etc... and only with the primary domain.

But, it didn't turn out to be what I needed to simplify things anyway. (What? Me? Overthink?). I'm just going the hopefully more straight forward route of logging everybody into their Google workspace accounts ahead of time, with "pre-seeding" via POP e-mail access to their previous @gmail.com account. Had to enable two step authentication on the old account so Google would allow me to create app specific password for the POP account settings. Funnily enough, I couldn't find a way to get the Google workspace account to check mail on another Gmail account using Google’s own OAUTH, but there you go.

@John Kennedy Thanks so much for the encouragement and the mini-checklist.