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

A partner tells you their mail to one of your users bounces, the NDR says "Recipient address rejected: Access denied", and the first instinct is to blame a spam filter or a blocklist. Almost always it is neither. Exchange Online is telling the sender that, as far as its directory is concerned, the recipient doesn't exist. In this post I'll explain the Directory-Based Edge Blocking feature behind that answer, list the situations that trigger it, and show how to fix and verify each one.

Symptoms#

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.

Why it happens#

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). If the address exists, the message continues to anti-malware, anti-spam and mail flow rules. If it doesn't, the service rejects it on the spot with 550 5.4.1, which saves everyone from processing and bouncing junk sent to invented addresses.

Whether DBEB applies depends on the accepted domain type in Mail flow › Accepted domains:

So the error has one root cause, a recipient address that isn't in the directory while the domain is Authoritative, with several ways to get there:

• 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.
• The domain was switched to Authoritative too early during a migration, or needs a resync after a change.

How to fix it#

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

   If nothing comes back, the fix is to create the right object: a mailbox, a mail user or mail contact pointing at an external system, or a group.
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

   If every recipient in the domain bounces right after a change, Microsoft's guidance is to switch the domain from Authoritative to Internal relay and back to Authoritative to force DBEB to resync its view of the domain.
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. Allow up to 24 hours for DBEB to update after on-premises changes.
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. 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. 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

Verify the fix#

Ask the sender to resend, or send from an external test account yourself, then trace it. Because the message is now accepted at the perimeter, it appears in the trace:

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.

References#

• Use Directory-Based Edge Blocking to reject messages sent to invalid recipients in Exchange Online (Microsoft Learn)
• Manage accepted domains in Exchange Online (Microsoft Learn)
• Email non-delivery reports and SMTP errors in Exchange Online (Microsoft Learn)