Case Study: Migrating Email from Shared Hosting to Google Workspace

The Reputation You Don’t Own

A flooring company’s outbound email started bouncing because a neighbor on their shared hosting IP had poisoned the well. This is how we fixed it.

The job came in with a description that sounded almost routine: a regional flooring retailer’s email was bouncing more often than it delivered, and the owner wanted it fixed. The symptom was clear and the diagnosis, when I ran it, was clearer still: it pointed to a fix that no amount of filter tuning or mailbox repair was ever going to deliver because as it turned out, their shared hosting IP was on the Spamhaus blocklist.

It wasn’t because of anything they’d done and there wasn’t any compromised account on their domain was blasting spam. Somebody else on the same shared hosting IP had earned that listing on their behalf. And as long as the client’s mail was leaving through that IP, every message they sent was a dice roll.

This is the story of how we got them off of it.

Part One: The Symptom and the Ceiling

The client was a family-run flooring company with a handful of employees, website storefront, a customer-communications platform, and an industry-specific ERP that sent quotes and purchase orders on their behalf. Their email was hosted on a popular shared cPanel provider, users connected with Outlook Classic on their desktops and for years it had worked. But in the weeks before they reached out, it had started not working — intermittently at first, and then often enough to be a problem they couldn’t ignore.

The owner described it the way non-technical people describe email problems: bills were getting “lost,” a customer said they never received a quote, replies were vanishing into the ether. When I ran the initial checks, the picture came together quickly. The shared outbound IP their provider used for SMTP — one IP, serving dozens or hundreds of tenants — was listed on Spamhaus. Once that happens, major receivers start treating everything from that address with suspicion, and small mistakes you’ve never made start costing you delivery.

The ceiling here was structural. On shared hosting, you don’t get to pick your outbound IP, you don’t get to police who else is using it, and you don’t get to rehabilitate it. You either wait and hope a neighbor cleans up their act, or you leave. There was nothing to tune, nothing to patch, nothing to un-check in a settings panel. The only real fix was to move their email somewhere they weren’t sharing a reputation with strangers.

Google Workspace was the target the client chose. This was a good choice because Google’s outbound infrastructure is ruthlessly maintained; nobody on Gmail’s sending pools is on Spamhaus, and the platform’s DKIM and SPF story is turnkey. The business case wrote itself: pay a modest monthly subscription, stop worrying about the IP, and get out from under a problem they had no tools to solve on their own.

I proposed the move, we agreed on scope, and I started mapping the ground.

Part Two: Mapping the Ground

On paper this was a five-user migration. In practice, the first thing I learned is that nothing about the client’s infrastructure was where the paperwork said it would be.

The provider’s control panel showed the domain sitting inside their DNS manager, with records visible and an “Advanced DNS” editor waiting to be used. That made it look like DNS was being served from the hosting account. It wasn’t. A single dig ezdomain.com NS +short query returned nameservers belonging to the domain registrar — a separate company entirely. The hosting provider’s DNS panel was cosmetic: a mirror of what they thought the records should be, with no authority to enforce it. All real DNS changes had to happen at the registrar, which the owner hadn’t logged into in years and couldn’t immediately find credentials for.

This is a surprisingly common trap. When a small business signs up for shared hosting, the registration and the hosting often get bundled in the first year and then drift apart as renewals land on different invoices. Years later, nobody remembers who’s authoritative for what, and the evidence in front of them — the records visible in the hosting dashboard — reinforces a wrong assumption. I’ve seen more than one migration fail the first time because someone confidently updated DNS in the wrong place and then wondered why nothing had changed.

The website was its own separate story. Three sites lived on the shared hosting account, but the public DNS A records pointed at Amazon Web Services addresses, suggesting a reverse proxy or caching layer somewhere between visitors and the origin. None of that touched email, but it was a useful reminder that the infrastructure I was inheriting had been assembled by several people over several years, and that my mental model of it wasn’t going to be accurate until I verified it myself.

