TL;DR
- Microsoft 365 is not a catch-all by default. For an authoritative domain, "emails for unknown recipients are rejected".
- An internal relay domain passes unknown recipients on to another mail server, so the answer then depends on that server.
- From our own tests, Microsoft refuses a probing IP that is on a blocklist, so many Microsoft-hosted addresses come back unknown rather than valid or invalid.
The direct answer
Exchange Online (the mail service in Microsoft 365) has two accepted-domain types (Microsoft Learn: manage accepted domains, checked 2026-10-18):
- Authoritative: "Email is delivered to email addresses that are listed for recipients in Microsoft 365 or Office 365 for this domain. Emails for unknown recipients are rejected." This setting enables Directory-Based Edge Blocking (DBEB).
- Internal relay: mail for recipients Microsoft doesn't know is relayed to the organisation's own mail server.
Microsoft says that if all recipients for a domain are in Exchange Online, DBEB is already in effect. When it blocks, the sender gets an error that "looks like" 550 5.4.1 Recipient address rejected: Access denied (Microsoft Learn: Directory-Based Edge Blocking, checked 2026-10-18). The same page warns there may be "infrequent instances" where a non-existent address is allowed through.
The documents we read describe no catch-all switch for Microsoft 365. We therefore don't claim that tenants can't be catch-all, only that the behaviour Microsoft documents is rejection (authoritative) or relay (internal relay).
What this means for verification
The method is the same everywhere: we open an SMTP session with the domain's mail server, ask whether it will take mail for the address, ask the same about a random address that cannot exist, and never send the message (how it works).
| What the server says | Our result |
|---|---|
| Authoritative domain, mailbox exists | deliverable |
550 5.4.1 Recipient address rejected | undeliverable: rejected_email |
| Internal relay, forwarded to an accept-all server | risky: low_deliverability |
Refuses us for who we are (5.7.x, blocklist or policy text) | unknown: blocked_by_server |
Temporary 4xx answer (deferral, rate limit, greylisting) | unknown: unavailable_smtp after a later retry |
Our code treats a 5.7.x refusal or text such as "blocked" or "Spamhaus" as a statement about our IP, not the mailbox, and returns unknown. A reply that clearly says the recipient was rejected, such as the DBEB text, wins and is counted as a real rejection.
What our own data shows
In a five-address test on 2026-10-17, Microsoft's mail protection servers answered from our home connection with 550 5.7.1 ... Client host [ip] blocked using Spamhaus. That likely reflects a residential-IP listing, not anything about the mailboxes. The lesson we draw is limited: from a single probing IP that Microsoft doesn't trust, Microsoft-hosted domains often come back unknown. We have no measured rate and don't quote one. Unknowns are refunded.
What to do
- Treat unknown on Microsoft domains as "not checked", not as bad.
- If you must send to them, send small batches and watch bounces (how many bounces burn a domain).
- For consumer Hotmail and Outlook.com addresses, see the Outlook.com page.
Sources
- Manage accepted domains in Exchange Online: checked 2026-10-18
- Use Directory-Based Edge Blocking: checked 2026-10-18
Common questions
Is Microsoft 365 a catch-all?
Not by default. For an authoritative domain Microsoft rejects unknown recipients. Internal relay domains pass them to another server, so those can behave differently.
Why do Microsoft addresses come back unknown?
Microsoft can refuse a probing IP, for example one on a Spamhaus list. That is a statement about the IP, not the mailbox, so we return unknown and refund it.
What does 550 5.4.1 Recipient address rejected mean?
In Microsoft 365 it is the reply for an address that doesn't exist in the organisation when Directory-Based Edge Blocking is active.