How Microsoft 365 answers a verification check
Exchange Online publishes one MX per tenant, under mail.protection.outlook.com. When the domain is authoritative and Directory Based Edge Blocking is on, which is the default, Exchange Online checks each recipient against the directory at RCPT TO and refuses unknown ones with 550 5.4.1 Recipient address rejected: Access denied.
The words "access denied" make that reply look like a policy block, and generic checkers treat it as one. Domains set to internal relay, hybrid setups and tenants behind a third-party gateway behave differently: they accept every recipient and sort it out later, which makes them catch-all at the SMTP level.
Microsoft 365 replies and what RocketVerifier returns
Each SMTP reply maps to one status and sub-status. Replies about the probing server are never counted against the address.
| Reply | Result | What it means |
|---|---|---|
| 250 2.1.5 Recipient OK | deliverable none | The recipient exists in the directory. |
| 550 5.4.1 Recipient address rejected: Access denied | undeliverable mailbox_not_found | Directory Based Edge Blocking: the user does not exist. |
| 550 5.1.10 RESOLVER.ADR.RecipientNotFound | undeliverable mailbox_not_found | Recipient not found by SMTP address lookup. |
| 250 for random addresses too | risky catch_all | Internal relay or a gateway accepts everything. Scored 0 to 100. |
| 550 5.7.606 Access denied, banned sending IP | unknown blocked | About the probing IP. Not charged. |
What RocketVerifier does differently for Microsoft 365
-
5.4.1 read as a missing user
On Microsoft hosts, 5.4.1 with "recipient address rejected" is a real not-found. Banned-IP and blocklist wording is still always a block, so the rule never misfires.
-
Business and consumer kept apart
Microsoft 365 tenants and Outlook.com are separate receiver classes with separate session profiles and rate budgets, because they behave differently.
-
Internal relay tenants caught
Tenants that accept every address are detected with a live catch-all test, and each address is scored send_safe, send_with_caution or avoid.
-
Gateways read in their own dialect
Many tenants sit behind Proofpoint, Mimecast or Barracuda. Each gateway has its own reply rules in the engine.
-
A block is never a bad address
Replies about the probing IP, rate or policy are returned as unknown with the blocked sub-status and never charged. Only an explicit mailbox answer becomes deliverable or undeliverable.
-
No email is ever sent
The SMTP conversation stops at RCPT TO, before DATA. Your recipients never see a probe.
Sending to Microsoft 365: what to get right
- B2B lists are full of Microsoft 365 domains. Verify before every outbound campaign, because people leave companies and their mailboxes are removed.
- Score catch-all tenants instead of dropping them. Many valuable accounts sit behind internal relay or a gateway.
- Microsoft 365 recipients apply their own tenant filtering, so authenticate your domain with SPF, DKIM and DMARC before you send.
Keep reading
Sources
- Microsoft Learn: Use Directory Based Edge Blocking to reject messages sent to invalid recipients
- Microsoft Learn: Manage accepted domains in Exchange Online
- Microsoft Learn: Email non-delivery reports in Exchange Online
Last reviewed