products
Catch-All Migration Gone Wrong: The 24-Hour Overlap Fix
A catch-all migration between domains looks like a two-step job: create the new rule, delete the old one. That sequence is exactly how one team lost a full day of unknown-address mail. The old catch-all rule was removed while the new domain was still verifying, and every message to a misspelled or retired address bounced with a hard 550. Here is the checklist that would have prevented it, and the 24-hour overlap fix that ended the outage.
The migration plan that skipped a step
The team ran a small sales operation on a legacy domain and had just moved the brand to a new one. Their catch-all setup was simple. A routing rule in the Google Workspace Admin console caught anything addressed to a name that did not exist and forwarded it to a shared inbox the sales reps monitored. That inbox had been quietly collecting misaddressed email for years: leads who typed the wrong first name, customers replying to an old signature, invoices sent to billing@ when the real alias was accounts@.
The migration plan read like a checklist from a blog post. Add the new domain, verify it, create the matching catch-all rule, then remove the old one. The administrator had Gmail Settings administrator privilege, so nothing blocked the work. The mistake was timing. Domain verification in Google Workspace is not instant, and the team treated “rule created” as “rule live.” They deleted the legacy rule the same afternoon, before the new domain had finished propagating.
What followed was a 20-hour window where mail to non-existent addresses on the old domain had no destination. Google Workspace lacks a dedicated catch-all switch, so there was no fallback setting quietly holding the line. The routing rule had been the only safety net, and it was gone while its replacement was still half-built.
Why the gap existed at all
A catch-all in Google Workspace is not a checkbox. You build it as a routing configuration in the Admin console, usually with a rule that matches messages addressed to non-existent recipients and then uses the Change envelope recipient action to redirect them. The catch-all mailbox receives mail for non-existent addresses only because that rule rewrites the envelope, not the visible To line. If the rule is absent, the message bounces at the SMTP layer and nothing downstream ever sees it.
The rule applies to inactive and unrecognized accounts, which is the whole point, but it can only do that inside a verified domain. Until the new domain finished verifying, the new rule existed on paper and did nothing. The old rule was already deleted. That is the entire failure mode, and it is boring in the way that most expensive outages are boring.
Verification is not the same as propagation
Domain verification confirms ownership. It does not guarantee that mail flow, MX records, and routing changes are all resolving the way you expect at that moment. Google notes that changes can take up to 24 hours to apply, and that window is precisely where this migration broke. The team confirmed the new rule in the Admin console, saw a green status, and assumed delivery was live. A single test message to a fake address on the new domain would have exposed the truth in under a minute.
There is a second trap here for anyone who has been running catch-all for years. Old rules often point at a destination that no longer makes sense after a rebrand. The new rule needs a real destination, and Google allows a user account or Google Group as destination. A Google Group address is usually the better choice for a shared catch-all because it survives staff turnover and lets you add reviewers without touching the routing rule. If the migration also changes the destination, you now have two variables moving at once, which is exactly when people delete the old rule too early.
The 24-hour overlap fix, step by step
The recovery was not clever. It was disciplined. The team rebuilt the old rule first, restoring mail flow to the legacy inbox within the hour, then ran the migration again with both rules active at the same time. Google Workspace catch-all email has more details on this topic. That overlap is the fix, and it should be the default for every catch-all migration, not a rescue tactic.
Build the new rule on the verified new domain and point it at the new catch-all destination. Leave the legacy rule running untouched. Send test messages to invented addresses on both domains, one per domain, and confirm each lands where you expect. Then wait. Keep both rules live for a full 24 hours and check delivery on the new domain at the start and end of that window. Only after the new domain has caught every test message for a full day do you remove the old rule. The overlap costs you nothing except a day of patience and a slightly messier Admin console.
One detail worth building into the checklist: label the test messages distinctly. Send from an external account, use addresses like catchall-test-1@yourdomain.com that you know do not exist, and check the catch-all mailbox for the rewritten envelope. If the message arrives but the original recipient address is missing from the headers, your rule may be replacing the recipient in a way that loses context. The Change envelope recipient action is the right tool, but it is worth confirming what the delivered message actually looks like before you trust it with real traffic.
The table below compares the migration approaches the team considered, including the one they should have used from the start.
| Approach | Downtime risk | Effort | Best for |
|---|---|---|---|
| Delete old rule, create new rule same day | High: gaps until the new domain resolves | Lowest | Nobody, and this is the mistake from the case study |
| Create new rule, keep old rule live 24 hours | Low: both domains catch mail throughout | Low, one extra day of waiting | Almost every catch-all migration |
| Pause catch-all entirely during migration | High: unknown-address mail bounces on both domains | Low | Only if you accept losing misaddressed email |
| Keep both rules permanently on both domains | None on paper, but duplicate destinations and confusion | Ongoing maintenance | Rare, usually a sign the migration was never finished |
| Use a Google Group as the destination for both rules | Low, and the group survives the cutover | Moderate setup | Teams with shared inboxes and staff turnover |
Confirming delivery before you pull the plug
Delivery confirmation is the step everyone skips because the Admin console looks reassuring. Do not trust the console alone. Send a fresh test message to a non-existent address on the new domain at hour 1, hour 12, and hour 24 of the overlap. Confirm each one arrives in the catch-all mailbox with the envelope rewritten correctly. If any test fails, the old rule stays. That is the whole rule: no confirmed delivery, no removal.
Watch the legacy inbox during the overlap too. If mail for the old domain starts arriving on the new domain before you expected it, that is fine, but it tells you the cutover is further along than the console suggests. If the opposite happens and the legacy inbox goes quiet while the new one stays empty, stop and investigate. A silent catch-all is usually a broken rule, not a quiet day.
Keep a written record of the exact rule names, destinations, and timestamps for both domains. If something bounces after the overlap ends, that record is what lets you rebuild the old rule in minutes instead of guessing at its settings. The team in this story lost a day of inbound lead mail precisely because nobody had written down what the legacy rule contained.
Making the overlap a standing habit
The lesson generalizes beyond one migration. Any time a catch-all moves between domains, destinations, or admin accounts, run the two rules in parallel for 24 hours and verify delivery on the new side before touching the old. Treat the Admin console status as a hint, not proof. Treat a single successful test as a data point, not a guarantee.
If you are documenting the process for your team, AllMail publishes a Google Workspace catch-all guide that walks through the routing rule, the Change envelope recipient action, and the verification steps in order. Use it as a checklist, then add the 24-hour overlap as your own house rule. The migration that failed here was not a hard problem. It was a sequencing problem, and sequencing is free to fix before you start.
