Allow & block lists
Allow and block lists override scoring for specific senders. They exist at three levels: global (every organization), organization, and user (personal lists users manage in the portal).
Entry formats
| You enter | Matches |
|---|---|
ceo@partner.com | Exactly that sender address (header From or envelope sender). |
@partner.com or partner.com | Any address at exactly that domain. |
*.partner.com | That domain and every subdomain (mail.partner.com, eu.partner.com...). |
203.0.113.7 or 203.0.113.0/24 | Mail from that connecting IP / range (organization and global lists only). |
Entries are validated when saved. Adding a pattern to the allow list removes it from the block list at the same level, and vice versa.
Which entry wins
- The most specific level decides: the recipient's personal list first, then the organization's, then the global list.
- Inside one level, block beats allow.
So a user can allow a newsletter the organization blocks, and an organization can block something globally allowed.
What an allow entry does NOT bypass
- Viruses and malware (ClamAV, Spamhaus HBL file hashes).
- Attachment policy (blocked file types, macros, encrypted archives).
- A DMARC failure where the sender's domain publishes
p=reject- so allow-listingceo@partner.comnever lets a forged copy of that address through.
Managing lists (Protect › Allow & block)
- Search / Level
- Find entries by text; filter to global, organization or user entries.
- Add entry
- Sender, domain or IP, List (Block / Allow), Level (Organization, or Global for MSP administrators), Organization (MSP administrators) and an optional Note (why it was added - you will want this in a year).
- Remove
- Deletes the entry. Effective within 30 seconds.
The table shows who added each entry and when. Organization administrators see their organization's entries and their users' personal entries.
Quicker ways to add: Allow / Block sender / domain on a message page; users' Release and always allow and Report as spam (personal lists); the REST API.