I run a Postfix/PostfixAdmin server at my-domain.info and forward some mail accounts to Gmail using SRS. I currently use several DNS-based blocklists in smtpd_relay_restrictions, including Spamhaus ZEN, SpamCop, Mailspike, relays.visi.com, and Spamhaus DBL checks for the sender, HELO, and reverse client name. Despite this, some obvious spam gets forwarded and Gmail rejects it with a 550 response citing the very low reputation of my server's IP address. The messages appear to come from legitimate-looking but disposable domains, so they are not always caught by the lists.
I understand that forwarding spam can damage the reputation of the forwarding server. I would prefer not to install SpamAssassin on this low-memory system because I am concerned about resource usage, configuration effort, and false positives. Are there reliable domain- or content-based blocklists I could add, or another lightweight approach that would improve filtering before messages are forwarded?
4 Answers
Forwarding mail directly to Gmail is often troublesome because Gmail evaluates the reputation of the forwarding server. Even correctly configured SRS does not make spam disappear; it mainly preserves the original sender for authentication and forwarding compatibility. Filtering the message before forwarding is therefore essential, and a separate outbound IP or domain for forwarding can help protect other mail.
Another option is to avoid SMTP forwarding altogether. Keep the mail on your server and let users retrieve it through IMAP or POP, or use a mail synchronization process that copies selected messages into Gmail. That way Gmail is not receiving every unwanted message from your server as an outbound SMTP delivery.
Make sure SPF, DKIM, and DMARC are configured and evaluated correctly, especially for forwarded mail. Authentication alone is not a spam filter, but failures and alignment problems can contribute to delivery and reputation issues. For automatic forwarding, DMARC handling and SRS need to work together; otherwise legitimate messages may be rejected as well.
That said, the error shown specifically points to the sending IP’s reputation, so authentication changes will not replace actual spam filtering. A hosted filtering service in front of the server is another practical choice if the machine is too constrained to run local content analysis.
The Gmail rejection is mainly a reputation problem, not proof that your RBL configuration failed. With SRS forwarding, your server becomes responsible for delivering every forwarded message, including spam that originally came from somewhere else. Google specifically recommends preventing spam from being forwarded and, where possible, using separate infrastructure for forwarding.
Before adding more lists, verify that the lists you already use are actually responding. Spamhaus queries generally should not be sent through public resolvers such as 1.1.1.1 or 8.8.8.8; they may return an error or no useful result for anonymous queries. Use a local recursive resolver such as Unbound and test the responses directly. Also, relays.visi.com appears to be defunct, and sbl.spamhaus.org is already included in zen.spamhaus.org, so those entries can be removed.
You already have a domain-based list: dbl.spamhaus.org. However, rhsbl checks normally inspect the envelope sender and HELO name. Many spam messages use a newly registered or otherwise clean sending domain while placing the malicious domains and URLs in the message body. Content inspection is needed for that, which is why a filter such as Rspamd can perform better than adding more static lists.
There is no blocklist that will reliably catch all spam. Static IP and domain data only covers known bad senders, while spammers constantly rotate addresses and domains. Combining reputation lists with message heuristics, URL checks, DKIM/SPF/DMARC validation, and some form of learning generally works much better.
Rspamd is worth considering as a lighter alternative to SpamAssassin. It supports DNS blocklists, content and URL inspection, and statistical rules, and it can be configured to reject only messages with very high confidence while leaving uncertain mail delivered or tagged. No system can guarantee zero false positives, so conservative thresholds and monitoring are important.
Forwarding authentication is more complicated than I expected. If local filtering remains too resource-intensive, keeping the mail locally and syncing only the needed messages may be safer than continuing to relay everything through Gmail.