Alias bounces sort into a few specific causes, all diagnosable, most coming down to the alias not actually being where you think it is or the domain not being ready for it:

The propagation delay, most common and most benign: alias changes in Workspace take time to propagate, up to 24 hours though usually less and mail sent immediately after adding an alias bounces until propagation completes. If the alias is minutes old, the fix is waiting, retrying delivery after the propagation window before troubleshooting anything real.

The domain readiness, the frequent real cause: an alias on a domain or subdomain not properly added and verified in Workspace, or whose MX records do not point at Google, has nowhere to land. Aliases on your primary verified domain work, aliases on a secondary domain need that domain added as a domain alias or secondary domain in the admin console with its MX records pointing at Google, the step that is skipped when someone adds user@newdomain expecting it to just work.

The conflict, occasionally: the alias address already exists elsewhere, as another user's alias, a group or a former user and the collision causes the bounce. The admin console flags conflicts when you try to add a conflicting alias, but aliases added by different admins or via directory sync can collide in ways worth checking, searching the address across users and groups.

The diagnosis path: read the actual bounce message, whose wording distinguishes these, address not found pointing at propagation or domain readiness, while a policy rejection points elsewhere. Then confirm the alias shows on the user in the admin console, confirm the domain is verified with Google MX records if the alias is on a secondary domain and check for conflicts. The bounce message plus these three checks isolates nearly every alias failure, with propagation delay being the answer often enough to try waiting first.