550 5.4.1 Recipient Address Rejected: Access Denied (Exchange Online)

What’s actually happening

Mail to an address on a Microsoft 365 domain bounces with 550 5.4.1 and the AS(201806281) tag. The sender gets the NDR even though the domain itself clearly exists and accepts other mail. It can affect one recipient (a typo or unsynced mailbox) or every recipient at a domain (a directory or policy problem). The same address may have worked before a migration or directory change broke it.

Common causes

• Directory-Based Edge Blocking rejects the address because no mailbox, mail user, contact, or group in the tenant matches it for an Authoritative accepted domain.
• The recipient was deleted, renamed, or had that proxy/alias removed, so the SMTP address no longer resolves to any object.
• In a hybrid setup the on-prem mailbox exists but is not synced to Entra ID / Azure AD, so the cloud directory DBEB checks does not know about it.
• An anti-phishing or spoof-intelligence policy in Defender for Office 365 blocked the sender rather than the recipient being invalid.
• A simple typo in the recipient address, or an accepted domain set to Authoritative when it should be Internal Relay for downstream routing.

How to fix it

1. Verify the recipient address existsRead the address in the NDR carefully for typos. In the Exchange admin center or via Get-Recipient -Identity user@domain, confirm there is an object with that exact SMTP address. If it is missing, the address is genuinely invalid — correct it or recreate the mailbox/alias.
2. Scope it — one recipient or the whole domainSend to a known-good address at the same domain. If that delivers, the problem is the one missing recipient. If everyone bounces, suspect the accepted domain type or directory sync rather than the individual mailbox.
3. Fix directory sync for hybrid mailboxesIf the mailbox is on-prem in a hybrid org, make sure the object is synced to Entra ID and that its address is present in the cloud directory DBEB references. Run a delta sync (Start-ADSyncSyncCycle -PolicyType Delta) and re-test once it completes.
4. Check the accepted-domain typeIf a downstream system should receive mail for the domain, set the accepted domain to Internal Relay instead of Authoritative so DBEB stops rejecting addresses it cannot see locally. Authoritative means 'all valid recipients live here.'
5. Rule out an anti-phishing blockIf the recipient definitely exists, check Defender for Office 365 anti-phishing and spoof policies and the message trace. A spoof or impersonation rule can surface as 5.4.1 Access denied even though the address is valid; adjust the policy or add the sender to the allowed list.