A denylist is a maintained set of indicators to refuse, such as addresses, domains, or file fingerprints, and teams also call it a blocklist or a blacklist.
The newer names avoid a loaded metaphor, while the control itself still stands or falls on fresh data and on room for honest users who were mislabeled.
How it works
Denylists work best against indicators that stay stable and that you are willing to update every day.
Attackers rotate addresses and files, so a list that was excellent last month can become a quiet source of false confidence.
Blocking too broadly hurts customers, partners, and your own monitoring systems.
Every entry needs an owner, a reason, and a review date, and there should be a fast path to remove a mistake when a legitimate service is caught.
Concrete examples
- A mail gateway refuses messages from a domain that has been sending invoice scams to your finance team all week.
- A site blocks a file fingerprint tied to a known banker family, then reviews the entry when the vendor ships a clean tool with a new fingerprint.
- An old address entry stops a partner's new office from reaching a portal until someone checks the review date and clears it.
Protective measures
- Give every denylist entry an owner, a reason, and a date when it must be reviewed or removed.
- Prefer narrow indicators over whole countries or huge address ranges unless a specific incident truly requires the broader block.
- Test how you will restore a legitimate partner quickly when a list entry is wrong.
- Use denylists together with identity checks and rate controls, because a changed indicator walks around a stale list.
Related articles
The article What is bot protection for sites? describes controls that do more than refuse a previously seen indicator.
The article What is a content delivery network? explains edge delivery where some refusal decisions can be applied close to visitors.
The article What is browser fingerprinting? covers client traits that sometimes feed a decision to challenge or refuse a session.