How Sender and Domain White List and Black List Precedence Works in SpamSentinel for Domino

This article applies to SpamSentinel, DuoCircle's spam filtering product for IBM Domino mail servers. It is intended for mail administrators who need to understand how SpamSentinel decides whether to allow or block a message based on sender address and domain rules, and how to achieve specific outcomes such as allowing individual senders from an otherwise-blocked domain.

This article explains how SpamSentinel evaluates an inbound message's sender address and sender domain against your configured White Lists and Black Lists, what order those checks happen in, which of the two candidate sender addresses (SMTP envelope vs. header "From") are actually compared against each list, and what conditions can override a white-listed sender. This covers only the sender-address / sender-domain based blocking/allowing mechanisms:

• Black Lists: Global Domain, Global Sender, Personal Sender/Domain
• White Lists: Global Sender, Global Domain, Personal Sender/Domain

It does not cover Subject, Subject Substring, word/content scanning, restricted attachments, SPF, or other non sender/domain based controls.

Two Candidate Addresses Per Message

For every inbound message, SpamSentinel extracts two separate sender identities before running any list checks:

• SMTP Address — the SMTP envelope sender (the "MAIL FROM" address the sending server actually used)
• From Address — the RFC822 message header "From:" field (what the mail client displays to the recipient)

These are not always the same address, and — importantly — not every list checks both of them. This is one of the most misunderstood parts of the product's behavior, detailed below.

Which Lists Check the SMTP Address vs. the Header From Address

Key takeaways:

• White Lists are symmetric and unconditional. Both the Global and Personal White List checks always test the SMTP address/domain first, and — if no match is found — automatically fall back to testing the header From address/domain as well. There is no setting that disables this fallback.
• Global Black Lists are asymmetric and configuration-dependent. By default, the Global Domain and Global Sender Black Lists only test the SMTP envelope address/domain. The header From address/domain is only additionally checked if the administrator has explicitly enabled the "Black List From Field" option in the black list configuration. If that option is off, a spammer could theoretically forge the visible "From:" header to a black-listed domain while using a different (non-blacklisted) SMTP envelope sender, and it would not be caught by the domain/sender black lists.
• Personal Black Lists never check the header From address, no matter how the black list options are configured — only the SMTP envelope address/domain is compared against a recipient's Personal Black List entries.
  
  

Overall Order of Evaluation

For every message, SpamSentinel checks lists in this order, stopping as soon as a decision is reached:

1. Global Sender / Global Domain White List — checked against SMTP address/domain, then (if no match) the header From address/domain.
2. Recipient validation (not a list, but happens next and can independently quarantine a message for invalid recipients).
3. Personal White List (per valid recipient) — checked against SMTP address/domain, then header From address/domain.
4. Global Domain Black List — SMTP domain always; header From domain only if "Black List From Field" is enabled.
5. Global Sender Black List — SMTP address always; header From address only if "Black List From Field" is enabled.
6. Subject / Subject Substring Black Lists — not sender-based, evaluated here in the sequence but out of scope for this article.
7. Personal Black List (per valid recipient) — SMTP address/domain only; header From is never checked.
   
   

The single most important rule: White Lists always win

As soon as any White List match is found (global or personal), all subsequent Black List checks are skipped entirely for that message. There is no scenario in the core sender/domain logic where a Black List entry can override a White List match. If a sender or domain is white-listed by any method, the message is marked "not spam" and none of the black list checks below it are even evaluated.

A Note on "Personal Domain" vs. "Personal Sender" Lists

Personal Domain and Personal Sender entries (both white and black) are not evaluated as two fully independent lookups — for a given recipient, the engine builds a combined lookup key of Recipient~Domain first, and if that isn't found, falls back to Recipient~EmailAddress. Administratively you can enable/disable each type independently in the UI, but functionally a match on either produces the same allow/block result for that recipient.

A Note on Multi-Recipient Messages and Personal Lists

Personal White/Black Lists are evaluated per recipient, not per message. On a message with multiple recipients, it's possible for the message to be white-listed for one recipient (removing that recipient from spam handling) while still being evaluated against the black list for other recipients who don't have a matching personal white list entry. Global White or Black List matches, by contrast, apply to the entire message for all recipients simultaneously.

Exceptions: Conditions That Can Override Even a Global White List Match

While a Global (or Personal) White List match normally guarantees the message is delivered without further spam handling, a few conditions are evaluated independently of white list status and can still cause a white-listed message to be quarantined, flagged, or altered:

1. Virus Detection — If the antivirus scan detects a virus, SpamSentinel forces the message into the highest spam category (Category D) regardless of any white list match, and explicitly disables the "Allow White-Listed Category D messages" setting for that message. A confirmed virus always overrides sender/domain white listing.
2. Administrator "Forced Result" — If an administrator manually forces a spam classification on a message (Forced Results feature), that forced action explicitly disables white-list processing for that message ("Allow White List" is turned off), overriding any sender/domain white list that would otherwise have applied.
3. Real-time Block List (RBL/DBL, e.g., Spamhaus) Lookups — DNS-based block list lookups (RBL for the sending IP address, DBL for the sending domain) run independently of, and separately from, the white/black list decision logic. If a message's sending IP or domain is found on an enabled RBL/DBL, the message's spam category is raised/promoted. This check is not gated by whether the sender or domain is on your Global White List, so a message from a white-listed domain whose sending mail server IP is currently listed on Spamhaus can still be flagged or promoted to a higher spam category.
4. Invalid Recipient Handling — Recipient validation happens independently of sender white/black listing. A message with no valid recipients can still be routed to quarantine even if the sender was globally white-listed, since the "invalid recipient" outcome is evaluated as a separate condition.
5. Restricted/Blocked Attachment Scanning — Attachment-type restrictions (e.g., blocking .exe files) are, by default, evaluated regardless of white list status. There is a separate configuration option ("Skip attachment scanning for white-listed senders") that administrators can enable to bypass this for globally or personally white-listed senders, but by default this scan is not skipped for white-listed senders.
6. MS Office Malware/Macro Scanning — Similarly, Microsoft Office document scanning for malicious content has its own independent "skip scan for white-listed senders" setting; a white-listed sender does not automatically bypass this scan unless that option is enabled.
   
   

In short: sender/domain white listing is the strongest control among the address-based blocking methods and always defeats black lists, but (a) it doesn't check the header From address consistently the way white lists do, (b) it does not exempt a message from virus scanning, administrator-forced results, or DNS block list (Spamhaus RBL/DBL) checks, and (c) unless explicitly configured otherwise, it also does not automatically exempt a message from restricted attachment or MS Office malware scanning.

Key Takeaways

• White Lists always take priority over Black Lists for sender/domain decisions
• To allow specific senders from a blocked domain, add those addresses to the Global Sender White List and add the domain to the Global Domain Black List
• White listing does not bypass virus scanning, RBL/DNS block list checks, or administrator-forced results
• Personal White/Black Lists are evaluated per recipient, not per message
• White Lists check both the SMTP envelope address and the header From address; Black Lists check the header From address only if the "Black List From Field" option is explicitly enabled