Senderbase Poor Reputation Help
Hi,
Long time cPanel user (and love it) but never had any need for help before. Got a problem with senderbase email reputation that is causing a number of ISPs to reject mail that I cannot seem to resolve and can't believe I'm the only person with a setup like this so hopefully someone can help me.
Background - I operate two servers, both hosting a number of legitimate domains. All domains are set up as local email exchangers. All are set to "Use the nameservers specified at the Domain"s Registrar" and all have SPF records set up and verified.
In terms of PTR records, those are set to the hostnames of the servers which is not any of the domain names hosted on the servers. Mail server settings tools e.g. mxtoolbox.com indicate all is fine with config, though the senderbase check page sometimes says "Fwd/Rev DNS Match" equals yes and sometimes it says no - which is just adding to the confusion.
I have contacted Senderbase who said:
"The IP's currently have a poor SenderBase reputation because you are sending mail through generic ISP pool addresses which should not be hosting a mailserver. Mailservers sending mail through generic ISP pool addresses are indicative behaviors of systems which have been spambot compromised and are considered a high risk for spam and malware infection.
The best way to resolve this would be to change the PTR/ rDNS of the IP's to the match the domain being used to send out mail. So that the senderdomain can be verified (authenticated SMTP) in relation to the rDNS match for the IP's."
I do have access to set the PTR records on the servers via my hosting providers control panel, but can only set one PTR record per IP. I have read it's not considered best practice to have multiple PTR records for an IP anyway.
There *must* be other cPanel users out there who are set up the same so any ideas/solutions to this would be gratefully appreciated as it's causing real problems. :(
Cheers
Andy
-
Thanks for the reply, but I really need to get to the underlying cause of the problem or any new IP address is just likely to end up with a "poor reputation" again, putting me back at square one. Funny thing is, I just tried to follow-up with senderbase support as this problem has only occured since I migrated to new servers and new IP addresses in December. Everything before was identical so I'm wondering if these IPs have historical spamming reputations, but lo and behold my email to them was bounced because of "poor reputation". You couldn't make this stuff up... 0 -
Everything before was identical so I'm wondering if these IPs have historical spamming reputations
This is what I suspected. It might be worth adding a new IP address and using it for sending just to rule that out as the cause of the problem. Thank you.0 -
Senderbase have come back saying "Using generic ISP strings can be suspicious. The cure would not to add additional PTRs (that will not help at all) but to use a more specific HELO like mailserver.domain.tld (well, and then have the PTR match that obviously)." How can you have a HELO of mailserver.domain.tld and have the PTR record match when you have multiple domains on the server without having multiple PTRs? There must be thousands of people out there hosting multiple sites/domains on a single server who also use those servers for email so I can't understand why I'm having these problems. It's taken god knows how long so far and I'm getting absolutely nowhere. :( 0 -
Right, the standard behavior is to setup RDNS for the hostname of the server. My advice is to try adding a new IP address and using it for sending just to see if it makes a difference. Thank you. 0 -
Just want to (hopefully!) close this off in case it's of help to anyone else in the future. I eventually found out it's not down to IP address, it's down to server hostname and, in particular reverse DNS. Senderbase now flag any server that has a non-unique generic ISP name as "poor" by default. They require a unique domain name per server for reverse DNS so, for example if you have server1.isp-provider.com and someone else has server2.isp-provider.com that is bad in their eyes as reverse DNS for both servers point to the same domain name. A point to note is that even if reverse DNS is correctly set up using the default hostname/server name, they will flag on their reputation page that forward/reverse DNS do NOT match. It's very confusing as every other test utility out there will indicate all is fine. To get round it, pick the domain name of one of the sites hosted on the server (doesn't matter which as long as it's unique) and set reverse DNS to that domain name. An hour after making the change Senderbase showed reputation on both servers as "neutral" from "poor". I also had to change /etc/mailhelo to reflect the change. It was set to use default ISP provided hostname and has been changed to mail..com - bounce EXIM after making this change. One other thing cropped up though - after a reboot (for reasons not related) I could not send or receive mail. Transpired that the rules for POP3, IMAP and SMTP within iptables were only configured for the default ISP provided hostname. I had to add new iptables rules for mail..com (even though the original hostname is still the overall hostname for the server). I have no idea why this is - whether iptables uses reverse DNS in some way or not, I just know doing that fixed it. Rules need to be added to /etc/sysconfig/iptables to be permanent and re-applied after reboot. Now, four days after making the change, reputation on one server is showing as "good", the other is showing as "neutral" and the delayed/queued mail on both servers has cleared. It was a LOT of investigation/work and Senderbase support are useless, but all appears to now be working as it should. I thought I might have to change SPF records for all hosted domains to say that mail..com was a valid sender, but so far that doesn't seem to be neccessary. Am continuing to monitor. 0 -
I am happy to see you were able to address the issue. Thank you for updating us with the outcome. 0
Please sign in to leave a comment.
Comments
7 comments