Exchange 2003 not consistently sending mail to domains MX records, sending directly to A record

That's a pretty vague answer...  What makes you think it's a DNS issue?  There have been no reports of any other users on other servers receiving bounced messages when sending to this domain.  DNS lookups consistently show the correct information for the MX records.  And immediately following the bounced message, resending the same message from the sent folder consistently is delivered correctly.  DNS information would likely be cached so I'd feel it unlikely it is DNS related.  If you have any other insight that I might have overlooked I'd certainly appreciate the feedback.

Check the problematic email domain records through www.dnsreport.com to highlight any issues. Use the tools found at www.dnsstuff.com to check email addresses and dns records. Will wait for your update on what you find. I cannot test as i am connected via mobile.

Re read your question. Cant this be an ip spoofing? Can you identify that fact?

I have checked records with dnsreport.com and everything passes fine.  I'm not sure which tests you would like me to run at dnsstuff.com.  I used the test for email address and it shows the appropriate MX records that do NOT include the server that mail delivery was attempted to.  What is it you hope to find wrong in these tests?  Perhaps if you share with me why you think this is a DNS issue I would have a better idea of what I'm looking for.

Forget my last comment. I seem to have misread.

How can this be related to IP spoofing?  There is no indication that any traffic is being generated from a server other than my Exchange server.  I send a message to the destination domain from my exchange server and there are corresponding log file entries on the other mail server with the appropriate time stamp for the messages that are rejected.  

It's almost certainly a DNS problem.

It's perfectly normal for a mailserver to attempt delivery direct to the A record when no MX records exist for the domain in question. I suspect that what is happening is that the mailserver is failing to retrieve the MX records for the domain and falling back to the A record. The problem is that if it's a sporadic DNS failure then it will be very difficult to pin down.

One way around it would be to firewall off your internal mailserver so that only the servers you specify can connect to it. If you do this then rather than the messages bouncing, they'll be queued on the remote exchange server until things sort themselves out and correct delivery to the MX records can be attempted.

dynamite - In theory that sounds possible but it seems terribly unlikely to me.  Why would no other mail servers be exhibiting this behavior?  I have scanned log files for days and am not finding any reference to servers attempting a connection to the A record other than those from this particular server.  Assuming it is a DNS problem, how would you explain why the messages always resend correctly moments after they bounce.  I would think cached DNS information would keep this attempted delivery to the A record until the data expired.  And what is the probability of having a failure to access only MX records for a domain but being able to successfully obtain the A record?  It must be finding some information to attempt delivery anywhere.

Your idea of using the firewall to avoud messages from bouncing sounds like a possible solution.  Unfortunately since this server accepts mail for domains other than those filtered by the 3rd party service, I can't just block IP's.  I would need to be able to accept mail to this server for certain domains but not others.  That is why we are using ACL's to restrict delivery rather than a firewall.  However, it makes me think about another possibility.  If I error with a 4XX response rather than 5XX, would Exchange also see this as a temporary failure and requeue?

It might bandaid the problem enough to not have bounced messages.  I don't particularly like the idea that mail will be held in queue for delivery for a failure that should not be happening anyway.  I'd much rather find the source of the problem and have mail delivered promptly.

What else is on the server that is sending the message?
To the best of my knowledge, Exchange will not try to use A records - if it cannot find the MX records then the message sits in the domain. However if something else is doing the email delivery then that could be doing the delivery to an A Record.

Simon.

Sembee - There is nothing else on that machine.  It is a dedicated server for strictly Exchange.  It was my understanding as well that Exchange would not deliver to an A record.  I've seen conflicting information on this but the last I had checked the RFC for mail delivery specified that it should not use an A record for delivery and fail the message if there was no defined MX record.  Here I'm being told otherwise and while searching the web I've found differing opinions on how that is supposed to be handled.

I also wouldn't believe it is something else attempting delivery because the bounce message is from the Exchange server and contains the delivery error code from the destination server.  If something else was attempting delivery on behalf of Exchange it would have to be transparent in the delivery process.  

