Smartermail keeps failing over to A records when MX records exist
Problem reported by Kyle Leesman - January 18 at 1:08 PM
I'm continuing to see a problem where we have clients report that valid emails are listed as "bounced" on our website after trying to send email to those addresses. I investigate the log files and in every case I find: "Failed to connect to the recipients mail server. No MX records were found for the '' domain. Failing over to A records."
However, in each case that domain in fact does have MX records published. In several of these cases we had successfully delivered mail to those domains via the MX less than 60 seconds earlier. The failover to the A records in these cases finds an IP that happens to be running a mail server, just not the right one, so it correctly returns a 550 No Such User error. Our system sees that bounce and we flag that address as bad in our database so we don't try to mail it again.
I assume the root cause is an intermittent DNS lookup failure and have attempted to switch to Google public DNS servers, but the problem persists. 
I don't believe that SmarterMail is receiving an "empty list of MX" records as specified in RFC 5321 as the basis for the A record failover, but rather is encountering some other error doing the DNS query. If that is the case the message should be queued for retry, not immediately failed over to the A record. 
Is there any way to enable logging of the DNS queries to really see what is happening?
Is it possible to disable the A record failover entirely so the server will use MX records or nothing?
Could somebody from SmarterMail explain to me how the DNS failover code works and the logic that would have to have happened for the A record failover to take place.

10 Replies

Reply to Thread
Matt Petty Replied
Employee Post
The behavior of the built-in .NET DNS Resolver, which is what SmarterMail internally uses for looking up DNS entries uses the DNS specified on the NIC, not the DNS specified in the server settings of SmarterMail.
Can you confirm that you've also set this as your DNS server for your network device?
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
Kyle Leesman Replied
Correct, I currently have the DNS settings on the TCP/IPv4 properties of the NIC set to (Google public DNS server) (Level3 public DNS server)
kevind Replied
Coincidentally, playing with DNS to try and speed up some RBLs, and found the comment above interesting.

You're saying SmarterMail uses the DNS specified on the NIC? Then wondering what the DNS entries in the server settings are used for.

0 Replied
I am facing the same issue with smartermail fail over to A records when DNS is sometimes intermittent. There should be a mechanism where it retries for a few query before failing over to A records immediately on 1 failed query. 
As in most case, we may not have our MX together with the web server. If it fails over to A records, it will fail delivery if my mail server is another server
Richard Frank Replied
It's not that Smartermail fails over the DNS records. It works like it should work. 
Use faster DNS servers or install a DNS on the server that works with root hints, or with fast forwarders.
Richard Frank Replied
Matt, what are the DNS settings for in the SM interface?
Knud Westdorf Replied
Have the same issue, where we use the Google ( DNS and CloudFlare ( :/
Kyle Leesman Replied
I still see this happening to us on occasion. My last attempt at fixing it was to specifically set the DNS server settings in Smartermail (Settings > General) Primary DNS IP and Secondary DNS IP. I used and However, spot checking I still see it happened again yesterday with one domain that should not have failed over. 

I still believe this behavior is being implemented incorrectly as the DNS MX query timing out is a different response than receiving a successful response with no MX records, but I was unable to convince Smartermail support that this was a problem.
Knud Westdorf Replied
Kyle - I have the samme issue. Changed the NIC DNS on Windows Server, and changed the SmarterMail DNS in controlpanel to and
echoDreamz Replied
I thought SM was moving to a different resolver than the sh***y one built-into .net. Maybe that is not happening until v17.


Reply to Thread