Block List (Blocklist)

A block list, also written blocklist, is a list of entities that are explicitly denied access or blocked from acting — a denylist. The entities can be many things depending on context: email addresses or domains blocked from reaching an inbox, IP addresses barred from a server, websites filtered out, users banned from a platform, apps prevented from running, or ad placements excluded from a campaign. The logic is permissive by default with named exceptions: everything is allowed except what appears on the list. Add something to the block list and it is shut out; leave it off and it passes. Block lists are a basic tool of security, moderation, spam filtering, and campaign control — a simple, direct way to keep known-bad or unwanted entities from getting through while everything else continues to flow.

A note on terminology is worth making, because it has changed. The concept was long called a blacklist, paired with whitelist for the opposite. Across the industry those terms have been widely replaced by block list (or blocklist) and allow list (or allowlist), which describe the function plainly and avoid the older words' unwanted connotations. The mechanism is unchanged — a block list still denies what it names — but the current, preferred terms are blocklist and allowlist, and you will increasingly see documentation, products, and standards use them. When you meet the old words in legacy material, read blacklist as block list and whitelist as allowlist. Using the current terms is not just etiquette; it is now the convention in most technical and marketing writing, so it keeps your language clear and current.

The block list's direct opposite is the allowlist, and the two embody opposite default stances. A block list is deny-by-exception: everything is permitted except the entities named on the list, so you block the known-bad and let the rest through. An allowlist is permit-by-exception: everything is denied except the entities named on the list, so you allow only the known-good and block everything else. They are mirror images. A block list is open by default and closes specific doors; an allowlist is closed by default and opens specific doors. Which you choose depends on the risk. Block lists suit situations where most traffic is fine and you only need to stop identified offenders; allowlists suit high-security situations where the safe set is small and known and everything unfamiliar should be refused.

The trade-off between them is coverage versus strictness. A block list is easy to run when the universe of good things is huge and only a few bad ones need stopping — but it can only block what is already known, so novel threats slip through until they are added, and the list needs constant updating. An allowlist is far stricter and safer against the unknown, since anything not explicitly approved is denied, but it is heavier to maintain and can block legitimate new entities that simply have not been added yet. In practice, systems often use both: an allowlist to define the trusted core and a block list to knock out specific bad actors within the broader allowed space. Choosing between them, or combining them, comes down to whether the greater cost is letting a bad thing in or keeping a good thing out.

Using block lists well means being clear about what you are blocking and why, and keeping the list current. Because a block list only stops what it names, its value depends on maintenance — adding new bad actors as they appear and removing entries that no longer belong, so it neither leaks nor over-blocks. Use accurate identifiers (the right address, domain, or placement) so you block the intended target and not innocents that resemble it. Match the tool to the risk: a block list is right when most of the field is fine and you are excluding known offenders, but where the safe set is small and the stakes are high, an allowlist is the sounder default. In advertising, for instance, a block list of unwanted sites or apps keeps a campaign off bad placements while leaving the wide inventory open — a sensible use of the deny-by-exception model.

The failures come from treating a block list as complete protection. Because it blocks only the known, relying on it alone leaves you exposed to anything new until it is spotted and added, which is why block lists lag behind fresh threats. Over-broad entries are the opposite danger — block a whole domain or range and you may shut out legitimate senders or users caught in the net. Stale lists that no one prunes keep blocking things that are now fine, or fail to block things that are now bad. And using a block list where the risk really called for an allowlist accepts too much by default. The discipline is to keep the list accurate and current, size each entry precisely, and choose deny-by-exception only where letting the unknown through is an acceptable risk — otherwise reach for the allowlist.

Block list, or blocklist, joins block, to obstruct, with list, an enumerated set, naming a denylist of blocked entities; it and allowlist have largely replaced the older blacklist and whitelist.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where block list (blocklist) is a core concern: