Verifying Google Workspace and Microsoft 365 email addresses: what the servers tell you

You can verify most Microsoft 365 and Google Workspace addresses without sending an email, because both platforms usually reject unknown recipients during the SMTP conversation. Gmail answers a nonexistent mailbox with 550 5.1.1, and Exchange Online's Directory-Based Edge Blocking answers with 550 5.4.1. The exceptions are configuration choices on the customer's side, such as catch-all routing or relay setups that accept every address, and those come back risky or unknown rather than valid.

That matters for B2B lists because a large share of business domains run on one of these two platforms. Knowing how each one answers explains most of the results you see.

How Gmail and Google Workspace answer a mailbox check

Google publishes its SMTP error codes. The ones that matter for verification:

The 5.x.x codes are permanent failures in the enhanced status code scheme of RFC 3463; 4.x.x codes are transient and may succeed later. That split is why a 550 5.1.1 can be trusted as "this mailbox doesn't exist" and a 450 can't be trusted as anything.

Workspace domains use the same mail servers, so the default behaviour is the same. The exception is a domain whose admin has set up catch-all routing for unrecognized addresses. With that rule on, mail to any local part at the domain is accepted and rerouted to a shared mailbox. A verifier that probes a random address first sees it accepted and reports the domain as catch-all. In pingutil that's risky with reason accept_all.

How Microsoft 365 answers, and why some tenants accept everything

Microsoft documents Directory-Based Edge Blocking (DBEB): if the recipient doesn't exist, the service rejects it at the network perimeter with 550 5.4.1 Recipient address rejected: Access denied. According to the same page, DBEB is already in effect when all of a domain's recipients are in Exchange Online.

Two configurations change that:

• Internal relay domains. During migrations, or in hybrid setups where some mailboxes still live on-premises, the accepted domain is often set to "Internal relay" instead of "Authoritative". Microsoft's instructions for enabling DBEB involve switching the domain to Authoritative, which means a relay domain doesn't reject unknown recipients at the edge. To a verifier, it looks like accept-all.
• A gateway in front. If the domain's MX points at a third-party security gateway rather than Microsoft, you're talking to the gateway. Some gateways check recipients, some accept and decide later.

Microsoft's doc also notes that even with DBEB, there can be "infrequent instances" where nonexistent addresses are allowed through. So a 250 from a Microsoft 365 tenant means "accepted for now", which is all a 250 ever means.

Why you still see unknown on big providers

Large providers protect themselves against address harvesting. A verifier's IP that opens many sessions and never sends mail can be slowed down, deferred or blocked. When that happens the honest answer is unknown, with a reason:

• greylisted: a temporary deferral that a real sender would retry.
• rate_limited: the server is limiting how fast it answers.
• blocked: the rejection was aimed at the checking server (its IP or sender address), not at the mailbox.
• timeout or connection_failed: no usable answer at all.

pingutil caches greylisted, blocked and rate_limited for one hour, then tries again. It doesn't cache timeouts, so the next request retries immediately. The full mapping is in email verification statuses explained, and the general limits of SMTP probing are covered in why SMTP verification is unreliable.

What to do with each result on a B2B list

For a list heavy on Workspace and Microsoft 365 domains:

1. invalid with mailbox_not_found or mailbox_disabled: remove from sequences. The provider said no in a permanent code.
2. valid: send, but still watch real bounces. A tenant can change its config.
3. risky / accept_all: keep, but don't count these as verified. Send to them in smaller volumes, or only when the contact came from a source you trust. Our catch-all domains guide goes through the options.
4. unknown: re-check later rather than deleting. If it's still unknown, treat it like accept_all.

You can see which mail platform a domain uses from the mx_host field in each pingutil result (for example, a Google or Outlook MX hostname), which helps when you're explaining a batch of accept_all results to a sales team.

curl -X POST https://pingutil.com/v1/verify \
  -H "Authorization: Bearer pk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "email": "jane@northwind-example.com" }'

Check a few of your own colleagues' addresses in the live verification demo to see what your own tenant returns, then read the field reference at /api#verify.