NDR 550 5.4.1 “Recipient address rejected: Access denied”: Directory-Based Edge Blocking

Symptoms to confirm

The sender receives an NDR with a line like this, usually with a server name and an internal code appended:

550 5.4.1 Recipient address rejected: Access denied. AS(201806281)
[DB5EUR03FT054.eop-EUR03.prod.protection.outlook.com]

• It typically affects external senders writing to your domain, and in hybrid environments it can also hit internal mail destined for an on-premises recipient.
• Other recipients in the same domain usually receive mail normally, unless the whole domain was recently moved or re-pointed.
• The rejection happens during the SMTP conversation at the service perimeter, before filtering, so the message often never shows up in your message trace. The sender's NDR is your main evidence.

Likely causes

Directory-Based Edge Blocking (DBEB) checks every inbound recipient address against the recipient objects Exchange Online knows about (mailboxes, mail users, contacts, groups and synced objects from Microsoft Entra ID).

• The recipient genuinely doesn't exist: a typo, a leaver whose mailbox was removed, or an alias that was dropped.
• The domain was just added or the MX record just moved to Microsoft 365, and the users haven't been created or synced yet.
• Hybrid objects are missing: an on-premises mailbox outside the sync scope, or a proxy address that never made it to Microsoft Entra ID. Microsoft notes that changes to on-premises objects can take up to 24 hours to be reflected in DBEB.
• On-premises mail-enabled public folders that weren't synchronized to Exchange Online.
• On-premises dynamic distribution groups, which never sync to Exchange Online.

+1 more causes in the full article.

Checklist

1. 1

   Confirm the address from the NDR exists

   Resolve it in Exchange Online PowerShell; Get-Recipient matches primary and proxy addresses, and the wildcard search helps when you suspect a typo or a removed alias.

   powershell

   Get-Recipient -Identity megan@contoso.com | Format-List Name, RecipientTypeDetails, PrimarySmtpAddress, EmailAddresses
   Get-Recipient -ResultSize Unlimited -Filter "EmailAddresses -like '*megan*'" | Format-Table Name, RecipientTypeDetails, PrimarySmtpAddress
   
   # Removed recently? Check soft-deleted mailboxes
   Get-Mailbox -SoftDeletedMailbox -Identity megan@contoso.com -ErrorAction SilentlyContinue | Format-List Name, WhenSoftDeleted

2. 2

   Check the accepted domain type

   and whether the problem is one recipient or the whole domain.

   powershell

   Get-AcceptedDomain | Format-Table Name, DomainName, DomainType, Default

3. 3

   Fix the hybrid object

   For an on-premises mailbox, verify the user is inside the Microsoft Entra Connect sync scope and that the SMTP address is present in proxyAddresses. Microsoft's documented nudge for a single stubborn recipient is to change the proxy address to a temporary value and then revert it, which triggers a fresh sync.

4. 4

   Sync mail-enabled public folders

   If the recipient is an on-premises mail-enabled public folder, it must exist in Exchange Online as a synced object. Microsoft provides the Sync-ModernMailPublicFolder script for hybrid public folder deployments; run it and confirm the folder's address now resolves with Get-Recipient.

5. 5

   Replace on-premises dynamic distribution groups

   They can't be synchronized, so create a mail contact in Exchange Online with the same external address as the group. DBEB then accepts the message and routes it on-premises through your hybrid connector.

6. 6

   Use Internal relay deliberately during migrations

   If the domain is shared with another mail system, set it to Internal relay, make sure an outbound connector routes unknown recipients to that system, and only switch back to Authoritative once every recipient exists in Exchange Online.

   powershell

   Set-AcceptedDomain -Identity contoso.com -DomainType InternalRelay   # while recipients still live elsewhere
   Set-AcceptedDomain -Identity contoso.com -DomainType Authoritative   # when every recipient is in Exchange Online

Watch out: Internal relay is not a free pass. Without a connector that can deliver the unknown addresses, Exchange Online accepts the message and then fails it later, so the sender still gets a bounce, just a slower and less obvious one. Treat Internal relay as a migration state with an end date.

Verify

Ask the sender to resend, or send from an external test account yourself, then trace it.

Get-MessageTraceV2 -RecipientAddress megan@contoso.com -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date) |
    Format-Table Received, SenderAddress, Subject, Status

• Delivered: the recipient resolves and DBEB is satisfied.
• Still no trace entry and the same NDR: the address still isn't in the directory. Re-check the exact spelling in the NDR against Get-Recipient output, and give synced changes the documented 24 hours.
• Trace entry with a different failure: DBEB is no longer the problem; follow the new status (connector routing, on-premises delivery, filtering).

Prevent it next time

• Before pointing a domain's MX record at Microsoft 365, create or sync every recipient first, and keep the domain Internal relay until that's done.
• Keep directory synchronization healthy and alert on sync errors; most hybrid 5.4.1 cases are sync problems wearing a mail-flow costume.
• When you decommission a mailbox, decide what happens to its address: a contact, a forward on a shared mailbox, or an intentional bounce.
• Remember the signature: 5.4.1 from a mail.protection.outlook.com host means "unknown recipient, Authoritative domain", not blocklisting or spam filtering.