We have a member of our staff who is attempting to send e-mail to a partner organization (domain barringtongroup.org) and is periodically receiving SMTP 5.5.0 bounce messages which indicate that our Exchange server is unable to relay. After a great deal of waiting for the intermittent problem to happen again with SMTP logging enabled, it has and it comes to light that the failed relay attempts are connecting to the wrong SMTP server.
It goes like this: the partner organization uses a web and email services company called Roar Solutions. The actual mail servers for the domain barringtongroup.org are listed in their MX records to be:
which appear to be part of a mail service provided by Rackspace. In every instance where we have successfully delivered mail to the barringtongroup.org domain, it's been to one of those hosts. However, the recently logged failure showed an SMTP session (and subsequent relay rejection) with the host 188.8.131.52. This machine is tin.niatech.ca, which is the primary nameserver listed in the SOA for barringtongroup.org.
It also happens to be, in addition to a nameserver:
a) the web server for barringtongroup.org
b) an SMTP server
which gels with the relay rejection when we try to deliver to the barringtongroup.org domain.
Anyway, three nameservers are listed in the SOA record for barringtongroup.org:
However, tiger.roarsolutions.com is not listed in the NS records at the parent server, and while the MX records for barringtongroup.org are present on the tiger NS, there are no A records for the aforementioned mx1 and mx2 hosts.
Now, I know that when an MX record can't be resolved for a domain successfully, Exchange will fall back on the A record for the domain. And, no surprise, the A record for barringtongroup.org is for 184.108.40.206.
Therefore, my thinking goes like this:
1) DNS resolves using tin.niatech.ca, graphite.niatech.ca, or another server with the appropriate MX and A records
2) SMTP connection is made to mx1 or mx2 and the mail goes through
1) DNS resolves using tiger.roarsolutions.com, which has the MX records but no A records for the MX hosts. This NS is authoritative, so MX lookup ultimately fails.
2) Exchange falls back to the A record for barringtongroup.org, 220.127.116.11.
3) 18.104.22.168 tells us to buzz off, given that we're trying to relay.
This is what I have put together from the evidence available to me and my (middling) knowledge of DNS. What I'm really looking for is a confirmation or denial of my suspicions from someone more knowledgeable about DNS than me, as the technical staff at Roar Solutions have flatly asserted that the problem is on our end and I can't agree with that assessment. I'm really looking to prove my case to them, more than anything else.