- DBEB (Directory-Based Edge Blocking), defined
- Directory-Based Edge Blocking (DBEB) is the Microsoft 365 setting that rejects mail for addresses missing from the tenant directory before filtering runs.
Microsoft's own documentation, read on 2026-09-25 (page updated 2026-08-03), describes it plainly. Mail for a valid address moves on through anti-malware, anti-spam and mail flow rules. Mail for an address that doesn't exist is blocked before filtering even starts, and the sender gets 550 5.4.1 Recipient address rejected: Access denied.
That reply is what makes Microsoft 365 checkable at all. A 5xx for one named recipient is a definitive no, the same signal a verifier looks for at the `RCPT TO` step of the handshake. Without DBEB the tenant would say yes to everything, and every address on it would look alike from outside.
You don't switch it on by hand in most tenants. Microsoft says that when all recipients for a domain live in Exchange Online, DBEB is already in effect. It's the accepted-domain type that decides: Authoritative turns DBEB on, and Internal relay leaves it off so mail for users still on an old server keeps flowing.
Hybrid setups add a condition. The domain's MX record has to point at Microsoft 365, so mail reaches Microsoft first. If the MX points at an on-premises server or a third-party gateway, that host answers the probe and applies its own rules, and DBEB never sees the address.
Microsoft's page also carries two caveats worth knowing. Dynamic distribution groups created on-premises don't sync to Exchange Online, so DBEB blocks them. And Microsoft notes there might be infrequent cases where an address that doesn't exist is allowed to relay through the service.
Rejection isn't the only hurdle on these domains. Microsoft responds inconsistently and rate-limits probe traffic hard, and it blocks SMTP probes from cloud IPs. The Microsoft 365 provider page walks through what that does to a verification run.
How ZapBounce reports it
When a Microsoft 365 tenant refuses the recipient, ZapBounce returns invalid with reason mailbox_not_found and the server's reply in smtp_code, and mx_host names the host that answered. So you can tell a DBEB rejection from a gateway's. If Microsoft throttles or stalls the probe, the row comes back unknown with reason throttled or probe_blocked, and it isn't billed. A tenant that also accepts our random-address probe returns catch_all, never a confident valid. How it works shows the full check.
DBEB (Directory-Based Edge Blocking): common questions
Is DBEB on by default in Microsoft 365?
Yes, for a domain whose recipients all live in Exchange Online and whose accepted-domain type is Authoritative. Tenants set to Internal relay, usually during a migration, run without it until the admin switches the domain back.
What bounce does DBEB produce?
Microsoft documents it as 550 5.4.1 Recipient address rejected: Access denied. The 5.4.1 enhanced code is the part to watch for in your bounce logs, since it points at the recipient's directory rather than at your sending reputation.
Does DBEB mean email verification works on Microsoft 365?
It means a Microsoft 365 tenant gives a definitive no for missing addresses. Throttling and blocks on cloud IPs still stall some probes, so a share of Microsoft rows lands as unknown and gets rechecked.
Why did a Microsoft 365 address pass verification and then bounce?
Check the accepted-domain type and the MX record first. A tenant on Internal relay, or one fronted by another mail host, can accept at the edge and reject later. Microsoft also notes rare cases where a nonexistent address relays through.