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.




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?
The problem occurs when switching a domain from Authoritative to Internal Relay. If you left the domain as Authoritative you wouldn’t run into the problem at all.
Thanks Paul