Exchange Online Protection 550 5.4.1 Recipient address rejected: Access Denied. AS(201806281)

Exchange Online Protection 550 5.4.1 Recipient address rejected: Access Denied. AS(201806281)

5/5 - (3 votes)

Today, I found myself working with a customer that was experiencing delivery failures to some Office 365 recipients from all external senders.

As problems go, this one definitely finds itself in the “interesting” category.  No, it’s never good to have “interesting” problems (just ask a doctor).

The scenario:

  • MX record points to on-premises spam gateway, which delivers to on-premises Exchange 2013 environment
  • All mailboxes were hybrid migrated to Office 365
  • Azure AD Connect is synchronizing identity
  • Inbound mail from external senders was not being delivered to some cloud recipients, though the same cloud recipients could send external mail and could send/receive with internal users.

Ran through the normal troubleshooting:

  • on-premises Exchange receive connector is listening on port 25
  • mail gateway log say ‘delivered’ to Exchange server
  • Exchange server has valid 3rd-party certificates bound
  • recipients have the correct type, depending on if they are new or migrated mailboxes
  • recipients in Exchange have proxy address
  • recipients in Exchange have valid target address pointing to the correct proxy
  • on-premises Exchange server can contact on port 25
  • Hybrid Configuration Wizard was run successfully

Enabled protocol logging, restarted the transport service, and decided to start investigating more deeply.

I discovered this snippet in the Send log:

MAIL FROM:<> SIZE=264118
RCPT TO:<> ORCPT=rfc822;
250 2.1.0 Sender OK
550 4.3.1 Recipient address rejected: Access denied. AS(201806281) []

The message is getting to Exchange Online, but it is being rejected.  550 is generally a “mailbox not found,” but the status code is … interesting, as we know the mailbox exists and can successfully conduct internal transactions.

In this case, the temporary solution was disabling Directory-Based Edge Blocking (DBEB) by changing the customer domains (not the ones) in Exchange Online to InternalRelay.

The larger problem was caused by some on-premises Active Directory issues that were synchronized via AAD Connect.  Each affected object needed to be updated (in essence, removing and re-adding SMTP addresses) to ultimately resolve the issue.


Published by Aaron Guilmette

Helping companies conquer inferior technology since 1997. I spend my time developing and implementing technology solutions so people can spend less time with technology. Specialties: Active Directory and Exchange consulting and deployment, Virtualization, Disaster Recovery, Office 365, datacenter migration/consolidation, cheese. View all posts by Aaron Guilmette

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Exit mobile version