# Whitelist MailBaby cPanel: Stop Greylisting and CSF Blocks

Source: https://srvscripts.com/guides/whitelist-mailbaby-cpanel/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

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.

In short: 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…

**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 | head
```

## cPanel 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 mailbaby
```

The 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.allow
```

`csf -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/28
```

Second, 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 MailBaby
```

Restart the daemon and check the rules parse:

```
spamassassin --lint
systemctl restart spamd
```

Per-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](/scripts/exim-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](https://docs.cpanel.net/), [RFC 5321 (SMTP)](https://www.rfc-editor.org/rfc/rfc5321), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [Warm up a new mail server IP or sending domain without landing in spam](https://srvscripts.com/guides/warm-up-new-mail-server-ip-domain/) · [Setting up MailBaby with cPanel/WHM Exim: router, transport, SRS and DKIM](https://srvscripts.com/guides/mailbaby-cpanel-whm-exim-setup/) · [Email forwarders with MailBaby: SRS, strict forwarding errors and backoffs](https://srvscripts.com/guides/mailbaby-srs-strict-forwarding-errors/).

## 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.