Verifying Microsoft 365 addresses

• A domain whose mailboxes all live in Exchange Online has directory-based edge blocking in effect without anyone switching it on, per Microsoft's documentation. 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, which is common during a migration or in a hybrid setup with on-premises Exchange, skips that check and returns 250 for any local part. 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.

• 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.

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 still keeps some mailboxes on its own Exchange servers usually marks the domain Internal Relay, and 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.

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.