550 5.4.1 Recipient Address Rejected: Access Denied

Problem

Mail bounces with a permanent non-delivery report: 550 5.4.1 Recipient address rejected: Access denied. The message never reached the mailbox, and the sender gets an NDR pointing at the recipient address. This is the classic fingerprint of Microsoft 365 / Exchange Online rejecting mail at the edge.

Symptoms

• The NDR reads exactly 550 5.4.1 <recipient@domain>: Recipient address rejected: Access denied.
• The reporting server in the bounce is protection.outlook.com or another Exchange Online host.
• Some recipients on the domain receive mail fine; only certain addresses bounce.
• The address looks correct and the recipient insists their mailbox exists.
• Mail to a mail-enabled public folder or a distribution point started bouncing after a migration.

What This Error Actually Means

Read the enhanced status code as two separate claims. The 550 is a permanent SMTP rejection — do not retry, this will not fix itself. The 5.4.1 plus the words Recipient address rejected: Access denied is Microsoft’s signal that the recipient system does not recognize this address and refused it at the perimeter.

The key point: this rejection happens before content filtering, spam scoring, or sender authentication. It is not about who you are or whether your SPF passes. It is about whether the address you sent to exists, as far as the receiving directory is concerned. That is why it is so often misdiagnosed — people see “Access denied” and start hardening SPF and DKIM, when the receiver never even looked at those.

In Microsoft 365 this behavior has a name: Directory-Based Edge Blocking (DBEB). When an accepted domain is marked Authoritative, Exchange Online treats its own directory as the complete, final list of valid recipients for that domain and bounces anything it cannot match. DBEB is a feature — it kills spam and backscatter aimed at made-up addresses before it costs you anything. It only becomes a bug in your eyes when a legitimate recipient is missing from the directory the edge is checking.

Top 3 Causes

1. The recipient address does not exist in the directory — A typo, a deleted or deactivated mailbox, or a mailbox that is still provisioning. DBEB checks the directory and finds nothing, so it refuses. This is DBEB doing exactly its job.
2. A shared domain is set Authoritative when it should be Internal Relay — The domain is split: some mailboxes live in Microsoft 365, others on an on-prem Exchange or a third-party host. If the accepted domain is Authoritative, Microsoft blocks every address it doesn’t host itself. Setting it to Internal Relay tells Exchange Online to hand unknown-but-valid addresses onward instead of bouncing them.
3. A mail-enabled public folder or unsynced object — Mail-enabled public folders are not synchronized to Entra ID, so DBEB cannot see them and rejects their mail. The same gap appears when directory sync (Entra Connect) has not yet propagated a newly created recipient.

Diagnose with DechoNet

• Email Check on the recipient domain to confirm where its mail actually routes — if the MX points at *.protection.outlook.com, you are dealing with Exchange Online and DBEB is the prime suspect.
• Email Header Analyzer to read the bounce itself: confirm the reporting MTA, the exact enhanced code, and that the failure is 5.4.1 (directory) rather than 5.7.x (authentication) — this is the single most decisive check.
• DNS Check to verify the recipient domain’s MX and any split-routing records, so you know whether the address should live in Microsoft 365 at all or be relayed elsewhere.

Resolution Checklist

• Confirm the code is 5.4.1 with “Recipient address rejected: Access denied,” not 5.7.1/5.7.26. If it is a 5.7.x code, this is an authentication or policy problem — see the SPF and unauthenticated-mail guides instead.
• Verify the recipient address exists and is spelled correctly. Check it in the Exchange admin center or ask the recipient’s admin to confirm the mailbox is active and visible in the directory.
• If the recipient is legitimate but on a shared/split domain, have the recipient’s admin change that accepted domain from Authoritative to Internal Relay in Mail flow > Accepted domains.
• If the recipient was created recently, wait for or force directory sync (Entra Connect); the address can be valid in the admin console but not yet at the edge.
• For a stubborn DBEB cache after fixing the object, toggling the accepted domain Authoritative → Internal Relay → Authoritative forces an immediate re-query of the directory.
• For mail-enabled public folders, route through Internal Relay or the documented public-folder workaround, since DBEB does not see them.

When to Escalate

• This bounce is generated by the recipient’s mail system, so most fixes belong to the recipient’s administrator, not you. Escalate to them with the exact NDR text — the 5.4.1 code and reporting host tell their admin precisely which accepted-domain or directory setting to check.
• If you are the recipient admin and a valid mailbox keeps bouncing after directory sync, escalate to Microsoft support with the message trace: a DBEB rejection that survives a correct, synced recipient object points at a backend sync fault on their side.