The Three Types of Whitelist

Indition Spam Killer supports three distinct whitelist mechanisms, each operating at a different level. Understanding what each one does — and what risks it carries — is essential before you start adding entries.

IP-Based Whitelisting

An IP whitelist entry tells the filter to trust all mail originating from a specific IP address or CIDR range. This is the right tool for internal systems: monitoring agents, application servers, backup systems, or any software that sends automated email from a known, controlled IP address.

whitelist:
  ips:
    - 10.0.1.50          # Internal monitoring server
    - 192.168.10.0/24    # Internal app server range

IP whitelisting is reliable because IP addresses don't lie in the way sender addresses do. Your internal monitoring server at 10.0.1.50 is not going to be hijacked and used to send phishing emails to your own employees. Use IP whitelisting liberally for internal infrastructure, but sparingly for external senders — an external IP can change hands, be compromised, or belong to shared hosting that also sends spam.

Domain-Based Whitelisting

A domain whitelist entry trusts all mail from any sender address at a specified domain. This is where most organizations make mistakes. The configuration looks harmless:

whitelist:
  domains:
    - bigvendor.com
    - partnercompany.org

The problem is that domain whitelisting creates a large, silent trust hole. If bigvendor.com gets compromised — and vendor email breaches happen constantly — every email arriving from that domain bypasses your spam filter entirely. Attackers who compromise a vendor's email infrastructure specifically look for customers who have whitelisted the vendor's domain, because it gives them a direct, unfiltered path into the target organization.

Domain whitelisting is appropriate only in narrow cases: domains you control yourself (subdomain routing, internal aliases) or domains with very high confidence of security posture. For most external vendors and partners, sender-level whitelisting is significantly safer.

Sender Address Whitelisting

A sender whitelist entry trusts mail from a specific email address. This is the most precise form of whitelisting and should be the default choice for individual people you want to ensure always get through:

whitelist:
  senders:
    - alice@bigvendor.com
    - noreply@paymentprocessor.com
    - reports@analytics-platform.io

If bigvendor.com is compromised, only mail from alice@bigvendor.com bypasses filtering — other addresses at that domain are still subject to normal scrutiny. The blast radius of a compromised vendor is much smaller with sender-level than domain-level whitelisting.

What Whitelisted Mail Still Does

A common misconception is that whitelisted mail gets no processing at all. This is not true. Whitelisted messages in Indition Spam Killer still receive X-Spam headers — they're scanned and scored — but the score does not trigger quarantine or rejection. The headers are still written so you have a record of what the filter would have said.

This matters for two reasons. First, it means you can audit whitelisted senders: if a vendor's mail starts arriving with a score of 8.5, that's a signal worth investigating even if it didn't get quarantined. Second, it means that if you later remove a sender from the whitelist, you already have historical scoring data to understand how they'll be treated.

When to Whitelist vs. When to Adjust the Threshold

Before adding a whitelist entry, ask: is this sender legitimately scoring high, or are they hitting false positives occasionally? These require different responses.

If a sender is legitimately scoring high — they send bulk newsletters, their email platform doesn't set good headers, they use a third-party ESP with a shared IP reputation — the right response is probably not to whitelist them, but to consider whether you actually want that mail at all. A newsletter service scoring 6.5 might be better handled by adjusting your newsletter folder rules in your email client than by lowering your filter's guard.

If a sender is hitting false positives occasionally — a key business contact whose mail sometimes has an elevated score due to the content they send — a sender-level whitelist entry is appropriate. You know the person, you need their mail to arrive reliably, and you trust that if their account is compromised you'll hear about it through other channels.

Raising the global spam threshold is almost never the right response to a single problematic sender. It degrades protection for every domain in exchange for fixing one relationship. Targeted whitelisting is almost always better than threshold adjustment.

How to Test Whether a Whitelist Is Working

After adding a whitelist entry, you can verify it's active by checking the X-Spam headers on a message from that sender. A properly whitelisted message will contain a header like:

X-Spam-Status: No, score=4.2 required=5.0 whitelisted=yes
X-Spam-Whitelist: sender:alice@bigvendor.com

The whitelisted=yes flag confirms the entry matched, and the X-Spam-Whitelist header tells you exactly which rule matched — sender, IP, or domain. If you don't see these headers, check that your configuration was reloaded after the change and that the whitelist entry is syntactically correct.

To test an IP whitelist, send a message from the whitelisted IP and check for:

X-Spam-Whitelist: ip:10.0.1.50

If you see the whitelist header with the correct source, the entry is working. If the header is absent or shows a different matched rule, review the configuration and ensure the IP matches exactly — CIDR ranges must be correctly formatted, and IPv6 addresses must be in canonical form.

Whitelist entries should be audited periodically. Senders move, vendors change email systems, internal servers get decommissioned. An entry that made sense two years ago may now be an open hole that no longer serves any purpose. A quarterly review of your whitelist is a low-effort habit that meaningfully improves your overall filter posture.