This probably should be a wiki, not entirely sure. Before I begin, the external server that performs scanning is a custom amavis/postfix/fortigate pipeline; it is suggested that any changes work within that environment.
I have enabled reverse lookup rejection for my work's email server, to reduce the inflow of spam being received by management. Yes, this was a management request, no pointy hair jokes please. In this regard, it is very effective, reducing the workload for our scanners by about a factor of 2 or 3. Turning it off is tantamount to professional suicide; please do not suggest abandoning it as a solution.
The problem is rather simple: lots of legitimate senders, either as vendors or customers, outsource or minimally set up their email services. The service providers are looking to turn a buck on the thinnest, smallest provisions possible, so they really don't give two hoots about getting their services fully compliant. That, or the customer/vendor has never heard of reverse lookup and can't be bothered to fix their DNS zone (or in some cases, they don't even control their DNS, which is a topic for another day). This is really a simple fix, they just need to create a reverse lookup record that matches the connecting IP address. It doesn't matter that the hostname or domain name of the server do not match the sender's domain, it only matters that the lookup for the server completes a "round trip" from IP->name->IP.
I don't have all day to chase every single one down and make a phone call, and frankly some of them won't take kindly to being pestered over the phone. But the number of broken servers out there is astounding, and not a month goes by that the "special exception reverse-lookup bypass list" grows with a few new IP addresses.
So the question is what is the best way to notify legitimate senders that their email is basically broken and needs to be fixed, without entirely cheesing them off? Is there some way to automatically notify them, so they get the information they need instead of the bland reject message that they will never bother to read? (I guarantee that 99% of the customers and vendors are non-technical and simply see it as "well it's your email server that's broken")
After some further discussion in chat, I went back to review the configuration file in use, and I think I've found a part of my grief. The following option is being used:
According to that page, this option has strict requirements, and so I presume as a result, it causes some false positives.