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
Community
  • 1
N10
  • 1
  • 5

2 Answers2

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?

James Shewey
  • 182
  • 14
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.

N10
  • 1
  • 5