Introduction

A Google Workspace alias that stops receiving mail after a migration is usually not a full mailbox outage. The primary mailbox may still work, users may still be able to sign in, and outbound mail may still send normally. What usually breaks is the alias layer itself: the alias was not recreated on the destination account, a conflicting object now owns the address, mail routing still points part of the flow at the old system, or the migration changed how the alias is supposed to deliver. Treat this as a recipient mapping and routing problem first, not a generic Gmail failure.

Symptoms

  • Mail sent to the primary Google Workspace address arrives, but mail sent to the alias does not
  • Internal users and external senders see different behavior for the same alias
  • The alias worked before migration and failed immediately afterward
  • Messages to the alias bounce, disappear, or land in the wrong mailbox
  • The affected address exists in admin records, but delivery still does not reach the intended user
  • Only one alias is failing while the main domain appears healthy

Common Causes

  • The alias was not recreated on the correct Google Workspace user after migration
  • The address is now attached to a different object such as a group, contact, or old recipient record
  • Mail routing still sends part of the domain’s traffic to the old server or old gateway
  • The alias belongs to a secondary domain or domain alias that was not migrated completely
  • Directory synchronization or recipient provisioning has not fully applied yet
  • Delivery to the alias is working, but forwarding, filters, or group settings changed the final destination

Step-by-Step Fix

  1. Confirm the primary mailbox for the affected user is receiving mail normally, because if the main mailbox is also failing, the problem is bigger than the alias and you need to troubleshoot general mail delivery first.
  2. Verify the exact alias address and the exact recipient it should belong to in the Google Admin console, because migrations often recreate the user but miss one or more alternate addresses or attach them to the wrong account.
  3. Check whether the failing address is truly a user alias and not a Google Group address, delegated mailbox, or forwarding-only address, because those objects behave differently and can look identical to end users after a migration.
  4. Search for conflicting objects that may now own the same address, such as groups, contacts, archived users, or suspended accounts, because Google Workspace can only deliver one way when duplicate or overlapping recipient objects exist.
  5. Test delivery from both an internal sender and an external sender and compare the outcome, because different behavior usually points to a routing or coexistence problem rather than a broken alias record alone.
  6. Review post-migration mail routing for the affected domain, including any split delivery, dual delivery, relay gateway, or old mail security service still in the path, because alias mail can continue following legacy routing even after the mailbox itself has moved successfully.
  7. Verify the alias domain and any secondary domains were fully migrated and are active in Google Workspace, because aliases tied to an unmapped or partially configured domain can appear to exist in admin records while still failing real delivery.
  8. Check filters, forwarding, and group membership on the destination mailbox if messages appear to vanish instead of bouncing, because the alias may already be receiving mail and then moving or redirecting it somewhere unexpected after delivery.
  9. Document the alias owner, test results from internal and external senders, any bounce text, routing settings, and conflicting objects if the problem survives a clean recheck, because that evidence lets Google Workspace support or the migration vendor isolate whether the failure is in recipient mapping or mail routing.