Microsoft 365 and Google Workspace Catch-Alls: Why They're So Hard to Verify

Short answer: Microsoft 365 and Google Workspace both accept incoming mail at a shared front-door gateway and make delivery decisions afterwards. When a tenant or domain is configured to accept unknown recipients, every address at that domain is accepted the same way — and ordinary email verification, which depends entirely on a server refusing addresses it does not recognise, has nothing left to work with. That is why your verifier returns "accept-all" on so many business domains and gives you nothing else.

Business email has consolidated heavily onto these two platforms, so in practice most of your catch-all problem is a Microsoft or Google problem. Here is what is actually happening, at a public level, and what to do about it.

Why these two platforms dominate the problem

Twenty years ago, verifying a business address meant talking to that company's own mail server, individually configured by that company's own administrator. Behaviour varied enormously, and that variation was itself informative.

Today the picture is very different. The overwhelming majority of business domains resolve to one of two hosted platforms. That consolidation has two consequences for verification:

Behaviour is uniform. Millions of domains now respond in almost exactly the same way, because they are running the same platform with the same defaults.

Defaults propagate at enormous scale. When a platform's recommended configuration is to accept unknown recipients, that recommendation is not adopted by a few hundred administrators — it is adopted across a large fraction of the business internet at once.

So catch-all is not a scattering of unusual domains any more. It is a structural property of how modern business email is hosted.

What a front-door gateway changes

Both platforms put a filtering and routing layer in front of the actual mailboxes. Incoming mail arrives at that layer, is accepted, and is then evaluated — filtered for spam and malware, checked against organisational rules, and routed to its destination.

This design is sensible. It centralises security, lets the platform absorb attack traffic before it reaches tenant infrastructure, and gives administrators one place to set policy.

It also means acceptance happens before the final answer about the recipient exists. When the tenant is configured to accept unknown recipients, the practical consequence for anyone checking from outside is stark:

• A real, actively used mailbox is accepted.
• A mailbox that was closed three years ago is accepted.
• A string that was never an address at all is accepted.

Identical responses, three completely different realities. No amount of care in performing an ordinary check will separate them, because the information genuinely is not in the response.

Why administrators configure it this way

It is worth being clear that this is not sloppiness. Common reasons, all defensible:

• Anti-enumeration. A server that rejects unknown recipients is a free directory service for attackers: guess names until one is accepted and you have a verified staff list to phish. Accepting everything removes that. Many security teams mandate it.
• Continuity after staff changes. Mail to a departed employee keeps arriving somewhere useful rather than bouncing at a customer.
• Typo tolerance. Misspelled enquiries still reach the business.
• Migration safety. During a mail migration, accepting everything avoids rejecting legitimate mail while records are in flux.
• Alias sprawl. Organisations that generate many short-lived addresses find accept-all simpler to run than a constantly-updated recipient list.

For a security-conscious organisation, accept-all is often the *recommended* posture. This is why catch-all prevalence is rising rather than falling, and why treating it as a temporary annoyance is a mistake.

A catch-all Microsoft 365 or Google Workspace domain is usually a signal of a well-run organisation with a real IT function. Those are frequently the exact accounts a B2B team most wants to reach — which is what makes the unresolved bucket so expensive.

What ordinary verification returns, and why

Faced with these domains, a standard verifier can accurately determine:

• the address is well-formed
• the domain exists and publishes mail servers
• the domain is hosted on a known platform
• the domain accepts every recipient offered to it

And then it stops, because the mailbox-level question has no answer available through those means. The output is "catch-all", "accept-all", "risky" or "unknown". As covered in our breakdown of verification statuses, that is the honest answer for a tool working with those signals — it is simply not a useful one.

Which leaves you with a segment of contacts at exactly the organisations you care most about, and no way to decide what to do with them.

How VeriMailX resolves them

VeriMailX resolves catch-all and accept-all addresses on both Microsoft 365 and Google Workspace to a definitive valid or invalid verdict. Self-hosted mail is covered too.

What you can rely on:

• A verdict on the mailbox, not a description of the domain's behaviour.
• No email is sent to the recipient. Nothing lands in their inbox, and the mailbox owner is not notified that a check occurred.
• Live resolution against the mailbox's current state at the moment of the check, rather than a cached opinion about the domain.
• Both platforms covered. The two platforms are not identical, and that difference is part of why ordinary verification struggles on them.
• Proprietary multi-signal resolution. The method is ours and we do not publish it. What we publish is the outcome and the standard we hold it to.

Our accuracy discipline

We do not claim 100% accuracy on any address, including these. Some cases are genuinely ambiguous, and in those cases we return risky rather than manufacturing an invalid to look decisive.

That is deliberate. A false "invalid" on a real person is the costliest error a verifier can make — you suppress a live prospect or an existing customer and never discover it, because suppression is silent. A "risky" verdict is something you can route to a human, hold back, or revisit. We would rather hand you an honest unknown than a confident mistake.

What this means for your list

Three practical implications.

Your catch-all segment skews toward your best accounts. Larger, better-administered, more security-conscious organisations are more likely to run accept-all. If your policy is "delete anything risky", you are systematically deleting your most valuable prospects.

Domain-level rules are not enough. "Exclude all catch-all domains" removes a large slice of the addressable market. "Include all catch-all domains" is the reputation risk covered in Are Catch-All Emails Safe to Send?. Only a mailbox-level verdict gives you a rule worth writing.

Re-verification matters more here, not less. These platforms accept mail for departed staff indefinitely, so a contact who left the company in 2024 looks exactly like one who started last week. Nothing in the ordinary signals will ever tell you otherwise.

Where to start

Pick a contact at a Microsoft 365 or Google Workspace domain that your current tool has been calling "accept-all" or "risky", and run it through the free email checker. Single checks require no signup.

If it resolves, so will the rest of that segment. Background on the underlying behaviour is in What Is a Catch-All (Accept-All) Email Address?, the practical workflow is in How to Verify Catch-All Emails, and pricing starts with free credits on signup.