If you tick the any of the DNS Verification options in a Sender Group then all mail failing the checked tests gets handled by that group, regardless of the practical reputation of the IP in question. The logical choice of the existing groups is the BLACKLIST, which means that offending mails will get dropped before much has been logged about them. Problems will be difficult to diagnose. As Ken points out, many genuine organisations think it quite acceptable to send from any old IP, and some may say "yes, the IP has no PTR but we've published a perfectly good SPF mechanism so we're covered". Message Tracking with the Advanced parameter Sender IP/Domain/Network Owner set to "*unknown domain" may give you some insight into the extent of the problem in your own inflow, though particularly awkward cases may occur at a low frequency, e.g. financial engines that send once a month.
If you have begun to use Message Filters then I recommend a new Sender Group directly beneath the BLACKLIST and not associated with any particular SBRS range. Mail Flow Policy throttling can be whatever you feel is appropriate given the remainder of the solution. Your message filter is then:
rDNS-check:
if (sendergroup == 'NAMELESSLIST') {
add-heading('No-rDNS-warning');
if (spf-status == 'pass') {
insert-header('X-rDNS', 'No PTR, SPF Pass');
}
else {
if (spf-status == 'fail, permerror, temperror') {
strip-header('Subject');
insert-header('Subject', '[NO rDNS] $Subject');
insert-header('X-org-Bad-rDNS', 'No PTR, bad SPF');
}
else {
if (no-reputation) {
strip-header('Subject');
insert-header('Subject', '[NO rDNS] $Subject');
insert-header('X-org-Bad-rDNS', 'No PTR, no SPF, no SBRS');
}
else {
if (reputation < 2.0) {
strip-header('Subject');
insert-header('Subject', '[NO rDNS] $Subject');
insert-header('X-org-Bad-rDNS', 'No PTR, no SPF, SBRS $reputation');
}
else {
insert-header('X-rDNS', 'No PTR, no SPF, SBRS $reputation');
}
}
}
}
}
.
This filter requires a Disclaimer Template text resource that adds a warning at the top of the message advising the recipient in plain English that the mail is questionable. If that's not appropriate to your domain or too much trouble to arrange, the entire add-header line can be omitted. If you have multiple listeners then you may need a further condition around the filter, though there are many examples of that in the Asyncos user guide.
My choice of reputation [SBRS] less than 2 is also arbitrary, based on my own inflow and you may want a higher or lower number. I've also been unsympathetic to senders with ramshackle DNS records, though the entire logic of the filter would need to be rearranged in order to count TEMPERROR as no SPF. Be wary if your own upstream DNS resolver is weak.
Mail leaving this filter will have either an X-rDNS or an X-org-Bad-rDNS header. You can then write Content Rules to act on the headers to quarantine or send to End User Quarantine, or arrange to have a downstream system (e.g. an Exchange Transport Rule) react to the presence or value of a header. The headers I'm writing in the filter are intentionally descriptive to help diagnose what is wrong with a mail.
I've outlined several areas where the filter or the general principle of DNS Verification might go wrong. One advantage of the above technique is that you can begin by taking only very moderate action, then step this up as you tune the solution to your inflow.
