It's quite entertaining to read - most of the article is pretty much elaborating a chain of bad decisions by the author which all lead to this now being a big problem. If he'd have written a similar dependency tree earlier and just thought about it for a few minutes that should've been avoidable.

> Update 1 - I know I can simply change the MX record to someone else but It has its own challenges.

I don't quite get that attitude. He's describing that he needs his business emails. Not just getting a mail server back online for that, even as interim solution, points to the opposite. In the time it takes for MX TTL to expire he could easily just throw up a postfix+dovecot on some VPS, with enough time to spare to add something like sogo if he feels fancy.

I was a bit worried when I saw the title of the article because I have one of these accounts but geez he made some bad choices. Deleting all phone numbers and the recovery and swapping to a new authentication method and then accessing from a different country??? No wonder it got flagged.

I probably wouldn't believe him either. Google should have an option to revert to the last trusted config after some verification method. Google support is bad, I'll give him that.

All this to avoid roaming charges? And then refusing to share a personal email in this scenario and missing meetings because of that.

I'd argue that changing the MX to fastmail or Microsoft would be much faster than a postfix+dovecot solution on a VPS but I think he's just refusing any solution based on his principals.

That's what I didn't get either. And you don't even need to configure a VPS, there's Fastmail, Protonmail, Zoho, Kolabnow, Purely mail, Migadu and so much more.

Why victim blame him for removing the phone number? He had a logical reason for doing so, and with Google supporting many forms of authentication it's perfectly reasonable to think that removing one wouldn't jeopardize the other methods.