There was also a small detour around the Workspace signup itself. At one point the owner mentioned he’d hit an error saying the domain was already associated with another Workspace account. By the time I was ready to log in and start building out the tenant, there was a working Workspace account for the domain available to use. I didn’t dig into its history — whether it was something he’d started and resolved himself, or something that had been sitting there from a much earlier point wasn’t going to change what I needed to do next. We used it, verified domain ownership cleanly, and moved on.

Part Three: The Account Archaeology

The next discovery was the mailbox inventory itself. The original scope called for five users but the cPanel mailbox list showed eighteen.

Some of them were obvious former employees, their mailboxes marked “restricted” (the provider’s term for “over quota and blocked from receiving new mail”), carrying hundreds of megabytes of history each. Others were forwarders that turned out, on closer inspection, to be something more. Two in particular deserved their own investigation before I spent any more of the client’s money on licenses.

The first, which I’ll call crew@, was a small mailbox used to log into an iPad on the sales floor and to power a customer-communications platform. The natural assumption was that this could become a Google Group with forwarding, saving a license. But the customer platform used OAuth to connect to a real Gmail or Outlook account, not a forwarding address, and a group has no credentials to authenticate with. If the platform needed to log in, the mailbox needed to be a real user. After confirming that was how the integration worked, the question answered itself: licensed user.

The second was stranger. The mailbox matched the domain’s bare @ address (essentially contact@ for the company) and its job, it turned out, was to serve as the outbound sender for the flooring ERP. When a salesperson generated a quote or a purchase order from the ERP, the ERP sent it via SMTP using that mailbox as its identity. I initially thought this address could stay as a group, with the ERP’s mail routed through Google’s organization-level SMTP relay. Then I opened a screenshot the owner forwarded from his ERP vendor’s support team. The ticket explicitly requested a Gmail account with two-step verification enabled and an app password generated. App passwords are a per-user credential; groups can’t have them. The ERP’s integration wasn’t flexible enough to use the relay path. If we wanted the ERP to keep working the way it always had, the bare-domain address also had to become a licensed user…with 2FA enabled, an app password generated, and a real mailbox where customers and vendors could reply.

A handful of other smaller accounts (a forward to an outside collaborator, an alias used as a 2FA recovery address on the owner’s own account, a catch-all that nobody could remember creating) got sorted into their appropriate homes: real groups where groups made sense, aliases where aliases made sense, labels inside the owner’s mailbox where historical mail needed to be preserved but a live destination wasn’t required anymore.

Part Four: Building the New House Without Breaking the Old One

With the inventory settled, I started building out the new Workspace tenant in parallel with the still-live old email system. The entire goal of this phase was to have everything ready to activate at the moment of cutover — no half-states, no gaps in authentication, nothing the old system relied on that wasn’t already waiting for it on the new one.

Users got created, and then groups got created with carefully-tuned posting and viewing permissions: external senders allowed, member-only visibility, owner and manager roles assigned to the right humans. The owner’s display name got cleaned up from the company name back to his actual name, and aliases were attached where they belonged.

The most delicate part of the pre-cutover work was authentication. The client’s existing DMARC record was already set to p=reject, the strictest possible policy, with aggregate reports being sent to a generic address at the registrar that nobody had ever monitored. That p=reject was a problem waiting to happen. If I swapped the MX records to Google before Google’s DKIM was publishing and SPF was updated, every message sent through Google would fail authentication and get rejected outright. No soft failures, no quarantine folder, just bounces.

The cleanest way to avoid that gap is to pre-publish Google’s DKIM key before cutover. DKIM in Google Workspace is inert until mail actually starts flowing through Google’s servers; the public key can sit in DNS for weeks without signing anything, because there’s nothing to sign yet. I generated the 2048-bit key in Admin Console, published the TXT record at the registrar under Google’s custom selector, and watched it propagate. Then I waited for Admin Console to flip from “not authenticating” to “authenticating email with DKIM.” At that point, the new signing infrastructure was armed and loaded; it just wasn’t being asked to do anything yet.

I drafted the post-cutover SPF and DMARC records and staged them in a document, ready to paste. The new SPF would authorize Google’s sending infrastructure and drop the old shared-hosting IP. The new DMARC would keep the p=reject policy because with DKIM already publishing and SPF flipping simultaneously, there would be no authentication gap to protect, and I redirected the aggregate reports to my own mailbox to analyze later.

