550 5.4.1 Recipient address rejected: Access denied

July 7, 2021 | by iaur | posted as Exchange Online, Mail Flow

Scenario

• A specific User or Shared mailbox is unable to receive inbound email
• The recipient is a full blown mailbox and able to receive emails before
• There are major changes with the recipient prior to the issue
• The sender is receiving an NDR or DSN with error 550 5.4.1 Recipient address rejected: Access denied
• By checking this KB, the MX record is fully should be propagated
• The issue does not appear when configuring your domain in Accepted Domain from Authoritative to Internal Relay
• The recipient is NOT a Distribution list or group

Context

I’ve dealt with 550 5.4.1 Recipient address rejected: Access denied error a few times before and came up with two path ways for you as a result.

Firstly, “The long way“. This path normally leads you to call M365 Support via the need help button in your Admin Center and the support engineer will present you a solution to run some backend scripts that would take 23-48 to replicate. Similarly, or even worst, the mailbox complication gets to a different level and end up needing a MSFT engineering’s support to fix it. However, in some cases it would take a week to a month to complete.

Finally, “the workaround“, The path that i usually take. Most of the time the issue is not on EOP If you’ve tried to configure your domain in Accepted Domain from Authoritative to Internal Relay. Configuring it that way is like simply turning off DBEB.

Directory Base Edge Blocking (DBEB) is a feature MSFT has introduced to recognize none existing mailbox at the server level so that the senders will get an NDR instantly. In other words, the root issue reside most probably on the MSOL or Azure AD level and the MSOL sync is not picking up the needed object’s email address details.

Moreover, triggering a sync that would not require MSFT intervention is the tricky part. The most viable and the safest I’ve discovered so far is adding a dummy smtp alias to the problematic mailbox.

Workaround

User Interface (UI)

Follow this link If you are more comfortable using the UI in Exchange Admin center (classic). However, replication time could take longer.

PowerShell

• Connect to EXO using PowerShell
• Identity the problematic mailbox’s user login (UPN) or email address (PrimarySMTPAddress)
• Formulate and run the cmdlet below

# To add an smtp alias

Set-Mailbox -Identity user@domain.com -EmailAddresses @{Add="user_dummy@domain.com"}

# user@domain.com is the target mailbox email address
# user_dummy@domain.com is the dummy smtp alias

Get-Mailbox -Identity user@domain.com | select -ExpandProperties EmailAddresses

# To counter check the changes made

• If no errors, wait for 30 minutes to a few hours
• Test the inbound email flow again