IP Whitelisting or Allow Listing

IP whitelisting — increasingly called allow listing — is the practice of naming senders that must always be accepted, regardless of what any blocklist says about them. It is the necessary counterpart to IP blacklisting: the mechanism that keeps a false positive on a third-party list from costing you a customer’s order confirmation.

Why is a whitelist needed at all?

Because you do not control the lists you reject on. A DNSBL operator can list a shared outbound relay used by your bank, your payment provider or your own ticketing system, and your server will refuse that mail without ever telling you what you missed.

There is a second reason that has nothing to do with false positives. Some senders you must accept are objectively poorly configured — a supplier with no PTR record, a legacy application server with a hostname that fails every check. A whitelist entry is the honest way to carry that exception, and it is far better than loosening the check for everybody.

Where does the whitelist go in the rule order?

Above the blocklist checks and below the anti-relay rules. In Postfix:

smtpd_recipient_restrictions =
    reject_invalid_hostname,
    reject_unauth_pipelining,
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_client_access hash:/etc/postfix/rbl_allow,
    reject_rbl_client zen.spamhaus.org,
    permit

The file itself is a simple map, converted with postmap:

root@server $ cat /etc/postfix/rbl_allow
mail.partner.example  OK
192.0.2.25            OK
198.51.100.0/24       OK

root@server $ postmap /etc/postfix/rbl_allow

The placement of check_client_access above reject_rbl_client is the whole mechanism: an OK terminates evaluation, so nothing below it can reject the connection. Placing it below the blocklist would accomplish nothing at all.

The full setup, including the combination with a local blocklist, is covered in whitelisting hosts, IP addresses and even networks in Postfix.

What does a whitelist entry actually bypass?

More than most people intend. An OK in check_client_access at this position skips every remaining restriction in the list — not just the DNSBL lookup, but the hostname checks, any later access maps, and anything you add underneath in future.

That is why the two most common failures are both about scope:

• Too broad. Whitelisting a /16 because one host inside it was blocked exempts sixty-five thousand addresses, most of which belong to someone else.
• Too permanent. An entry added to unblock a partner during an incident in 2021, never removed, is a standing bypass for whoever holds that address today. Address space gets reassigned.

How should a whitelist be maintained?

• Narrow the entry to the smallest range that solves the problem — a single host rather than the network it sits in.
• Record why and when. A comment with the date and the ticket turns an unexplained line into something a colleague can safely delete later.
• Review on a schedule. Anything that cannot be justified on review should go; if it was still needed, you will find out quickly and can re-add it with a current reason.
• Prefer authentication where it exists. For your own applications and relays, SMTP AUTH or a dedicated submission service is a better control than an IP exemption — see access management.
• Log the matches. A whitelist entry that has not matched in a year is not protecting anything.

Whitelisting and blacklisting together

The two combine to express exceptions a single list cannot. If a network sends mostly unwanted mail but contains one host you need, blacklist the range and whitelist the host — with the whitelist first:

# /etc/postfix/rbl_allow  (checked first)
192.0.2.23  OK

# /etc/postfix/my_blacklist  (checked after)
192.0.2.0/24  REJECT blocked for a good reason

This is the pattern described in blacklisting single hosts, IP addresses and even networks in Postfix, and it is the main reason to maintain a local blocklist rather than relying purely on public ones: your own list is the one you can carve exceptions out of.