0

My client is having intermittent problems sending email to a few customers. It has really only happened in the last five days and so far only to six different messages but they all have the same differences between a working and failed delivery.

In the screenshot below, the difference between a working and failed delivery is the Server IP/Hostname that it attempts to deliver to. I chose this recipient since their domain is generic. In other attempts with tens of messages per week it looks very similar.

For some reason Exchange Server obtains the IP for the domain of the recipient account instead of using the address from the MX record. (ie. mindspring.com instead of mx3.mindspring.com)

My client is running Small Business Server 2011 Standard w/ Exchange 2010. The rest of their ~200 messages a day send just fine.

[ScreenShot][1] (Can't attach images yet) (enlarge)

My research so far:

  1. microsoft exchange not using mx record
  2. microsoft exchange random recipient ip changes
  3. exchange sending to A record
    1. Possibly relevant: link
  4. exchange sending to wrong mx
    1. Same situation but from the other side: link
    2. Same situation, no resolution: link
6
  • For some reason Exchange Server obtains the IP for the domain of the recipient account instead of using the address from the MX record - I don't understand that statement.
    – joeqwerty
    Mar 12, 2015 at 5:56
  • The MX record for mindspring.com is mx1.mindspring.com but instead decides to use mindspring.com which should not be handling this mail and results in the error I'm receiving.
    – N10
    Mar 12, 2015 at 5:57
  • Gotcha. I didn't understand what you were saying. It's using the A record for the domain instead of the MX record. That's a valid behavior if no MX record can be found. Have you tried running nslookup for the MX record from the Exchange server? How about using SMTPDiag from the Exchange server?
    – joeqwerty
    Mar 12, 2015 at 14:25
  • The problem is intermittent, by the time i get the report everything checks out. Emails also go through later on. I did not know about it failing back to the A record though.
    – N10
    Mar 12, 2015 at 15:24
  • Yep. Per the relevant RFC's, in the absence of an MX record, fallback to the A record. This might be an opportunity to check your DNS setup. Are you using forwarders? If so, the problem may lie there.
    – joeqwerty
    Mar 12, 2015 at 15:25

2 Answers 2

0

Well, if I try to telnet mindspring.com:25, I am unable to connect, so I suspect that ServerHostname is a red herring. Clearly you are getting connected to a mail server, but it is requiring that you authenticate in order to use port 25. The 550 error you are getting is either because SMTP auth is turned on on the server you have connected to, or because they are trying to force TLS.

If you go to the command line on that server and type:

nslookup
set type=mx
mindspring.com

what do you get back? Does everything check out? Do you get the same answer if you do

nslookup
server 8.8.8.8
set type=mx
mindspring.com

Or do you work for mindspring and this is all internal?

3
  • I get mx1 mx2 mx3 and mx4.mindspring.com for the MX record. I am able to telnet into mindspring.com:25 (207.69.186.21:25) and see a ESMTP mail service ready banner. No parameters have changed on my side and the message will send successfully after a few hours.
    – N10
    Mar 12, 2015 at 4:24
  • Remember that a lot of email can get connected to many ports other than 25.
    – mdpc
    Mar 12, 2015 at 7:20
  • But how would it announce to other servers that it is receiving on something else? And why would a major service use a non standard port?
    – N10
    Mar 13, 2015 at 20:15
0

TL;DR: One of the two ISP's we are using blocks DNS requests from outside their network. DNS requests were occasionally coming from the other ISP's network...

The fix: Implement a static route at the firewall for ISP DNS servers to use a specific interface, or use another service (like OpenDNS or Google DNS).

The story: Well we found out what the problem was. The exchange server was functioning mostly as we expected. We have a dual WAN connection that the firewall fails over to if the primary goes out. So on the domain controller we added DNS servers for both of our ISP's to be queried (along with OpenDNS as a tertiary option). We will have to do some more research on this particular procedure, but we found that Exchange wasn't querying the first server (our primary WAN connection) all the time.

It seemed to cycle between all of the options all the time. This worked without a problem until our secondary ISP changed settings on their DNS servers to refuse connections from IP's outside of their network. A packet capture revealed this response which eventually brought us to our conclusion. When Exchange received the refused response it fellback to just querying the A record and attempted to make a connection using that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .