Relaying outbound mail through MailBaby means a share of your inbound traffic now comes from MailBaby’s network: bounce messages for undeliverable mail, rejected rSPAM messages returned to the sender, and SRS bounces for forwarded mail. If your server greylists, rate-limits or spam-scores those connections, customers see delayed or missing bounces and your support team loses the information those messages carry. Three settings on a cPanel server need adjusting. The same principles apply on DirectAdmin with CSF and SpamAssassin or Rspamd.
Table of Contents
Short answer: Add MailBaby’s return range, currently published as 162.220.160.0/28, as a trusted host in cPanel greylisting with whmapi1 create_cpgreylist_trusted_host, allow it through CSF with csf -a, and list it under trusted_networks and internal_networks in SpamAssassin’s local.cf. Confirm the range against the InterServer portal before applying it, and test by forcing a bounce and watching it arrive without a greylisting delay.
Identify the range
MailBaby’s return traffic originates from InterServer address space. The range published in the vendor’s cPanel example is 162.220.160.0/28. Confirm it against the current documentation in the InterServer portal before whitelisting, and re-check after any announcement of infrastructure changes; a stale range silently stops working rather than failing loudly. You can also confirm from your own log by looking at where bounces are actually coming from:
grep 'MAILER-DAEMON' /var/log/exim_mainlog | grep -oE 'H=[^ ]+ \[[0-9.]+\]' | sort | uniq -c | sort -rn | headcPanel greylisting
Greylisting temporarily rejects the first connection from an unknown sender and accepts the retry. That is fine for botnet spam and harmful for bounces you want immediately. Add the range as a trusted host:
whmapi1 create_cpgreylist_trusted_host ip='162.220.160.0/28'
whmapi1 read_cpgreylist_trusted_hosts | grep -A2 mailbabyThe second command lists trusted hosts so you can confirm the entry. The same list is visible under WHM » Email » Greylisting » Trusted Hosts. If you use a comment field, mark it as the MailBaby return range so a future admin knows why it is there.
CSF and LFD
CSF applies a connection rate limit per IP on port 25 through CT_LIMIT and PORTFLOOD, and LFD blocks IPs that trigger repeated SMTP AUTH failures or Exim rejections. MailBaby’s return traffic can trip both on a busy server, particularly PORTFLOOD if bounces arrive in a burst after a mailing. Allow the range explicitly:
csf -a 162.220.160.0/28 "MailBaby return traffic"
grep mailbaby -i /etc/csf/csf.allowcsf -a writes to /etc/csf/csf.allow and applies the rule immediately. Entries in csf.allow are exempt from PORTFLOOD, CT_LIMIT and LFD blocking, which is what you want. Do not add the range to csf.ignore as well; that stops LFD logging anything about it and you lose visibility.
Outbound is the other direction: CSF’s SMTP_BLOCK setting, if enabled, prevents non-root and non-mail users from connecting to port 25 remotely. Exim runs as its own user and is on the SMTP_ALLOWUSER list by default, so the relay connection to relay.mailbaby.net:25 is unaffected. Verify with grep -E '^SMTP_(BLOCK|ALLOWUSER)' /etc/csf/csf.conf. Note that the cPanel-maintained CSF fork, which replaced the discontinued ConfigServer builds in early 2026, keeps these option names unchanged.
SpamAssassin
Bounces and returned rSPAM messages contain the original message, which by definition scored as spam. SpamAssassin will often score the bounce highly too and a customer with aggressive filtering deletes it unread. Two changes help. First, tell SpamAssassin that the relay is part of your trusted infrastructure so the Received: hop is not treated as an untrusted relay. In /etc/mail/spamassassin/local.cf:
trusted_networks 162.220.160.0/28
internal_networks 162.220.160.0/28Second, add a small negative score for bounces from the relay so genuine delivery status notifications get through while still allowing strong spam signals to dominate:
header __SRVS_MB_RELAY Received =~ /mailbaby\.net/i
meta SRVS_MB_BOUNCE (__SRVS_MB_RELAY && ANY_BOUNCE_MESSAGE)
score SRVS_MB_BOUNCE -2.0
describe SRVS_MB_BOUNCE Delivery status notification returned via MailBabyRestart the daemon and check the rules parse:
spamassassin --lint
systemctl restart spamdPer-user whitelists in cPanel » Spam Filters » Additional Configurations are not the right tool here; they whitelist sender addresses, and bounces come from MAILER-DAEMON at many hosts.
Exim callouts
If sender verification callouts are enabled in WHM » Exim Configuration Manager » Basic, Exim may attempt a callout to the relay’s null-sender bounces. Callouts on bounces are pointless and slow. Confirm that Sender verification callouts is off unless you have a specific reason; the default is off.
Verify
Send a message through the relay to a non-existent mailbox at a domain you control on another server, so it bounces. The bounce should arrive within a minute and appear in /var/log/exim_mainlog with the relay range in the H= field and no temporarily rejected greylisting line before it. Check csf -g 162.220.160.1 returns no deny entries and that the bounce in the customer’s inbox is not tagged as spam.
The common pitfall is whitelisting an old range copied from a forum post: verify the current range, and set a reminder to re-verify it quarterly. If you also use the mail queue report, a rising count of frozen bounce messages is the first sign the return path is being blocked.
Whitelist MailBaby cPanel at a glance
Official documentation: cPanel & WHM documentation, RFC 5321 (SMTP), Linux man pages.
Related guides: Warm up a new mail server IP or sending domain without landing in spam · Setting up MailBaby with cPanel/WHM Exim: router, transport, SRS and DKIM · Email forwarders with MailBaby: SRS, strict forwarding errors and backoffs.
Frequently asked questions
Do I need to whitelist MailBaby if greylisting is disabled in WHM?
The greylisting step can be skipped, but the CSF allow entry and the SpamAssassin trusted network lines still matter, because rate limits and spam scoring on returned messages are independent of greylisting.
Does whitelisting MailBaby in CSF open the server to spam from that range?
No. The range only carries bounces, delivery notifications and rSPAM returns for mail your own server sent through the relay. The csf.allow entry exempts it from connection limits and LFD blocking; Exim’s normal recipient checks and SpamAssassin still run.
Should the MailBaby range go in csf.allow or csf.ignore?
csf.allow. It exempts the range from PORTFLOOD, CT_LIMIT and LFD blocks while keeping it visible in the logs. csf.ignore stops LFD logging the range at all, which hides problems rather than solving them.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Last full review
- Next review
- Sources
- docs.cpanel.net