| Microsoft 365 | |
|---|---|
| Domains | Custom business domains hosted on Exchange Online |
| Mail routing | A tenant-specific hostname ending in mail.protection.outlook.com, usually built from the domain name with hyphens replacing dots. |
| How results come back | Many mailboxes; unanswered ones come back unknown, unbilled |
How Microsoft 365 answers a probe
What the server does when we open a connection and ask about one address.
- Per Microsoft's docs, a domain with all its mailboxes in Exchange Online has directory-based edge blocking on by default. Unknown recipients get 550 5.4.1 with Recipient address rejected: Access denied, which is a clean answer we can use.
- A domain set to Internal relay skips that check and returns 250 for any address. That's common during a migration or in a hybrid setup. From our side it's a catch-all domain, however tidy the directory is.
- Connection-level throttling applies on top of both, and Exchange Online Protection will refuse a connection entirely if our IP has not built a history with it.
- Some tenants sit behind a third-party gateway such as Proofpoint or Mimecast, which answers the probe instead of Microsoft and follows its own rules.
The part that catches people out
What we do about it
The mx column in the CSV export names the host that answered, so a Mimecast or Proofpoint gateway in front of the tenant shows up by name. A Mimecast answer is a Mimecast answer and not Microsoft's. Where the tenant accepts everything, the catch-all probe catches it and the row comes back catch_all, never a confident valid. A 550 5.4.1 from a fully hosted tenant comes back invalid with MAILBOX_NOT_FOUND. A 421 or a refused connection comes back unknown with TEMPORARY_FAILURE or SENDER_BLOCKED as the reason, and unknown results are never billed. The four-step check closes the connection before DATA, so the tenant never receives a message.
Sending to Microsoft 365 mailboxes
Verification is one step. These are the things that decide whether the message lands.
- Exchange Online Protection weighs the sending domain's authentication heavily, and a soft DMARC policy loses you the benefit of the doubt.
- Bulk mail to a 365 tenant often lands in the Other tab of Focused Inbox rather than the junk folder, which looks like delivery in your stats and like silence to the recipient.
- Tenants frequently keep a departed employee's mailbox as a shared mailbox. It accepts mail forever and nobody reads it.
A hybrid tenant that says yes at the door
Say you're checking 60 addresses at a regional hospital group. The MX ends in mail.protection.outlook.com, so it's Microsoft. Our random-address test comes back 250, and so does everything else. One likely reason is how the domain is registered inside Exchange Online. Microsoft's edge blocking only rejects unknown recipients on domains marked Authoritative. A company that keeps some mailboxes on its own Exchange servers usually sets the domain to Internal Relay. Then the edge accepts every recipient and lets the inside servers sort it out.
When you send to a bad address there, the rejection comes back later as a bounce message, commonly 550 5.1.10 RESOLVER.ADR.RecipientNotFound. We never see that at the probe stage, because we close the connection before DATA and no message is ever sent. So the verdict you get from us on that domain is catch-all, and the 5.1.10 bounces only show up in your own sending logs after a real campaign goes out.
When a valid address still bounces your mail
Distribution lists and Microsoft 365 groups are real recipients, so a tenant with edge blocking turned on answers 250 for them. Many are locked to internal senders. Mail from outside then bounces with 550 5.7.133, sender not authenticated for group. The probe was right that the address exists. It couldn't know the list refuses strangers. Keep those rows out of your invalid pile and note them as closed to outside mail, which is a different fact about the record.
You can check the platform yourself with dig MX. A hostname like contoso-com.mail.protection.outlook.com is the classic pattern, and tenants that turned on DNSSEC for inbound mail may show a name under mx.microsoft instead. If you see pphosted.com or mimecast.com, a gateway is answering first, and its rules apply before Microsoft's do.
Questions people ask
Why do two Microsoft 365 domains behave differently?
Because recipient validation depends on how the tenant routes mail. One domain is fully hosted in Exchange Online and rejects unknown addresses at the edge. The next is set to Internal relay for a hybrid setup, or sits behind a gateway, and accepts everything. Same product, opposite results.
Does a security gateway change what you can verify?
Yes. When Proofpoint, Mimecast or Barracuda fronts a tenant, that appliance answers our probe and applies its own policy. Many of them accept all recipients by design, which turns the domain into a catch-all from our side.
Is Microsoft 365 a catch-all provider?
Not inherently. Some tenants end up that way through relay settings or a gateway. But a domain fully hosted in Exchange Online rejects addresses that don't exist. Once the connection is allowed, it's one of the easier business platforms to check.
Why did a Microsoft 365 address come back unknown?
Because Exchange Online Protection throttled or refused the connection instead of judging the address. ZapBounce returns that as unknown with the reason named, such as TEMPORARY_FAILURE or SENDER_BLOCKED, and refunds it. A re-check a few hours later often gets a clean answer.