These are things that I learned piecemeal, with multiple mistakes along the way.   DNS queries for spam filtering have different needs that DNS queries for interactive users. 

1) Fast DNS breaks Reputation block lists

You have probably been advised to point your internal DNS servers to Google (8.8.8.8) and Cloudflare (1.1.1.1) because these DNS services are faster than recursive resolution starting from a root hint server, and a little bit of speed multiplied by millions of queries can have a big impact.   Part of that speed benefit happens because these services use zone transfers to create local copies of most DNS data.   Reputation Block Lists work by connecting DNS to the services' proprietary reputation database, and this data does not get included in a zone transfer.   So if you route your RBL query to Google, you are likely to find no reputation data.    I first learned this on the SpamHaus website awhile back.  I just went there to find the link but could not find it today.

2) Safe DNS blocks reliable spam filtering

Safe DNS is based on the idea that if you prevent someone from resolving a dangerous name to a dangerous IP address, you prevent the user from going to that dangerous site.    Some implementations handle bad names by returning no data, so that a web user receives a "host not found" error.   Other implementations return a false IP address, so that they user receives a "this site has been blocked" landing page.    I am aware of Safe DNS implemented as a DNS server (Cloudflare 9.9.9.9) and as a firewall filter.   However, email filtering often performs DNS lookups to return an IP address so that the IP reputation can be checked.   Safe DNS undermines those checks.   The block-page version of safe DNS is likely the most harmful because the dangerous host is likely to be scored as safe.   The no-data version still provides less information than would be obtained from seeing the correct result.

3) Other missing data: DNS timeouts and DNS SEC failures

DNS Timeouts produce an uncertain result for spam filtering.   If, like most systems, you are configured to allow anything that does not produce an alarm, uncertainty is equivalent to pass.   I have collected DNS Timeouts from multiple sources:   My own filtering process, Authentication-Results headers that were created by intermediaries prior to arriving into my system, and DMARC aggregate report data provided by recipients of my messages.    I expected DNS timeouts to be rare, something like 1 in a billion, because I have never observed DNS timeouts interfering with web traffic.   But my email filtering data showed very different results.   Timeout errors are often in the range of 1 in a few hundred lookups!   I posted an items about "SPF Optimization" because my own timeouts were dramatically reduced or eliminated by reducing workload -- I stopped doing lookups for high-volume queries where the answer was already known.

DNS SEC is similar.  Instead of returning a TimeOut result, DNS SEC signature verification failures will return a server error, probably after attempting the query on all of your configured DNS server options.   My personal experience is that DNS SEC enforcement has occasionally blocked legitimate sites with DNS SEC configuration errors, but it has never detected a poisoned result, presumably because DNS poisoning is not as easy as some have feared.

I have tried to judge whether attackers can benefit from intentionally configuring their own DNS server to be unresponsive, causing timeouts, or incorrectly signed, causing DNS SEC errors.   I have not been able to support that hypothesis.   However, I have noticed that some spammy domains do produce timeouts every time, so I remain suspicious.   At minimum, consider how your design handles missing DNS results, and consider whether you are vulnerable to attack if missing data causes a malicious message to be allowed for lack of provable threat. 

Adapting to these issues

Fast DNS and Safe DNS are good defenses when applied to interactive users, and this includes people using webmail on your mail server.   But these tools are not appropriate for spam filtering.   So I recommend performing spam filtering on an inbound gateway, separate from your mail server, and have the inbound gateway pointed to a dedicated DNS server.  The dedicated DNS server will not use forwarding and will not be subject to DNS filtering.    Handling DNS SEC failures is a tougher call.   You need to consider whether your software can distinguish between "Server Error" and "No Data", and whether you want to handle those results differently.   At the moment, I slightly favor using a DNS server that ignores DNS SEC, because I hope that a poisoned result will be detected as a dangerous IP, while I expect that an unresolved name will produce no response.