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.

Posted on 2006-11-09
Last Modified: 2013-11-15
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,, but left it unchecked and kept checked.

When I try to send email to any account, 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, 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 from the Exchange server's brain, if indeed that is the issue.

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

Also, although 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 points to the external host, i.e., nothing points to the Exchange server. In fact, our internal domain has nothing to do with either or

Question by:hyogurt
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 5
LVL 104

Accepted Solution

Sembee earned 500 total points
ID: 17907833
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.


Author Comment

ID: 17908362
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, in other words, the Exchange server should have no knowledge of, 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?
LVL 104

Expert Comment

ID: 17908630
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.

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 17908774
I originally only added 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'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 desperation) and still no success. Any message to generates the error.

I can't think where else to look, what else to do.
LVL 104

Expert Comment

ID: 17908853
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?


Author Comment

ID: 17909062
Thanks for sticking with me on this, Sembee.

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

I've made no modifications to any SMTP connector; the only place I entered 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.,   84600  MX  IN  (10)  84600  A  IN  72.xx.xx.xx

In other words, the Exchange server shouldn't know, 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...

Author Comment

ID: 17909583
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, 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?
LVL 104

Expert Comment

ID: 17909815
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> <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?


Author Comment

ID: 17910134
And 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

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

Was it the missing RLZ information that was causing the issue, or at least allowing it to persist?
LVL 104

Expert Comment

ID: 17910182
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.


Author Comment

ID: 17940463
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 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.

Featured Post

Back Up Your Microsoft Windows Server®

Back up all your Microsoft Windows Server – on-premises, in remote locations, in private and hybrid clouds. Your entire Windows Server will be backed up in one easy step with patented, block-level disk imaging. We achieve RTOs (recovery time objectives) as low as 15 seconds.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

In-place Upgrading Dirsync to Azure AD Connect
A list of top three free exchange EDB viewers that helps the user to extract a mailbox from an unmounted .edb file and get a clear preview of all emails & other items with just a single click on mailboxes.
To add imagery to an HTML email signature, you have two options available to you. You can either add a logo/image by embedding it directly into the signature or hosting it externally and linking to it. The vast majority of email clients display l…
This is used to tweak the memory usage for your computer, it is used for servers more so than workstations but just be careful editing registry settings as it may cause irreversible results. I hold no responsibility for anything you do to the regist…

761 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question