Part Five: The Long March of IMAP Migration

The other thing you want done before cutover is as much historical mail migration as you can get. Seven years of email across five mailboxes is twenty-something gigabytes of data, and no matter how fast your tools are, Google’s will not let you move it fast. Google’s built-in IMAP migration service is free, reliable, but aggressively throttled and unfortunately the throttling is non-negotiable, invisible, and applies to mailboxes of every size.

I kicked off the first batch by selecting all five users at once and pointing the tool at the shared hosting IMAP server, with an arbitrary start date deep in the last century to make sure nothing got excluded. The tool ran. It discovered tens of thousands of messages across the five mailboxes and chewed through most of them at a respectable pace, with a handful of failures along the way (a fraction of a percent…normal, typically corrupted headers or messages over size limits). Then, somewhere in the middle of the 12-gigabyte mailbox, progress essentially stopped…not crashed, not failed, just throttled to a degree that made progress invisible from one hour to the next. Whether the throttling was specific to that mailbox or whether the job as a whole had simply hit a ceiling and the last big mailbox was where I happened to notice it, I can’t say for certain, but the effect was the same: the small mailboxes finished, the big one crawled.

This is a known trade-off with Google’s built-in tool: it’s free and correct, but the ingest rate is set somewhere Google doesn’t tell you. On small mailboxes it’s fine, on large ones, you expect to get throttled. And critically — this is what makes the trade-off workable — the tool connects to the IMAP source directly, by hostname, not via MX records. That means the migration can keep running after cutover, because changing MX records only affects new incoming mail; the tool is still happily pulling old mail from the provider’s mailbox server by its actual address.

For the service-account mailboxes that were becoming groups or labels rather than 1:1 user destinations, I used a different approach. Google’s IMAP tool can’t target a group, so I pointed each of those mailboxes at the owner’s account with a destination label — bills-archive, erp-archive, and so on. The historical mail would live inside his inbox, visually organized by label, searchable, and out of the way. New inbound mail to those addresses would go to the live groups. It’s an ugly seam if you stare at it, but for small businesses where “I need to find an invoice from two years ago” is the actual use case, it works.

The first batch ran for days in the background while I continued with the rest of the setup. Meanwhile, the delta migration (the catch-up job to grab anything that arrived during the cutover window) would also have to run after the MX flip. I knew going in that the delta was going to be throttled just as hard; Google doesn’t care how small the job is.

Part Six: The Cutover

We picked an evening, confirmed the owner was available, and walked through the sequence.

Cutover Timeline

01

Platform Ready

Activate Gmail in the Admin Console.
02

DNS Access

Log into the registrar.
03

Mail Routing

Delete the old MX record, then paste in Google's five MX records in order of priority.
04

Authentication

Replace the old SPF with the new one. Replace the old DMARC with the new one, keeping the same p=reject policy but redirecting aggregate reports.
05

Verification

Save. Run dig from my terminal. Wait for propagation.
06

Live Test

Send a test message from my own domain to the owner's new Gmail and watch it arrive. Send a test back and watch it arrive.

It took about twenty minutes from deletion to confirmed delivery; no bounces, silent losses, or missing authentication. The DKIM key we made earlier was now the signing key for everything leaving the company, and because I’d pre-published it, Google’s first outgoing message already authenticated cleanly against it. The old shared hosting IP — and its Spamhaus listing — were no longer part of the client’s outbound story.

The IMAP migration continued running in the background. The owner got his first new email in Gmail within a minute of the cutover completing. The team, which had been warned about the transition earlier in the day, was going to wake up to Gmail in the morning.

Part Seven: The Long Tail

A migration like this is never really “done” at the moment of cutover. The MX flip is the most dramatic moment, but the work that follows it is what determines whether the client actually stays happy.

