Does email verification work on Microsoft 365 addresses? On most tenants, yes, and the reason is in Microsoft's own documentation. When every mailbox for a domain lives in Exchange Online, a feature called Directory-Based Edge Blocking is already in effect. Mail to an address that doesn't exist is refused at the edge with 550 5.4.1 Recipient address rejected: Access denied.
That refusal is exactly the signal a verifier reads. The SMTP check sends RCPT TO for the address, gets the 550 5.4.1, and closes the connection before DATA. A real mailbox gets a 250 instead, and nothing is delivered either way.
The catch is the speed limit. Microsoft's support pages describe error 451 4.7.500-699 (ASxxx) as IP throttling: when a connecting IP sends far more than its usual pattern, Microsoft treats it like a new sender on probation, a technique the same page calls graylisting. Probe a few thousand Microsoft-hosted addresses from one IP and you'll meet it.
Under throttling, one address can return a clean 550 at 10:00 and a 451 at 10:20. Neither reply is wrong. The second one just isn't an answer about the mailbox.
What changes the answer on a Microsoft 365 domain
Hybrid and migrating tenants. Microsoft's setup steps have admins keep a domain on Internal relay until every mailbox has moved, and edge blocking applies once the domain is switched to Authoritative. A domain on Internal relay passes unknown recipients along instead of refusing them, so it can look like a catch-all.
Rare gaps on Authoritative domains. Microsoft's own note says there might be infrequent cases where addresses that don't exist are allowed through the service.
Security gateways. When a company puts a filtering gateway in front of Microsoft 365, the MX record points at the gateway, and the gateway answers the probe. That reply describes the appliance, not the mailbox behind it.
Probe traffic from cloud IPs. Gmail and Microsoft 365 both block SMTP probes from cloud addresses, which is why a Microsoft-heavy list tends to return more unknown results than a list of small self-hosted domains.
Why a second pass works on Microsoft
The short version
- Treat a 550 5.4.1 or a 250 from a fully cloud-hosted Microsoft 365 domain as a real answer.
- Treat any 451 4.7.500-699 as no answer, never as a verdict.
- Re-run the unknown segment a day or two later rather than deleting it.
- Look up the MX record first: a gateway in front of Microsoft 365 answers for itself.
Questions people ask
Does email verification work on Microsoft 365 addresses?
Yes, on most tenants. When a domain's mailboxes all live in Exchange Online, Microsoft rejects unknown recipients at its edge with 550 5.4.1, which is a clear signal for a verifier. Throttling and hybrid setups are what produce unknown results.
Why do Microsoft 365 results vary between runs?
Microsoft throttles connecting IPs that change their sending pattern, answering 451 4.7.500-699 instead of a verdict. The same address can get a 550 on one pass and a 451 on the next. Only the 550 and the 250 say anything about the mailbox.
Is Microsoft 365 a catch-all provider?
No. A fully cloud-hosted domain rejects unknown recipients. A domain still set to Internal relay during a migration passes unknown recipients on, and it behaves like a catch-all until the admin switches it to Authoritative.
What does 550 5.4.1 Recipient address rejected mean?
It means Microsoft 365 has no mailbox at that address. Directory-Based Edge Blocking refuses the message at the edge, before any filtering runs, so it's a reliable invalid signal.