SBS 2003 Server won't send to Exchange 2003 Standalone with same domain name as one listed in the Recipient Policy

Good morning,

I have a very interesting connundrum. I have a single SBS2003 server behind a Zywall 5 and about 15 users.
We are running Exchange with this network.
Our domain locally is
Our local live internet domain is
Then, in the recipient policies,  we have setup the three domains that we send to.

We have the default policy set to, a external domain hosted in another city. Each user in the local city has to send email as this domain for compliance and simplicity purposes. So, users in Chicago for instance send emails out as Users in another city are members of another domain but we added a recipient policy to allow all internal users to send as

The recipient policy is setup as follows:

Default Policy - default (Not responsible for this organization so the check box is unchecked inside the properties of this selection)

CompanyCity Policy
This is a second policy that is weighted higher.

This policy is at the top of the list while the default policy is at the bottom of the list. - default (Responsible for sending mail to this organization) This domain is the domain that the local SBS server manages. Emails do not go out using this addressing.

For a while, I was having issues where the domain was listing at the bottom of each of the emails that came back as NDR's to domains like comcast, aol, and others.
I checked in the SMTP Virtual Server Properties, then the advanced button and found that instead of, was being used. is a LOCAL domain like I mentioned. It does not resolve DNS wise to any external one to one NAT'd address where as does. So, domains that do reverse lookups where failing those messages.

We altered the setting to be and that worked for that issue.

The email domain is hosted on a Exchange 2003 server in Chicago.
It is 3rd party hosted exchange.
We added a recipient policy to our SBS Exchange box to allow users to send emails out as if they were sending from just like the users on the hosted exchange solution. The problem is, when we send emails to these users from the domain, they come back with the following error:

The e-mail account does not exist at the organization this message was sent to.  Check the e-mail address, or contact the recipient directly to find out the correct address.
< #5.1.1>

Does having a recipient policy set for here in our office in a different city on a different server cause issues in this solution?
Do I need to enter a DNS entry for the server in Chicago so that if the Exchange box can't do a directory look up for a user in the Chicago office locally it will forward mail there?

Basically, I need to be able to email people in our chicago office.

Since they host the domain, and I have as a recipient policy setting that has all outbound mail tagged with that domain, and it can't find them locally on the SBS server, it is failing when we try to send.

Any help would be appreciated!

Who is Participating?
SembeeConnect With a Mentor Commented:
What you are trying to do is share the SMTP name space.
This article goes through your options on how to share it.

The problem will be the other side. It depends on how much freedom the hosting company has allowed. If they can add the second domain name, then that makes deployment much easier.

The other option would be to use the send unknown recipients to server feature. However that would mean you cannot have anyone in the other office listed in the GAL, so no members of the distribution groups etc. When they are shown in the GAL that means the object is local and messages to that object would not be sent out.

PatrickDomanAuthor Commented:
Where is this send unknown recipients to server feature? I saw a filter unknown recipients check box option...
It is on the SMTP Virtual Server.

ESM, Servers, <your server>, Protocols, SMTP. Right click on the default SMTP VS and choose Properties. Click on the tab Messages. The box is at the bottom.

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Jeffrey Kane - TechSoEasyConnect With a Mentor Principal ConsultantCommented:
Actually this problem can be resolved quite easily (even though your configuration is a nightmare) by adding a FQDN to your Exchange Configuration.  

In your Server Management Console, navigate to:
Advanced Management > First Organization (Exchange) > Servers > Servername > Protocols > SMTP > Default SMTP Virtual Server.  Right click that and select Properties.

Then select the MESSAGES TAB and at the very bottom you'll see "Forward all mail with unresolved recipients to host"
In this box enter

There's a good little overview about how this works if you click help on that particular window.

This is yet another reason that you should not use a .com for your local domain and instead use the recommended .local (or any other non-resolving TLD).

PatrickDomanAuthor Commented:
This didn't fix it, I am only out here once a month and I hate to make these changes while remote. I altered the SMTP Virtual Server like you mentioned sending all email to that can't be resolved... I then changed the default SMTP Recipient Policy to be the because email needs to show that it went out as instead of

It just sits in the queue.
Jeffrey Kane - TechSoEasyPrincipal ConsultantCommented:
Well, I'm assuming that WHATEVER the actual FQDN of your mailserver in Chicago is, that's what you put for  If that can't be resolved, then it sounds to me as though you've created a DNS zone file for on your SBS, which is not necessary at all.

Normally, your SBS wouldn't care at all that another server is hosting email for the same domain name... it doens't know because it doesn't ask.  But since you have created an EMAIL domain space of it would first look for the recipient in Active Directory (because your DNS is AD integrated), and then would normally FAIL if it didn't find a match.  But if you put the FQDN of an outside server with the same domain name, then it will go out to the Internet to look for that host.

So, have you manually modified the standard SBS DNS structure?

PatrickDomanAuthor Commented:
I added the entry to the SMTP virtual server under the messages tab as instructed. It just sat in the queue.

I then went back and created a zone for I added a host record in there with the external IP address for It still wouldn't forward. That is about where the queued email NDR'd back to the person testing it for me.
Jeffrey Kane - TechSoEasyPrincipal ConsultantCommented:
Well, does resolve over the Internet?  Can you look it up at and see if it works?  If it just sat in the queue I would wonder why it didin't go out to look for it... that would be due to something locally that's prohibiting it, or that it just doesn't exist externally.  HOWEVER, your NDR stated that the email account didn't exist... not the domain.  So it was checking your OWN server for the account and never got outside.

With all that you've apparently configured manually it will be rather difficult from this perspective to sort it all out for you.  Since SBS's configuration is handled by the wizards you need to get your basic services operating that way first, and then incrementally make changes so you know what works and what doesn't.

I'll be happy to take a look at a couple of things though... if you can first post a complet IPCONFIG /ALL from the server that would be a good place to start.  While there is nothing in an IPCONFIG that would compromise security, you may want to slightly edit it for privacy purposes.  If you choose to do that, please only replace the last two octets of a Public IP Address with ***.*** and the first part of the domain name can be replaced with *******.

PatrickDomanAuthor Commented:
Ok, I found the actual fix to this. We were very close.

I had a recipient policy for each @company.... option before we moved to this new server, however there is a better way to do it.

Go to the Recipient policy properties.
Only use the default and make sure there is no reference to the domain you are adding.

I have in there now.
I have in there as well.
I removed

From there, when the entry is removed, it will leave the SMTP address in the Active Directory "Email Addresses" tab.

So I have in there as a email address, in this case I set it to be the default as that is the address we want to send as now.
I have in there as well.
I have user@companyolddomain in there as well.

So, emails from all 3 domains will go to users that have them setup there.

Having the as the default allows this to work in that the mail message is coming from as the default recipient policy so emails will resolve IP wise from where they leave to the domain name here in the office. We're just simply masking the identify if you catch my drift. So, setting the default SMTP Email Address to allows Exchange to send the message as while still sending and being able to resolve the because it doesn't get frustrated about trying to resolve as it is not local.

So it was a mixture of the Microsoft Way and Tricking the server that resolved this but I do appreciate your help.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.