GSuite...while migrating to 365, how to deactivate a primary domain, yet still keep a login....

[YeOldeStonecat]

I know how to do this with 365, but it doesn't appear to work with Google even though it looks like it should.

I have a client with 2x domains under his Google account. I migrated the first company already, and I need to delete those mailboxes. As I'm pretty sure that any external people on Google who email them...will have the email land in their Google mailboxes...instead of making it to 365. Because...Google still thinks its mail servers own the domain. That's how most other mail servers work anyways...I'm guessing Googles does. (instead of checking public MX records).

Anyways, the head honcho there has domainA. Which is the one I need to delete, and he is the superadmin of the site.
I created my own account, superadmin, under domain B...which I'll migrate next week.

My question is, can I just delete the domain from the Google tenant? With 365, all users would revert back to @initialdomain.onmicrosoft.com.
I see Google has a test domain, @initialdomain.test-google-a.com but it doesn't appear you can log in using that...or even create an account using that test domain.

I don't want to delete domainA..and have all the user mailboxes who use that for primary get whacked...yet.

 

[Sky-Knight]

If you change the DNS Google should follow that, if it doesn't work contact Google Support, they'll fix it.

Cloud systems aren't mail servers... they don't act like that anymore. DNS is king, that's why when DNS breaks very bad things happen. Everything in both GSuite and M365 lives and dies on DNS just as potently as Active Directory does. It's how the entire cluster knows what to do with anything.

Anyway, there is propagation delay, so keep your migration software syncing for a couple days after the cutover.

 

[YeOldeStonecat]

Cutover was last Sat morning...so...5x days later...I'm still hitting the "migrate" button at BitTitan....just to get those delta sweeps of the old mailboxes to get stragglers.

Suppose I could verify by using my gmail account to send an email to an ex staffer in the old system..change their mailbox password and log in and see....or if I get an NDR because 365 said "no such mailbox here!'

 

[Sky-Knight]

I've only done a handful of these, but they've always followed the DNS. If it's been 5 days, I have to assume the TTL on the DNS records have long since expired.

If mail is still going to the wrong place then you need to open a ticket with Google so they fix their mess. Failing that, the next least destructive thing I can think to do is rename all the mailboxes to different addresses so stuff starts bouncing. Those bounce messages for Google specifically tell the back end to "try again" as it were.

But you could also look at the delivery headers for the mails landing in the boxes and ensure the source is what you think it is. It's entirely possible it's not just Google stuff still using out of data data. You never really can get rid of all of that... you just have to accept that some mail systems suck.

But again NDRs bouncing back in the cloud age cause resets of impacted stuff. So a rename can help.

 

[YeOldeStonecat]

Several days pre migration I always dial down TTL of MX to 15 minutes..so yeah it's well past that!