dynamite - In order for your situation to happen, are you saying that the DNS lookup must result in no MX records being sent back but not a failed lookup to the server?  In other words if the Exchange server failed in the attempt to look up the MX records this would not happen but if the lookup was successful but the authoritative DNS set back an empty list then it would deliver to the A record?

To avoid any confusion over the issue of delivery to A record vs no delivery I just tested the theory.  I created a new domain with no MX but with an A record and Exchange (2003 at least) will route the mail to the A record as dynamite indicated.

That's correct.

Working backwards from the problem you're seeing, the only reason that the Exchange server should be trying to deliver direct is if it thinks there are no MX records, just an A record.

Given that we know that there are MX records, it almost certainly indicates a temporary DNS problem.

I've occasionally seen a similar DNS problem with W2003 DNS servers where they are under the impression that there is no A record for a host, and this lack of result is cached for a short period of time. I only ever saw it on 1 of 6 DNS servers at a time (although not always the same one), so chances were that if you checked the DNS by hand it would almsot certainly give the right answer. I never actually worked out the cause of this, so that probably doesn't help much.

That is what brings me to my initial question...  You said the only reason that the Exchange server "should" be trying to deliver direct.  My concern was that something was mucked up with Exchange and it wasn't behaving as expected.  I can follow the logic of why it would use the A records but what just totally eludes me in this situation is this server appears to be the only server having any problem sending mail to this domain.  Log files on the destination server clearly show rejected connections for machines trying to use the A record and it's just this one server.  A DNS issue would seem to certainly effect other servers as well.

Not if the DNS issue is related to the local name servers that the Exchange server is using.

OK lets see if i can help make this a bit more confusing...
in windows environment every client and server act as both a dns client and dns server...how does this work?...
lets assume we have a brand new network with clients and DNS servers....and your exchange server tries to send a brand new email to a new address....first the client (XP or windows 2003) checks its catche and if the record is not found then it contacts the DNS server configured in the TCPIP settings....DNS server then checks its catche and if the record is not found (also if not the authoritave server) then it goes over the net searching for that record....when
it is found it writtes down the TTL and keeps it in its ctache and forwards the information to the client(the xp or 2003
server)....the client keeps record of TTL and keeps the info in its CATCHE....
in your case as outlined by dynamite it is possible for no MX record to be returned and A record to be used instead....
so in theory when resending exchange must use the catche if the TTL is not expired  which means A record whould be used......

now you have two things to figure out.....is TTL expired or not durring the resend....if yes then it is normal to see the MX record being used(maybe the DNS server responding was not as busy as the first time)....

if TTL is not expired then MY GUESS WILL BE that since no MX record were returned on the first try(A record was returned) then windows simply does what it does everytime you send an email....contacts DNS for AN MX record and DNS server gets it right the second time.....


PS: DYNAMITE i like your explanation( RFC 974)....i learned something new....you deserve 5000 points....

Vahik, I appreciate the lengthy explanation of DNS.  I'm already well aware of how it works but perhaps it will help someone else viewing this question.

There are a few things that I want to point out.

1. If the DNS issue is "outside" causing MX records to not be supplied then I would expect this to be an issue from other servers sending mail to my domain.

2. If the DNS issue is "inside" and the claim is that this Exchange server is somehow having issues obtaining MX records from the DNS server, why do I not have problems sending mail to any other domain?  And yet it has no problem obtaining the A record from the same DNS server.

3. If the issue is related to cached information, why does it always only fail one time.  I send out mail to that domain from this Exchange server all day long.  And consistently after every bounced message that comes back after attempting delivery to the A record, a resend of the message just moments later always delivers correctly.

All of the explanations make sense but are not practical explanations as to why this is happening.  DNS server load would not cause just one domain's email to fail, my DNS server for the domain wouldn't cause just one Exchange server to not obtain MX records.  And none of the situations explain why it consistently sends on a resend.  I certainly can't be lucky enough to always click resend on expiration of TTL.

One other thing just to clarify...

