A Google Workspace catch-all email routes all incoming messages sent to non-existent email addresses at your domain to a specified mailbox. It acts as a safety net for typos, missing aliases, or forgotten addresses.
Catch-all forwarding is enabled at the domain level in Google Workspace Admin Console. When activated, any email sent to [email protected]-even if no user or alias exists-gets delivered to a designated inbox. This includes messages sent to [email protected] if no such account exists.
For example, if someone sends an email to [email protected] but no user or alias exists under that name, and catch-all is set to [email protected], the message arrives in the info inbox. This behavior applies globally across all subdomains unless explicitly restricted.
When an email is sent to an address not mapped to a user or alias in your Google Workspace account, the system checks for a catch-all setting. If one exists, the message is routed to the configured mailbox. The original sender receives no bounce notification unless the domain's MX records are misconfigured.
Messages forwarded via catch-all are treated as regular inbound emails. They appear in the recipient's inbox, show up in search, and are subject to spam filters. However, they do not trigger delivery notifications or read receipts.
There are two primary configurations for catch-all email in Google Workspace:
| Setting | Description | Use Case |
|---|---|---|
| Global catch-all | Applies to all unassigned addresses across the domain. | Small teams with limited email aliases. |
| Subdomain-specific catch-all | Can be set separately for subdomains like [email protected]. |
Larger organizations managing multiple business units. |
Each domain can have only one active catch-all rule. You cannot set multiple destinations. If you change the target mailbox, all prior catch-all traffic reroutes to the new address.
Google does not allow catch-all rules based on patterns (e.g., "forward all emails to [email protected] if the local part starts with 'test'"). Rules are binary: either on or off, with a single destination.
Many organizations assume catch-all prevents lost messages. In reality, it increases exposure to spam and phishing. According to Google's security documentation, catch-all settings can make domains more attractive targets because attackers test common addresses like [email protected] or [email protected] knowing they'll deliver somewhere.
Catch-all does not prevent mail delivery failures. If an email is sent to [email protected] and the domain has no MX record, the sending server may still reject the message. Catch-all only applies when the domain resolves correctly but the address doesn't exist in the user list.
Instead of relying on catch-all, create explicit aliases for known roles. For example, define [email protected], [email protected], and [email protected] as aliases tied to specific users or groups. This ensures accountability and reduces noise.
Use Gmail's "Auto-responders" and "Vacation responders" for temporary handling of missed emails. These tools can send automated replies stating "This address is inactive. Please contact [email protected]."
For advanced routing, use Google Workspace's SMTP and API-based rules. A small SaaS company I helped configure uses a script that checks incoming emails against a database of valid addresses. If no match, it logs the attempt and sends a bounce with a custom message. This reduced spam volume by 89% compared to their previous catch-all setup.
As a rule of thumb: never enable catch-all unless you're certain you need it. Google's own guidelines state that "catch-all features increase the risk of abuse and should be avoided unless absolutely necessary."
When catch-all is required-for example, during migration or for legacy systems-limit the duration. Set a calendar reminder to disable it within 30 days. Monitor logs via Google Workspace Audit Logs to track catch-all activity.
A Google Workspace catch-all email forwards all messages sent to undefined addresses at your domain to a single inbox. While useful for catching typos or testing, it introduces security risks and operational overhead. Best practice is to use targeted aliases and automated routing instead. If you must use catch-all, monitor usage closely and disable it after the need ends.