I'm posting this a suggestion rather than a problem as I have a sneaking suspicion that despite the way it is described in the Help that the Reverse DNS Spam Check is somehow "Working As Intended" when in reality it almost useless as implemented.

Forward Confirm Fail and Forward Confirm Mismatch spam settings should be concerned with the HELO/EHLO address that is provided by the connecting SMTP server. An Host A lookup should be done on the HELO/EHLO address to get an IP adddress. That IP Address from the Host A lookup should match the IP address the SMTP server is connecting with otherwise it should FAIL. A PTR query for that IP Address should come up with a rDNS record that should match the HELO/EHLO provided otherwise it should FAIL. The rDNS value should then have a Host A record that matches the IP address the SMTP server is connecting with otherwise it should FAIL.

What is happening in reality is that the SMTP server gives a HELO/EHLO. Smartermail is then looking up the IP Address from the Host A record for that HELO/EHLO and then the PTR record and the Host A record for the results given. It is matching just the IP Address and not the HELO/EHLO and the domain in rDNS. It is never attempting to match the results of the PTR record in rDNS with the HELO/EHLO and providing a FAIL when they mismatch. (NOTE: This is a separate issue from the HELO/EHLO resolving with a CNAME instead of a Host A record.)

The vast majority of Spam has a mismatching HELO/EHLO from the PTR record. For some examples:

In all of these examples, the HELO/EHLO matches the IP address from a Host A lookup and the results of the Host A record from the results of the PTR lookup rDNS record match IP addresses so SmarterMail gives them a PASS, when in reality they are two different Host names that mismatch and should FAIL.

Although the way SmarterMail is currently doing a FCrDNS may be technically correct, it doesn't address the real reason why FCrDNS should be performed to be effective against Spam. Most ASNs have something populating their PTR records in rDNS that will almost always match a Host A record, i.e. Google Cloud or AWS (such as 226.187.91.34.bc.googleusercontent.com or ec2-44-225-173-64.us-west-2.compute.amazonaws.com). However, running a SMTP Server at those services you may have a Host A record that resolves to that IP but your HELO/EHLO will not necessarily match the Host name in the PTR record for that IP unless you are running a SMTP service authorized by that Hosting Provider who has modified their PTR record to match your STMP server's HELO/EHLO. Which is precisely why matching the results of the PTR record and the HELO/EHLO are critical in fighting Spam (a.k.a. those pesky AAA, 0maha Steaks, Keurig, BlueCross, and Marriott & Hilton Hotel spam everyone here on the Community Forums often complain about).

Would it be too much to ask that there be an option in the Reverse DNS Spam Check to match the HELO/EHLO to the PTR with a Weight so that it can actually catch the majority of Spam and therefore live up to it's potential as a truly useful Spam Check?