Cold Email Bounces After a Prospect's Email Migration: Why Valid Leads Start Failing

When a prospect's company moves its email from one provider to another, some addresses that verified last month stop existing, even though the domain is unchanged. The new system only has the mailboxes and aliases the admin set up. Departed staff, old naming formats and shared inboxes that nobody recreated disappear on cutover day. During a staged move, the domain may also accept every address and pass unknown ones to the other system, which bounces them later. So when you see an MX change on a domain in your list, re-verify that domain's leads before you send, and again once the migration settles.

If you are already looking at a cluster of bounces from one company, start with most of your bounces came from one domain, which covers all five causes. This post is about migrations specifically, and how to catch them before they bounce.

What changes in a migration, and what doesn't

Stays the same	Can change
The domain (company.com)	The MX records and the server answering for the domain
Most current employees' main addresses	Aliases (j.smith@ pointing at john.smith@)
	Address format for new or re-created accounts (jsmith@ vs john.smith@)
	Accounts of people who had already left but were kept as mailboxes
	Shared inboxes and groups (sales@, team@) recreated as different types, or not at all
	How the domain answers verification checks

Microsoft's own Google Workspace migration guide says the process "requires that you provision all of your users who will be migrated as mail-enabled users outside of the migration process" (Perform a Google Workspace migration). In other words, the admin builds the user list on the new side. Anything not on it does not exist there. The same is true in the other direction.

Why a migrating domain can look catch-all

Many migrations run in stages: some users move first, the rest later. To keep mail flowing, admins route mail between the two systems. Google Workspace's split delivery is one way to do it. Google describes it as sending incoming mail to one of two systems based on the recipients, with the MX pointing to Google and the other system added as a route (Google, split delivery). A common setup sends any recipient Google does not recognise on to the old server. Microsoft's migration guide likewise has the admin create routing subdomains for each side (prerequisites).

The effect on a cold sender:

1. Your verifier, or your step 1, reaches the server named in the MX.
2. That server does not know the address, but accepts it and forwards it to the other system, because that is the rule for unknown recipients.
3. The other system does not have it either, and bounces it back, minutes or hours later.

From outside, the domain looks catch-all or the address looks accepted. The bounce comes after the send. This is one reason late bounces cluster at one company.

Spot migrations before you send

The clearest signal is a change in MX records since you last checked the lead.

1. Keep the provider with the lead. When you verify a list, record each domain's provider label (Google Workspace, Microsoft 365, gateway, other). The bulk email provider lookup gives you this for a whole list.
2. Before a campaign, look up the providers again. Run the same lookup on the domains you are about to send to.
3. Compare. Any domain whose provider changed is a migration, or a new gateway in front of the old provider.
4. Re-verify those domains' leads. Treat old results for them as expired, however recent.

What changed	Likely meaning	Action
Google Workspace to Microsoft 365, or the reverse	Provider migration	Re-verify all leads at the domain now and again in a few weeks
A gateway appeared (pphosted.com, mimecast.com)	New security gateway	Re-verify; expect more catch-all and unknown results. See verifying behind security gateways
MX disappeared	Domain no longer receives mail	Drop the domain; see check if a domain accepts email
MX points to a parking or hosting provider	Domain lapsed or parked	Drop the domain's leads; nobody there is reading mail

For one domain at a time, the MX lookup shows the current records.

Re-verify on two dates

A migration is a process, not a moment. Verify twice:

When	Why
Right before the next send	Catches addresses that are already gone
A few weeks after the MX change	The old system has usually been switched off, so forwarding rules stop masking dead addresses

On the second pass, expect some addresses that came back catch-all or valid during the migration to come back invalid. That is the forwarding rule disappearing, not the verifier changing its mind.

Adjust the campaign for migrating domains

• Send migrated domains in their own segment until the second verification. Their bounce rate is less predictable.
• Lower the per-company cap. If you were planning five contacts at that company, send to two first and wait for bounces. See how many people at one company to email.
• Leave a longer gap before follow-ups, so late bounces arrive before step 2.
• Suppress bounced addresses globally, not only in the campaign that sent them.

Migration or something else?

Pattern	More likely
Same domain, provider changed, scattered bounces across names	Provider migration
Bounces mention a new company or the old domain forwards to a new one	Rebrand or acquisition
Bounce text names policy, spam or the sender	A block, not a bad address. See Bounce Doctor
Every address at the domain rejected as unknown, including verified ones	The domain turned on directory-based blocking or stopped accepting mail

Where SimpleVerifier fits

SimpleVerifier checks each address against the mail server named in the domain's current MX records, and marks addresses it could not confirm as risky rather than valid. That includes catch-all answers during a migration. Label providers with the free bulk email provider lookup, then re-verify changed domains on the verify page. The first 100 checks are free with a Google sign-in. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.