Why does an IP address almost immediately get into the Composite Blocking List?

Question

Email

The server's IP address always ends up in the CBL.
CBL Lookup information IP Address 176.9.138.XXX is listed in the CBL. It appears to be infected with a spam sending trojan or proxy.
It was last detected at 2012-07-15 17:00 GMT (± 30 minutes), approximately 15 hours ago.
It has been relisted following a previous removal at 2012-07-15 10:57 GMT (21 hours, 21 minutes ago)
This IP is infected (or NATting for a computer that is infected) with a spam-sending infection. In other words, it's participating in a botnet. If you simply remove the listing without ensuring that the infection is removed (or the NAT secured), it will probably relist again.
Checked with antivirus - nothing.
All server domains are connected to GMail for the domain. Google has SPF records on all domains, on one of them it allowed sending emails from the server in the SPF record. (mail())
All domains have DKIM records.
All that the server sends is a letter when registering on the site (the server is allowed to send letters from this domain), in total no more than 50 people are registered and no more than 5 people are registered per week.
The SMTP port is open and the server is responding to requests.
Why does an IP address almost immediately get into the Composite Blocking List? How to find the cause and eliminate it?

Answer 1

I recommend using only GMail servers if you are already working through them ... I.e. so that your site sends notifications not as a server, but as a client, communicating via smts and imaps (if necessary) with gmail.

Answer 2

And in the logs of the mailer, too, only 5 letters a week?
Maybe they send you letters with a fake sender address and your mailer rejects them and sends them back (now to the addressee of the spam mailing).
Or a perl script hangs in processes that are busy with mailing (it can still run ssmtp or sendmail for itself), usually its letters are visible in /var/log/maillog and the queue of letters is huge for sending.
Although, perhaps, checks on openrelay would have revealed this.

Answer 3

and what answers on the 25th port is correctly configured? how is openrelay not working?

Answer 4

We had a case where a server (located on AWS) was blacklisted due to the fact that the name in HELO did not match the name received during reverse IP resolution. It was decided after prescribing the correct name for ip.