---
title: "IP Whitelisting or Allow Listing"
description: "IP whitelisting exempts trusted senders from blocklist checks, so important mail is never rejected by a third-party listing or an overly broad rule."
url: "https://mailmum.io/glossary/ip-whitelisting/"
---

# 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](https://mailmum.io/glossary/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](https://mailmum.io/glossary/dns-blocklist-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](https://mailmum.io/glossary/pointer-record-ptr/), 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:

```txt
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`:

```sh
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](https://mailmum.io/posts/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](https://mailmum.io/glossary/access-management-in-email-systems/).
* **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:

```sh
# /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](https://mailmum.io/posts/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.