Page 1 of 1

check_reverse_dns_list rule questions

Posted: Tue Aug 06, 2013 5:08 pm
by widomaker

I'm looking for additional details or a better description of what this rule is (check_reverse_dns_list).

Is it a more forgiving version of check_dynamic_reverse_dns that only matches very specific patterns instead of all generic reverse DNS?

Can you provide an example of a pattern that it is intended to catch? Do you know how likely false positives are with this rule?

We are finding that a large number of mail servers that communicate with our customers have generic reverse DNS. While we can exclude our customers that complain, I'd like to avoid them having to complain in the first place, if possible, by using a more forgiving rule.

Any thoughts or suggestions are welcome.


Re: check_reverse_dns_list rule questions

Posted: Wed Aug 07, 2013 10:12 am
by magicspam
Hello widomaker!

check_reverse_dns_list is a compiled list of patterns for servers that have leaked spam. Qualification is that the source has been reported to have sent spam (human reports) and that multiple source patterns of the same or similar PTR records exist. Challenges to listings can be made at: ... amic_regex

with link 'Challenge an Entry'

This is of course different than check_dynamic_reverse_dns because, as you pointed out, this rule simply hits on IP addresses with dynamic style PTR records.

We hope this answers your question widomaker!

-- MagicSpam Support Team --

Re: check_reverse_dns_list rule questions

Posted: Wed Aug 14, 2013 11:07 am
by widomaker
So, in your opinion, or estimation, would you consider this rule (check_reverse_dns_list) to be less likely to have false positives than the check_dynamic_reverse_dns rule that blocks any dynamic looking reverse DNS (which is quite common for non-spam senders)?

I'm looking for an alternative to check_dynamic_reverse_dns (which blocks lots of spam but also blocks too many legit senders).

Thanks for your time and thoughts.


Re: check_reverse_dns_list rule questions

Posted: Wed Aug 14, 2013 4:02 pm
by magicspam
Hello Widomaker,

Thank you for your response!

The important thing to take away in this case is that *neither* of these rules have "false positives".

-- check_reverse_dns_list is vetted and compiled by human reports. Nothing is automatic and removal is self-serve.

-- check_dynamic_reverse_dns is simply a piece of logic which tests if a PTR record is dynamic or not.

If legitimate postmasters in your geographical region do not follow email server best practices there may be more cases where they trigger the check_dynamic_reverse_dns rule. It is up to you, as the postmaster of your mail server, whether or not you want to allow messages from mail servers with improperly configured PTR records - taking into consideration the large amount of spam that comes from mail servers with improperly configured PTR records.
You might also consider contacting the postmasters at the sending servers and informing them of the best practices and why it would behoove them to follow these. You may use the following URL for more information: ... e_dns.html


-- MagicSpam Support Team --

Re: check_reverse_dns_list rule questions

Posted: Mon Aug 19, 2013 3:10 pm
by DavidMiller
I am not sure what is causing the issue. The email appears to be coming from a Yahoo server of sorts. This is a legitimate email.

How do I know what is the issue based upon the following response;

-----Original Message-----
From: []
Sent: Sunday, August 18, 2013 11:54 PM
Subject: Failure Notice

Sorry, we were unable to deliver your message to the following address.

Remote host said: 550 Dynamic Style reverse DNS IP=[].Rejected by MagicSpam 1.0.5-3.4 (xxxx://www .magicspam .com/).Visit xxxx://www . linuxmagic . com/best_practices/check_dynamic_reverse_dns.html for more information [RCPT_TO]

--- Below this line is a copy of the message.

Received: from [] by nm13. access. bullet. mail. gq1. yahoo. com with NNFMP; 19 Aug 2013 03:53:08 -0000
Received: from [] by tm2. access. bullet .mail. gq1. yahoo .com with NNFMP; 19 Aug 2013 03:53:08 -0000
Received: from [] by smtp104. sbc. mail. gq1. yahoo. com with NNFMP; 19 Aug 2013 03:53:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1376884388;

Re: check_reverse_dns_list rule questions

Posted: Tue Aug 20, 2013 9:59 am
by magicspam
Hello David,

Thank you for your post. If you could, please forward, as an attachment, the entire message you received to our support email address so that we can examine this further. Forwarding as an attachment is important so that headers are preserved.

Our support email address is


-- MagicSpam Support Team --

check_reverse_dns_list rule questions

Posted: Sun Nov 26, 2017 1:41 am
by leon-Pi
I notice, in the new version, that the single check_dynamic_reverse_dns rule has been replaced by two rules:
check_dynamic_reverse_dns FULL
check_dynamic_reverse_dns_default COMMON

What are the differences in these new rules? I had to disable the previous check_dynamic_reverse_dns rule due to too many poorly set up email servers affecting our customers mail delivery. Im curious if the the rule spit would make it possible to re-apply some of the dynamic reverse dns protections.


Re: check_reverse_dns_list rule questions

Posted: Tue Nov 28, 2017 6:11 pm
by magicspam
Hello leon-Pi,

Thank you for your post.

check_dynamic_reverse_dns_default COMMON uses the single REGEX for determining if the the message should be rejected based on the reverse DNS, while check_dynamic_reverse_dns FULL uses our own list of probable dynamic reverse DNS entries, which is regularly updated in your MagicSpam.

We would suggest you to enable the check_dynamic_reverse_dns in your MagicSpam and check if the spam protection for your server is improved.

Please note that MagicSpam PLUS and PRO versions, available only for certain platforms, offer the 'FLAG' feature, which allows you to enable certain policies in the 'FLAG' mode. 'FLAG' mode allow messages only to be flagged as spam and delivered to the customers quarantine, where they can be analyzed and excluded if needed, instead of being rejected right away.

With this advanced feature, you should be able to test any policy without fear that any false positive messages would be rejected.

We hope this information helps.