Verifying Google Workspace addresses

• An administrator can set a catch-all address for the domain. Where that is on, every local part returns 250 and mailbox-level verification stops being possible.
• With no catch-all configured the behavior matches consumer Gmail: 550-5.1.1 for addresses that do not resolve to a user or alias.
• Aliases and group addresses accept mail and look identical to a personal mailbox at the protocol level. A 250 for sales@ tells you a route exists, not that a person reads it.
• The same cloud-IP blocking applies, and it applies harder to business domains because Workspace admins can add stricter connection rules on top of Google's defaults.

• Workspace domains inherit Gmail's bulk sender rules once the receiving side counts as Gmail, so authentication requirements apply to business recipients too.
• A group address like team@ can have twenty members. One message becomes twenty deliveries and any of them can complain.
• Departed employees are the usual cause of a Workspace bounce. Companies often keep the account for weeks, forward it, then delete it, so the same address can move from valid to invalid without warning.

Say your prospect list holds 23 people at a 40-person design agency, all on the agency's own domain. The MX record points at Google. We check the real addresses and one made-up local part, something like zq7f3k1x, and every one of them comes back 250. All 23 rows get the catch-all label, because the server just told us it would have said yes to anything.

Here's the part people miss. On a true Google catch-all, sending won't settle the question either. Mail for an address that matches nobody gets delivered to whichever mailbox the admin picked, so you see no bounce at all. Your email tool reports 23 deliveries, and some of them landed in an office manager's overflow folder. Replies and clicks are the only evidence that a named person exists there.

Run dig MX on the company domain. Older setups list five hosts, aspmx.l.google.com and four alternates. Domains set up since 2023 often show a single record, smtp.google.com, which is Google's current recommendation. Either one means Google receives the mail.

It doesn't mean Google is the first thing your message meets. If the MX names a filtering service instead, that service answers the probe and Google sits behind it where you can't see. A Google MX also says nothing about who is on the other end. User mailboxes, aliases and catch-all routes all look the same from outside, which is why we report the platform and the result of the random-address test and stop there. Ask any vendor who shows you a valid verdict on a Workspace domain whether they ran that test first, and what they do when it comes back 250.