The ERP’s reconfiguration was the next morning’s task. I created the dedicated licensed user for the bare-domain address, enabled two-step verification, navigated past the surprisingly obscure app-password interface (which isn’t reachable from the normal account settings and has to be accessed directly), and generated a credential for the ERP’s vendor to install on their end. They scheduled the change, tested it, and the ERP started sending quotes and purchase orders from the new mailbox within the day.

The delta migration crawled through the cutover-window messages on Google’s schedule, not mine — a few dozen items over the better part of an hour, exactly as throttled as I’d warned, but it eventually finished.

And then the real verification: DMARC reports. Five days after cutover, I pulled the aggregate reports that were now landing in the owner’s actual mailbox instead of the registrar’s black hole. Eighty-six messages evaluated across five reports. 98.8% of messages passing both DKIM and SPF. Zero rejections, zero quarantines, the only authentication anomaly was a single softfail from a message that had been forwarded through a third-party mail server — a well-understood artifact of how forwarding interacts with SPF, saved by DKIM, completely harmless. The domain was authenticated, the policy was enforced, and nothing was being spoofed.

I closed the contract.

Lessons for Business Owners

On shared hosting, you don’t own your email reputation — you rent it from strangers. Every small business that sends important mail from a shared hosting IP is one bad neighbor away from the problem this client had. If email matters to your operation (quotes, invoices, customer replies, order confirmations) the money you save on bundled hosting email is not money you actually saved. inasmuch as it’s a bill you pay later in lost messages and bounced quotes.

Authentication is not optional anymore, and it’s not “set and forget.” This client had SPF, DKIM, and DMARC records from years ago, including an aggressive p=reject policy. None of them had been touched since they were set up. The DMARC aggregate reports were being sent to an address nobody had ever read. That’s functionally the same as not having DMARC at all, because the whole point of the aggregate report is to tell you what’s happening to your domain’s mail. If you can’t name the inbox your DMARC reports go to, you have more of a checkbox thsan you a legitimate DMARC monitoring setup.

Check where your DNS actually lives. Hosting control panels routinely display DNS records they have no authority over. The only way to know who’s actually answering for your domain is to ask the root directly with a tool like dig or an online DNS lookup. Before any migration, figure out where the authoritative nameservers are pointed, and make sure you have working credentials for that system, not just for the place you think manages DNS.

Cutover without a gap is possible, but it has to be designed. The reason this migration didn’t produce a single bounce is that DKIM was published and active before any mail was routed through the new platform, SPF and MX were updated simultaneously, and DMARC was never loosened during the transition. The alternative — temporarily softening p=reject to p=none during the cutover window — is perfectly legitimate, and many migrations use it. But with preparation, you can keep the policy strict the whole way through.

Conclusion

What started as “our email is bouncing” became an investigation into shared infrastructure, misrouted DNS, service accounts that nobody had documented, and an ERP integration that quietly demanded its own licensed user. None of these surprises were catastrophic, and none of them derailed the project. They were the normal texture of doing migration work on real, lived-in infrastructure, the kind where nothing has been audited in years because everything mostly worked.

The client got off the blocklist not by asking to be removed (which often just means participating in a game of musical chairs), but by leaving the neighborhood entirely. Their outbound reputation is now Google’s, which is about as clean a piece of infrastructure as the modern internet offers. Their authentication is tight, their DMARC reports actually go to a human, and their ERP is sending quotes and purchase orders from a real mailbox that can receive replies. he owner mentioned afterward that the migration had “forced us all to clean things up”…one of the quietly underrated benefits of a project like this. A migration is one of the few moments when a team has no choice but to look at every account, every filter, every forwarding rule, every setting that nobody’s touched in years. The kind of housekeeping that everyone agrees should happen but never quite makes it onto anyone’s calendar gets done, because the alternative is carrying the mess into the new system.

If you’re a small business owner reading this and wondering whether your own email setup has any of these quiet problems, the fastest check is the one I ran in the first five minutes: look up your outbound sending IP, run it through Spamhaus, and see what comes back. If the answer is “nothing,” you have time to plan. If the answer is anything else, you’ve just found out what your next project is.

Client details have been anonymized. Technical findings, infrastructure decisions, and timelines are drawn from the actual engagement.