One of my customers is running an exchange environment with multiple Accepted Domains.
The reason for that is that this company is a Holding and it has a bulk of sub companies.
Normally the sub companies are using the Mail service from the Holding environment.
Now one of the sub companies wants to use an autonomy mail environment, which is not attached to the Holdings infrastructure.

 

After they have configured their own Mail system, everything works fine – except mail flow from the Holding.
As an example:
The Holding is called Contoso Ltd. (contoso.com) and the sub company sub.contoso.com.
New Mail infrastructure can receive mails from around the world: @outlook.com -> @sub.contoso.com works without any problems.
But if users from Contoso Ltd. trie to send Mails to the sub company (@contoso.com -> @sub.contoso.com), it fails with the following NDR:

 

As we can see in this NDR, the exchange was not able to find the recipient. The reason for that is clear; there is no mail address or Mailbox of this user in the organization of Contoso. However, why exchange tries to send/deliver the message internal and not external?

 

To figure this out we have to check for some different things in our environment.
Let us start with internal DNS zone:
We need to open a command prompt on one of the Exchange servers in the Contoso environment and run the following command:

nslookup –q=mx sub.contoso.com

With this command, we try to figure out if the MX Record is visible for our Exchange server.

 

As we can see in the print screen, for our Exchange server the domain sub.contoso.com do not exists. I figured out, that there is no internal DNS zone created for the sub Domain.
After we have created this internal DNS zone with the right settings, I had run again the command:

nslookup –q=mx sub.contoso.com

 

Now it looks much better for our Exchange.

So let us try to send a test mail to a recipient in the target domain (@sub.contoso.com).
To track our Mail we can simply use the Exchange management shell and run the following command:

Get-MessageTrackingLog -Start "02/02/2018 13:15:00" -End "02/02/2018 17:00:00" -Sender "[email protected]" -server EXC01

As we can see on the print screen, our message fails to be delivered.

 

Even the NDR shows us again that the recipient user is still unknown.

 

So what to do next?

We going to login to our Exchange ECP and navigate to “mail flow” / “accepted domains”.
Here we can see that our Domain contoso.com is registries as an Authoritative Domain. That means all subdomains will be listening to the main domain, like a wildcard.

 

So let us register here a new accepted domain for our sub company.
For that we will register it as internal relay:

After we have done this, we need to go to our send connectors, if the company is using a smart host for sending mails, we will come back later to it:

 

We have to check if the scoping is set right. In my case all looks good because it is set as Wildcard with the (*) entry.

 

If your connectors are configured differently, you will have to add the sub domain (sub.contoso.com) as an address space.

 

From now, the mail flow is working as expected and we have fixed the issue.

 

 

IMPORTANT:
If you are using a smart host for sending mails, you need to check the configuration there as well. Some of the smart hosts can be configured that all messages from a domain (@contoso.com) included all sub domains has to be delivered to the Exchange organization. In this case the sender mail will again be returned to the Contoso Exchange and not to the sub.contoso.com Mail server and we have again the same NDR.

 

So if you still have the problem after following this article, check your smart host setting!

 

 

Photo by Daniel Jensen on Unsplash