Do you have any gateways that handle incoming mail before it reaches your server? You may need to add that server's IP address to the Settings>Antispam>IP Bypasses list to ensure we're skipping that IP and looking to the previous one for our spam checks.

Good day Kyle,

No Incoming gateway, the mail server is connected directly to the public IP and no firewall filtering that server either.

And no IPs bypassed that shouldn't be? Beyond that I would suspect a DNS lookup failure or incorrect value. You can try disabling DNS caching (Settings>Protocols>SMTP Out) and changing your primary/secondary DNS to something like 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google) directly, then do a restart of the server for good measure. If that doesn't help we'll probably need to look into the logs some more. 

Good day Kyle,

Alright I did that, I will update this post if it helped or not. I did have DNS caching on and I changed the DNS entries along with restarting the Smartermail service. Thank you for the suggestions.

Sounds good thanks, and you're very welcome!

Good day Kyle,

Just to update this thread, checking our delivery logs for the past few hours look a lot better now. SPF failure lookups seemed to have gone away, my initial guess here is the DNS caching being on was the culprit, but updating the DNS surely doesn't hurt. If I run into another issue with this I will report back on it. Thanks again for the assistance, it's much appreciated.

We also saw repeated failures of Google's DNS servers today both IPv4 and IPv6 -- so switching to CloudFlare has resolved the issue --

Does Smartermail need  ipv6 dns servers?

Good day,

Ok, maybe I spoke too soon, while there is not as many SPF and reverseDNS lookup failures, it appears they are still happening enough that my clients are still reporting the issue.

I am seeing this in my delivery logs this morning (I bolded the problem areas):

[2023.09.14] 11:56:30.560 [55637201] Spam Check results: [_DMARC: 0,none], [REVERSE DNS LOOKUP: 10,ReverseFailed], [NULL SENDER: 0,passed], [_SPF: 30,Fail], [_DKIM: 0,None], [ZERO SPAM: 0], [PSBL: 0], [SORBS-NEW: 0], [SPAMCOP: 0], [SEM - BLACKLIST: 0], [IADB: 0], [VIRUS RBL - MSRBL: 0], [BARRACUDA - RBL: 0], [UBL: 0], [VIRBL: 0], [SENDERSCORE: 0], [GBUDB: 0], [ABUSEAT - CBL: 0], [MAILSPIKE-H1, MAILSPIKE-H2, MAILSPIKE-H3, MAILSPIKE-H4, MAILSPIKE-H5, MAILSPIKE-L1, MAILSPIKE-L2, MAILSPIKE-L3, MAILSPIKE-L4, MAILSPIKE-L5: 0], [SORBS-DUL: 0], [UCEPROTECT LEVEL 2: 0], [SORBS-RECENT: 0], [SEM-BL: 0], [LASHBACK: 0], [UCEPROTECT LEVEL 1: 0], [BACKSCATTER: 0], [HOSTKARMA - BLACKLIST: 0], [RFC2 REALTIME LIST: 0], [BONDEDSENDER: 0], [NOABUSE: 0], [SPAMRATS: 0], [SORBS-NOMAIL: 0], [SEM-BS: 0], [IX: 0], [MSRBL: 0], [SURRIEL: 0], [SPAMHAUS - ZEN: 0], [WPBL - RBL: 0], [UCEPROTECT LEVEL 3: 0], [SEM - BACKSCATTER: 0], [NOPOSTMASTER: 0], [HOSTKARMA - YELLOW: 0], [MCAFFEE: 0]

[2023.09.14] 11:56:30.560 [55637201] Spam Checks completed.

This email was from a client that my customer has been doing business with for years, HarmonyCastings.com

I performed a SPF lookup on MXToolbox and they have a valid SPF record specified. Looking at the header information harmoncastings is using Office365 for their email provider. I can see the ReverseDNS failing if it's expecting to see the client's name attached to it, but the SPF should not have failed at all but yet it still is.

This is part of the header from the email that SmarterMail claimed the SPF failed:

ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass

 smtp.mailfrom=harmonycastings.com; dmarc=pass action=none

 header.from=harmonycastings.com; dkim=pass header.d=harmonycastings.com;

 arc=none

As you can see clearly right there SPF passed, but yet SmarterMail has it in our delivery logs as SPF failing? 

It does appear the client has a cross tenant on Office 365, I see this in the header as well:

X-MS-Exchange-CrossTenant-AuthSource: DM4PR01MB7881.prod.exchangelabs.com

So is this a case where Smartermail is only looking at the last section of information? I am at a loss here as to why the SPF failed. Any ideas? Do I have to open a ticket for this?

I am at the point to either shutoff SPF checks (which I really do not want to do) or score it really low at least until I can get some resolution on this. Please let me know.

Hey Jay, 

I've been doing some testing on my end. One thing that I would like you to try is to set both the primary and secondary DNS servers to the same IP. So for example Go to Settings->General then set the primary and secondary to 1.1.1.1 

Let me know if that resolves the issue and if so we will go from there. 

Thanks, 

Good day Zach,

I made the change and I will report back my findings. Thank you.

Hey Jay, 

Did the change make any difference?

Thanks, 

Good day Zach,

No unfortunately I am still having the same issues, I lowered the scoring on both ReverseDNS and SPF lookups so everything did not get sent to spam immediately. A lot of  the client complaints I have been receiving are emails that are on the Trusted Senders list for their respective domains.  I am also finding that DMARC lookups are failing as well even though there's a valid record posted online according to MXToolbox. I found several of these in the past few days. Is Smartermail also using the DNS server settings on the Windows server as well? I did not change those, I only changed the DNS setting in the SmarterMail interface itself.

