A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Exchange 2K3 problem.

I've searched the other solutions to this problem, but none seemed relevant.

Our email is hosted as POP accounts, and we're using eXchange POP3 (a very fine product, BTW) to collect mail from the POP accounts and deliver them to the Exchange server (no lectures please on how this is not cool...there are a number of reasons why we're doing this).

We're switching our domain name, but haven't completed changes yet. In anticipation of the switch, I added to the Generation Rules under the default Recipient Policies the new domain, newdomain.com, but left it unchecked and kept olddomain.com checked.

When I try to send email to any account @newdomain.com, I get "A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients.  Contact your administrator." I've ramped up the Diagnostics Logging to maximum and looked each send up in the Message Tracking Centre, but the message never leaves the system. The last two events are "Message Routed and Queued for Delivery," and then the NDR is generated.

Thinking it might be Exchange looking internally for newdomain.com, I removed the entry from the Generation Rules, and applied the policy, but the error persists. I then flushed the global and Exchange server DNS caches, just in case, but no luck.

Where can I look to purge newdomain.com from the Exchange server's brain, if indeed that is the issue.

Note that mail from other servers, e.g., hotmail.com, delivers successfully to newdomain.com.

Also, although olddomain.com is similarly hosted as a series of POP accounts which eXchange POP3 collects, we have never experienced this error running Exchange in this configuration.

All zone information for newdomain.com points to the external host, i.e., nothing points to the Exchange server. In fact, our internal domain has nothing to do with either olddomain.com or newdomain.com.

Who is Participating?
If you don't enable the policy then Exchange doesn't recognise it as being a domain that it is responsible for and will get confused. The messages will then loop round and generally cause an ugly mess.

You have two options.

1. Remove the domain from the policy.
2. Active the policy.

This isn't caused by the POP3 connector, although I cannot allow it to pass but to say that as far as I am concerned there are no technical reasons why a POP3 connector should be used.

hyogurtAuthor Commented:
As I said, I did remove the domain from the policy, and then I did activate it. I can find nowhere in the Exchange System Manager or anywhere else in AD any reference to newdomain.com, in other words, the Exchange server should have no knowledge of newdomain.com, yet the problem persists.

Is there some cache of this data which needs to be purged? Would a restart of the Exchange server perhaps help?
When you remove a domain from the recipient policies, it doesn't remove it from the user accounts. Therefore if you applied the policy there is a good chance it is still on the user accounts, which will confuse Exchange.

Both the domain and Exchange cache a lot of information. This cache is usually flushed in about two hours or so, therefore based on the time that you posted the question it should be flushed by now.

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

hyogurtAuthor Commented:
I originally only added newdomain.com to the Generation Rules...I didn't actually *apply* the policy, so it did not propogate to users; no user has a @newdomain account, and no one ever did. As I mentioned, I was only preparing for the change, and did not execute it. I thought newdomain.com's mere presence in the list might be affecting the system. But it is indeed completely gone, after never having been applied, and then, with its existence erased, I re-applied the original rules for good measure.

I have also restarted the server (something I never do during business hours...my desperation) and still no success. Any message to newdomain.com generates the error.

I can't think where else to look, what else to do.
If you send an email to that domain using an external account, what happens to it then?
You haven't attempted to put the new domain in to any SMTP Connector or anything like that that could have looped the message back on itself?

Have you started to make MX record changes or anything that could be getting in the way - either internally or externally?

hyogurtAuthor Commented:
Thanks for sticking with me on this, Sembee.

Mail from external accounts (e.g., hotmail) are delivered successfully to newdomain.com.

I've made no modifications to any SMTP connector; the only place I entered newdomain.com was in the Generation Rules, and from there it is now gone.

MX records for the domain are independently hosted outside our internal domain, and contain no references other than what's normal, i.e.,

newdomain.com   84600  MX  IN  (10)  mail.newdomain.com
mail.newdomain.com  84600  A  IN  72.xx.xx.xx

In other words, the Exchange server shouldn't know newdomain.com, and should attempt to send out to it without hesitation. Somewhere, somewhere, it's retaining this information...I just have no idea where. I only entered it once, on the Generation Rules. But now I'm repeating myself...
hyogurtAuthor Commented:
I'm assuming Exchange checks a routing table before it consults DNS, to determine if the message can be delivered internally. The server must be retaining in this routing table information related to newdomain.com, which it picked up from the Generation Rules (even though they were never applied).

Any idea how to access these tables, to view and/or purge them?
Exchange doesn't look at routing tables. It doesn't need to. It knows if an address is local or not.
Try entering the external email address of a valid user in your existing domain. What happens? It gets underlined. Exchange knows at that point that the email is local because it has looked up the address in the AD domain.

If the lookup fails on both your contacts list and the AD domain, then Exchange knows it is external and will attempt to push it out. If there is no smarthost configured either on an SMTP Connector or on the SMTP virtual server then it will do an NSLOOKUP on the domain, find the MX records and attempt to deliver to that. If you had made a mistake and had your own external IP address in the MX records then the message would sit in the queue because the it cannot be delivered to itself - your firewall wouldn't allow it.

Therefore the only thing that is like to be cached is the nslookup information - but if you have never put MX records in to your internal DNS for this domain then that will not be cached and the server will lookup the information off the internet. You can see this for yourself by dropping in to a command prompt...

nslookup <press enter>
set type=mx <enter>
domain.com <enter>

You will then get back the MX records that the server can find.
These should be external IP addresses. If they are internal or blank, then you have a problem.

The original error message that you have posted would tend to indicate that the server your server is trying to deliver to is either rejecting the message or trying to forward it back to the Exchange server, which is therefore rejecting it back to the internet because the domain is not in its recipient policy.

You might see something if you do a telnet test to the SMTP port on your Exchange server and then another test to the SMTP port of the server listed in the MX records OR more importantly the server that your outbound email is passed to.

Are you using any third party SMTP scanning tools that might be getting in the way, that have been configured for this domain?

hyogurtAuthor Commented:
And suddenly...it works.

I attempted an nslookup, but it failed as there was no Reverse Lookup Zone in DNS, so I created one, and added PTR records for the DC and the Exchange server. Then I did the nslookup test, and it provided the correct MX record for newdomain.com.

Then, for the hell of it, I sent another test message, and it worked...it got through, no bounce.

Was it the missing RLZ information that was causing the issue, or at least allowing it to persist?
Most sites I come across don't have the reverse DNS. I usually set it up myself. If you make the reverse DNS zone active directory integrated then it will be populated automatically. I doubt if the lack or PTR information was the cause.

hyogurtAuthor Commented:
Setting up PTR was a cinch. I remember being intimidated by Microsoft's documentation on the matter, which led to my procrastination.

So I guess the newdomain.com info was cached somewhere, and eventually cleared. Wish it hadn't taken virtually all day to happen, I wasted a lot of time.

Thanks Simon for 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.