NDR 550 5.5.1 User Unknown for Internal Relay Domain

When you have configured two Exchange organizations for a shared SMTP namespace you may encounter a problem with non-delivery reports (NDRs) being generated for a domain name that is configured as an Internal Relay.

In the following scenario there are two organizations. Company A is configured with both an Authoritative domain and an Internal Relay domain for Company B.

Your expectation of this configuration is that if Company A receives an email for a recipient in the companyb.com namespace that does not exist in the Company A organization, that the email will be relayed to Company B instead.

However, under certain conditions you may receive an unexpected NDR instead that contains the error “550 5.1.1 User unknown“.

The cause of this issue is the Recipient Filtering feature of Exchange’s anti-spam functionality, which is an optional component for Hub Transport servers but is available by default on Edge Transport servers.

Recipient Filtering will block messages that are addressed to a recipient that does not exist in the organization.

This is undesirable behavior in an Internal Relay scenario because the assumption in that scenario is that the SMTP namespace is shared and therefore many of the recipients will not exist in the first organization that processes the email.

This is normally not a problem though because a domain that is added to the Accepted Domains list as an Internal Relay domain is exempt from recipient filtering. This setting is configured in the AddressBookEnabled attribute of an Accepted Domain.

[PS] C:\>Get-AcceptedDomain | select name,domaintype,addressbookenabled

Name                     DomainType AddressBookEnabled
----                     ---------- ------------------
companya.com          Authoritative               True
companyb.com          InternalRelay              False

However, if a domain is added as Authoritative at first, and then later changed to Internal Relay, the AddressBookEnabled attribute remains set to True, which creates the NDR situation if the recipients have not already been created within the organization (eg as contacts).

[PS] C:\>Set-AcceptedDomain companya.com -DomainType InternalRelay

[PS] C:\>Get-AcceptedDomain | select name,domaintype,addressbookenabled

Name                     DomainType AddressBookEnabled
----                     ---------- ------------------

companya.com          InternalRelay               True
companyb.com          InternalRelay              False

The solution is to use Set-AcceptedDomain to set AddressBookEnabled to False after converting the domain from Authoritative to Internal Relay.

[PS] C:\>Set-AcceptedDomain companya.com -AddressBookEnabled $false

[PS] C:\>Get-AcceptedDomain | select name,domaintype,addressbookenabled

Name                     DomainType AddressBookEnabled
----                     ---------- ------------------
companya.com          InternalRelay              False
companyb.com          InternalRelay              False

When Edge Transport servers are involved this change will take some time to synchronize before it takes full effect.

About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Connect with Paul on Twitter and Google+.

Comments

  1. May be i am wrong, but have a doubt. Why are we making companya.com as internal relay? By keeping companya.com as Authoritative and making AddressBookEnabled to False is enough right?

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.
Loading...

Still running Exchange 2003? Time to get moving and start your upgrade. Find out how - Click Here