Hey Jay, 

Can you please open a ticket? I have a script that intercepts the DNS requests from the server side. This will allow us to see what the DNS server is returning to SmarterMail and what requests SmarterMail is sending from outside of the application. What we can do is set up a screen share and set up this script then we can go from there. 

Thanks, 

Good day Zach,

I will open a ticket tomorrow for this, that way we are not under a time crunch today. I appreciate it.

Im seeing the following, maybe related.

For reasons unknown to me the following is occuring sporadically

Using MXToolbox test
smtp     mail.xxxxx.com     Reverse DNS does not match SMTP Banner     information More Info
smtp     mail.xxxxx.com     Warning - Does not support TLS.     information More Info
smtp     mail.xxxxx.com     May be an open relay.             information More Info

Then after several minutes the tests will pass (as they should), then after a certain period of time, the tests would fail.

To make things more perplexing, incoming emails are also being bounced due to the having "Enable Inbound SMTP Blocking" enabled for Reverse DNS.

Any tests I run from a command line interface shows the reverse smtp banner being reported as it should be.

Ive checked all relevant settings with regards to the reverse smtp banner, at the ISP, in Smartemal CP, in Plesk CP and all is as expected.

Currently using OVH DNS servers as the server is leased from OVH.

I am completely perplexed.

Currently running AV scanning tools on the server ....

Hey Steve :-) Do you by chance have any security software set up on this server or a firewall in front of it that might proxy SMTP communication? The intermittent nature of this leads me to believe MXToolbox.com is testing a different MX/IP address sometimes or they're reaching something else on your end intermittently. Let us know what you find out!

Hi Kyle, no, there is no additional security software on the server. Re firewall, its a self managed OVH server. I did not setup anything to proxy SMTP communications.

To be clear, its not just the reporting from MXToolbox, emails are also being bounced due to whatever is causing the issue.

I will repond via the last ticket I had open with you, as this stuff may have started happening after the upgrade to the version that first implemented different method of handling DMARC

Hello

Jay Altemoos, did you manage to solve your problem?

I'm also having random problems with with DNS queries and the symptoms are:
- delays in Spam Check (due to dns queries timeout)
- no ReverseDNS or SPF check (due to dns query timeout)

This only happens with the most recent builds (including Build 8664). We use the same DNS server and the same RBLs on all servers regardless of the build and this does not happen on any server with build 8251 (Aug 4, 2022).

I also had to lower the scoring on both ReverseDNS and SPF or messages were blocked in SMTP.

I would downgrade if it were feasible, but SmarterTools support indicates that "any downgrade lower then Build 8495 (Apr 5, 2023) will have issues do to the amount of changes that took place for this release".

Hi

same issues here we use 1.1.1.1 and 8.8.8.8 and had to lower spf in 15.7 it worked perfect.

sounds like we should turn off "ReverseDNS" look up tests until this is resolved ??
I also noted that very often MXToolbox informs me that SMTP connection time is slow (sometime up to 15 seconds and more), so I refresh the test a few times, sometime it comes back as slow other times OK ....

But there is a very strong reason not to use any of these DNS: many RBLs block known public servers.
The ideal is to use one of yours (if you have one that performs recursive queries) or one of your hosting provider.

Steve,

A legitimate mail server must have an IP with ReverseDNS configured. ReverseDNS and SPF are essential in combating Spam and not being able to effectively use either of them because SmarterMail's DNS client randomly gives timeouts is very worrying.

Slow SMTP connection is not necessarily a problem. I prefer to have an SMTP connection considered "slow" for the MX Toolbox and consult more than 40 RBLs (each with its own weight according to its effectiveness) to block Spam at the SMTP level and reduce the load on the server and the Spam that my clients receive than to be "fast" and ineffective.

I also think it may depend on the MX Toolbox connection to your server. Servers geographically closer to MX Toolbox datacenter will benefit from this test. It's worth what it's worth.

@Duarte
Yes, disabling ReverseDNS is far far far away from being OK. But I need a temporary solution for all the bounced emails from people who are contacting my customers.

Re slow transaction response, its the inconsistency more than anything. I.e. from 15+ seconds to no delay etc

Hi Duarte,

No the issue is not resolved. ST Support found an issue and have escalated it to development to fix and will let me know when a patch is released. No ETA on that yet.

What I did for now to calm down the amount of good emails going to spam is lowering the scores for both SPF and ReverseDNS. I did not feel comfortable shutting off those checks, so lowering the scores was the next decision in line. That has at least calmed down the amount that was going to junk email. I also uncovered the fact that several RBL checks are also coming back false positive as well. I verified this via checking not only MXtoolbox but also on the RBL itself. Each time I checked, the domain in question and the sending server were not listed on the RBL that Smartermail scored it as being listed on.

My first guess here is for whatever reason SmarterMail is slow at getting the response back and just classifies the failure even though it may not have been. Hopefully there's a fix on the horizon.

In SmarterMail settings -> General -> Server Info
put the same IP in the Primary DNS IP and in the Secondary DNS.

After a few hours I already have an average time of the RBLs identical to the servers in the old build.

Unfortunately for me, I have 1.1.1.1 in both primary and secondary DNS settings in Smartermail. What I did in the meantime is disable the ones where the Average time was 9000ms and above. Since I have done that the false positive scoring has calmed down there as well.

Thank you for the information also.

where can you check the duration of the query in sm? i know i can check it in windows 

cheers 

It appears that the new BETA version resolves this issue because a new DNS client is used.

Unfortunately, it is out of the question to upgrade production servers to a BETA version and it looks like we will have to wait for the new version to mature :(