"in your case as outlined by dynamite it is possible for no MX record to be returned and A record to be used instead....
so in theory when resending exchange must use the catche if the TTL is not expired  which means A record whould be used......"

On the resend, Exchange is NOT using the A record.  It is using the correct MX records because it is sucessfully sending.

This has been enlightening and although it doesn't necessarily address the root cause of the problem it does shed enough light on the issue to further troubleshoot.  I wish I had access to the servers involved to browse log files, etc.  Regardless it seems that Exchange is doing what DNS is telling it to do in which case this issue isn't terribly appropriate to this category.

I appreciate the insight.  I believe the only real solution at the moment is the bandaid approach to changing the error code to 4XX as a temporary failure and allowing the server to resend at a later time.

coralogic i have answered thouands of questions and recieved even Fs for my efforts,,,,,but never been so diappointed
by a grade like this one....and this will be the first time i must ask ADMIN  Sembee to reconsider your GRADING....
I also would like Sembee to ACCEPT THE ANSWER from Dynamitedotorg (all point should go to him)since his comments were crucial in solving your problem.....

i must also add i have not only paticipated in thousands of questions and answers but i have also read every single question asked and answered here on the exchange forum for the past 3- 4 years and  this one should be considered one of the classics(classic is the one where u dont find your answr on a MS site or doing a GOOGLE search)....and i dont say this because i participated in it....
dynamitedotdog i see this is your first post but i can also see that you know what you are talking about....KUDOS to you....

I'm a little taken back by your comments and would really like more explanation as to what you find so disappointing.  I certainly made every effort to be accurate in the grading and the dispursement of points.  Both you and dynamite offered significant insight into the issue and I felt it was fair for both of you to be compensated for that effort.  As for the grading, I used the guidelines that were provided in the link.  It indicated that if the answer I received did not answer the problem but gave information that would lead to an answer that a grade of B was appropriate.  I suppose if you look at this from the prospective of the answer is Exchange isn't the problem then yes it was solved but it did not completely remedy the problem so I graded it accordingly.

I am fairly new to the site but assure you my attempts were made with good intentions.  If Sembee should see fit to change what I have done then I certainly have no objections to that but for future reference it would be good for me to know why you were so disappointed with what I have done and why.

I wanted to point out as well that you were the first response to my question and indicated then it may have been a DNS issue and not Exchange.  I would have thought of anyone to be upset about dispursement of points that you would feel slighted if not awarded any points for your comments.

It looks as thought I'm just not familiar enough with the grading system and took it too literally.  There is a great deal of speculation in the answer to this problem and unfortunately it has reached a dead end not due in part to those answering questions but due to the fact I have limited resources to further troubleshoot this problem.  Taken literally I do need more information to complete the task but that information can't really be obtained without further investigation.

I understand from Simon's post that I was looking at the grading system in a different prospective.  I would think giving an A for best effort even when the problem has not been solved gives an inaccurate representation and skews grading to prodominately A.  But if that is how the system is geared then I have no objection to giving an A.  In all honesty from my prospective even if the problem was never solved and answers given were bogus I'm not out anything by just giving an A anyway.

I'm quite sorry if I've offended anyone.  I was merely trying to "play by the rules" as I understood them from the help information.  I must say this is the first time that I as a finacially supporting user to a service have felt attacked.  Vahik - I commend you for being so active in the Q&As and being so familiar with the platform.  I would just ask that you be a little more patient in working with someone new to the service that isn't as familiar with the rules of the road.  I assure you, my intentions were genuine.

Hello my client is also having this exact problem with an error randomly

Recipient address rejected: Access denied (state 14)

This is an exchange 2003 server and most emails are sent and received without problem.   Is there a relationship between only 1 MX record in DNS with a 0 value?  Should I recommend adding multiple MX records to the DNS to see if this helps?

nslookup non-authoritative answer:
 
myclientsdomain.com  mx preference = 0, mail exchanger = mail.mailroute.net
 
mail.mailroute.net   internet address = 199.89.0.202

                                              

1:
2:
3:
4:
5: