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?

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)

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

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.

Have the same issue, where we use the Google (8.8.8.8) DNS and CloudFlare (1.1.1.1). :/

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.

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.

I thought SM was moving to a different resolver than the sh***y one built-into .net. Maybe that is not happening until v17.

Any news on this? Keeps getting errors in maillog with PTR/A...  :( 

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 ? 

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.

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.

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.

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. 

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 ?

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.