5
Smartermail keeps failing over to A records when MX records exist
Problem reported by Kyle Leesman - 1/18/2018 at 1:08 PM
Resolved
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.com' 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 8.8.8.8, 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.

18 Replies

Reply to Thread
0
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
www.smartertools.com
0
Kyle Leesman Replied
Correct, I currently have the DNS settings on the TCP/IPv4 properties of the NIC set to 
8.8.8.8 (Google public DNS server)
209.244.0.3 (Level3 public DNS server)
3
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.

TIA.
0
robin.ng 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
0
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.
2
Richard Frank Replied
Matt, what are the DNS settings for in the SM interface?
0
Knud Westdorf Replied
Have the same issue, where we use the Google (8.8.8.8) DNS and CloudFlare (1.1.1.1). :/
1
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 8.8.8.8 and 9.9.9.9. 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.
0
Knud Westdorf Replied
Kyle - I have the samme issue. Changed the NIC DNS on Windows Server, and changed the SmarterMail DNS in controlpanel to 1.1.1.1 and 8.8.8.8.
0
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.
0
Knud Westdorf Replied
Any news on this? Keeps getting errors in maillog with PTR/A...  :( 

0
Martin Blanchette Replied
We are also experimenting this issue, we are now on Build 8629. I would expect this behavior to be fix since the last 5 years.

What is the official workarround to fix this problem ? 
1
Tim Uzzanti Replied
Employee Post
We have been dealing with unreliable DNS results in the older .NET Frameworks for a long time. This is often mitigated because DNS is designed to be fire and forget and requires retries regularly.  In most cases, you might see a failure in your logs but a follow-up attempt will work just fine.  

With our new .NET 7 release, which is in BETA since yesterday, has completely revamped DNS capabilities and delivers much better results and performance.  This is one of many reasons why we wanted to move to .NET 7.  We invite you to download the BETA and test it out.

Tim Uzzanti
CEO
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
2
Martin Blanchette Replied
Thank you for the quick reply.

Do you have an ETA on when this release will be considered stable and pushed out to the public? We don’t have a test environment set up for SmarterMail and don’t feel comfortable using a beta version in production.

Would having IPv6 disabled (or enabled) in the NIC interface cause any interference with the current DNS behavior? In theory, I don’t think it should, but I've come across some posts from Microsoft that seem to indicate that disabling IPv6 could lead to unexpected behavior.
1
fatih yıldırım Replied
We are experiencing the same DNS issue, and as a solution, installing the beta version is recommended. Who will be responsible for addressing potential major issues that may arise in the beta version? We urgently request the release of a mirror update related to the DNS issue.
1
Tim Uzzanti Replied
Employee Post
SmarterMail has been working around DNS issues since its first version, which are caused by the previous .NET Framework. However, SmarterTools has implemented various solutions for retries and timeouts that have minimized the impact on SmarterMail's performance. Keep in mind, SmarterMail processes millions of emails a day across an immense network of SmarterMail servers and gateways. 

We record every DNS failure, even though we have mechanisms to handle them so they are normally not an issue. This may cause some customers to worry about the results but we would rather log all information for obvious reasons. In regards to DNS requests with RBL or URIBL lists, many failures are caused by overloaded servers and why we update our default lists regularly.  The .NET 7 Framework improvements will improve the accuracy of a small fraction of those results as well.

For the BETA, I require the SmarterTools development team to participate in the community so that conversations and issues are resolved without delay. The issues related to the BETA are managed by the Development team directly and not through our Business Operations team which is our normal process.

Hope this information helps. 
Tim Uzzanti
CEO
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
This may be related or not, Sorry but I am really not sure. 
So, If it does not, let me know.

We are still using SmarterMail 14 and about to upgrade in a 2 weeks.
But I have noticed for quite a while (3 years) this issue where we are getting emails rejected or people are telling me they can not send to us.... saying the "NO MX records exist" or "no A record exists."  When I looked into this, it seemed that the issue we had was that its not the A records that was a problem, but the AAAA record does not exist. If I understand this, AAAA is IPv6 ?
What it looked like to me was that (mostly google) are trying to email us using IP6 looking for an AAAA record and no, that does not exist for us as our upstream simply does not offer IP6 addressing. Instead of them retrying on IP4, it simply fails to send.  Is this related ?

www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !

0
Douglas Foster Replied
Nor related, as the message means the sender never tried to connect to your server because it never found an address.  So your server is not the problem.

Any chance that someone tried to enable DNS SEC for your domain, but did it incorrectly?   That is the only scenario that I can imagine which fits your symptoms.

Reply to Thread