What is the Spamhaus content hash blocklist and how does it compare to DCC, Vipul's Razor, and Cloudmark?
Published 19 Jul 2025
Updated 23 Oct 2026
14 min read
Summarize with
Updated on 23 Oct 2026: We clarified HBL lookup responses, DCC bulk counts, and the evidence needed to investigate content filtering.
The Spamhaus content hash blocklist, usually called the Spamhaus Hash Blocklist (HBL), is a content-based blocklist (blacklist) that lets a receiving mail system query cryptographic hashes of selected message elements. Its documented token categories cover email addresses, cryptocurrency wallets, URLs, and malicious or suspicious files. It is not a sender authentication system, an IP blacklist, or a generic hash of the whole message body. It answers a narrower question: does this extracted content element have a bad reputation in the HBL context used for the lookup?
The shortest comparison is this: Spamhaus HBL is closer to Vipul's Razor and Cloudmark than it is to DCC, because HBL attaches reputation to specific content tokens, while the Distributed Checksum Clearinghouse (DCC) mainly reports how often similar message checksums have been seen. DCC totals reported recipient counts for similar checksums. Spamhaus HBL tells a receiver that an extracted token matches an HBL entry. Cloudmark and Vipul's Razor also use fingerprint-style detection, but their trust models and product shapes differ.
For senders, this distinction matters. Passing DMARC means that SPF or DKIM passed with an authenticated domain that meets DMARC's matching rules for the visible From domain. It does not prove that a URL, attachment, cryptocurrency wallet, or address in the message is acceptable. For background on IP and domain listings, start with blocklist basics and then map the content signals back to your sending sources.
How the four filtering systems differ
- Spamhaus HBL: A content hash blocklist that lets receivers query hashes of extracted email addresses, cryptocurrency wallets, URLs, and malicious or suspicious files in separate token contexts.
- DCC: A distributed fuzzy-checksum system that mainly answers whether similar mail has been seen in bulk. That makes it useful for scoring bulk mail, but unsafe when treated as proof of abuse.
- Vipul's Razor: A collaborative spam fingerprinting system where reported messages generate signatures that other systems can use for filtering decisions.
- Cloudmark: A commercial filtering system built around message fingerprinting, feedback, and network intelligence. It belongs in the same general family as Razor-style detection, rather than DCC-style bulk counting.
- Practical difference: HBL can identify a listed token inside a message, while DCC can identify repeated mail even when that mail is legitimate and wanted.
Treat content hash data as a receiver-side evidence layer. It helps decide what to do with a message after its content has been observed. It does not replace sender reputation, domain authentication, user feedback, complaint data, or local policy.
Spamhaus describes the value of Spamhaus hash blocklists as content-focused detection that can catch abusive material even when it arrives through shared infrastructure. The sending IP and authenticated domain remain useful signals, but HBL lets receivers check specific elements carried in the message.
How the Spamhaus content hash blocklist works
HBL processing starts when filtering software extracts a supported token, normalizes it as required for that token type, and computes a one-way cryptographic hash. The software then queries that hash in the matching HBL context. Spamhaus documentation specifies SHA-256 hashes encoded in RFC 4648 Base32, with hexadecimal SHA-1 support for email addresses, cryptocurrency wallets, and URLs. The file context requires SHA-256.
HBL usually runs during content analysis after SMTP DATA, because body URLs and attachments must be received before they can be checked. Header tokens can be checked once the relevant headers are available. The receiving system can still reject the message before acknowledging the end of DATA. That differs from an IP DNSBL, which can reject during the SMTP connection based on the connecting IP. It also differs from a domain blocklist, which checks domains used for sending or found in message content.
Spamhaus HBL filtering steps: normalize message tokens, create hashes, query the blocklist, and apply local policy.
The strongest use case is mail that looks technically legitimate at the transport and authentication layers but carries a token already associated with abuse. That includes a compromised sender address, a malicious or suspicious file, a cryptocurrency wallet used in a scam, or a campaign URL. A sender can have a valid DKIM signature and still send content that a receiver wants to quarantine.
URL hashing is a good example of why normalization and context matter. A harmful link can use a URL shortener, redirector, online file storage provider, or tracking path. Checking the specific URL token lets a receiver act on that resource without blocking the provider's whole domain or every legitimate user of the service. Spamhaus's URL normalization rules depend on the host, so hashing an arbitrary full URL does not reliably reproduce the listed token. Check header URLs such as List-Unsubscribe as well as links in the body.
A content blacklist hit applies to the queried token. It does not automatically place the whole sending domain or IP on a blacklist.
What HBL actually hashes
HBL organizes hashes by token context. The filtering software must extract the supported value, hash it in the documented format, and query the matching context. A hash without the correct context does not explain which kind of content matched.
|
|
|
|---|---|---|
Email address (_email) | A normalized address in Sender, Reply-To, or the message body | The address has been observed in spam; this does not by itself prove account compromise |
Cryptocurrency wallet (_cw) | A supported wallet address found in message content | The wallet has been observed in abusive mail |
URL (_url) | A URL processed using the applicable host-specific normalization rules | The URL has been observed in spam; the response alone does not classify it as malware |
File (_file) | A SHA-256 hash of an attached or extracted file | The file is known malware or has been observed as suspicious in spam |
Documented Spamhaus HBL token categories and the meaning of a match.
The one-way hashes reduce each token to a fixed-size value and avoid distributing the original address, wallet, URL, or file content. Hashing is not encryption or guaranteed anonymity: a guessed token can be hashed and compared. The lookup result still needs local interpretation, especially because the file context distinguishes known malware from files that are suspicious based on observation in spam.
Spamhaus HBL requires authorised data-service access and compatible extraction and lookup logic. It is separate from public IP DNSBL queries. A sender normally encounters it through a receiver's filtering result or through a Spamhaus listing investigation.
How to interpret HBL lookup responses
An HBL DNS lookup returns a category code, not a universal spam score. Spamhaus's HBL return codes distinguish token matches from query errors:
|
|
|
|---|---|---|
127.0.3.2 | Email address observed in spam | Investigate the matched address and message context |
127.0.3.10 | Known malware file | Apply the local malware-handling policy |
127.0.3.15 | Suspicious file | Assess attachment risk without calling it confirmed malware |
127.0.3.20 | Cryptocurrency wallet observed in spam | Investigate the wallet token and its use |
127.0.3.30 | URL observed in spam | Inspect the normalized URL and redirects |
127.0.3.255 | Unsupported IP query | Correct the lookup; this is not a content listing |
127.255.255.250 or 127.255.255.251 | Disabled or improperly used access key | Resolve the access error; do not count it as a token hit |
HBL DNS response codes identify the matched category or an access or query error.
NXDOMAIN means that the correctly formed query has no current entry in that context. A timeout or SERVFAIL is a failed check, not a clean result. A negative lookup also says nothing about other tokens, other blocklists, or whether the message is safe. Preserve the queried hash, context, return code, and timestamp when requesting a receiver review.
How HBL compares to DCC, Razor, and Cloudmark
|
|
|
|
|
|---|---|---|---|---|
Spamhaus HBL | Listed token hash | Token reputation | Targeted content filtering | Reused or compromised token |
DCC | Repeated fuzzy checksum | Reported bulk count | Bulk scoring | Wanted bulk |
Vipul's Razor | Reported fingerprint | Collaborative spam signal | Spam scoring | Shared message pattern |
Cloudmark | Network-classified fingerprint | Content and network signal | Commercial filtering | Provider-specific decision |
Compact comparison of content hash and checksum systems.
DCC is the odd one out. The Distributed Checksum Clearinghouse totals reported recipient counts for message checksums, so its core result measures bulk distribution. Bulk is not the same as unwanted. Receipts, order confirmations, school notices, and security alerts can share repeated content and still be wanted. A receiver that weights DCC too heavily can block legitimate mail. Fuzzy checksums deliberately ignore some message differences, so adding a personalized greeting does not reliably change the bulk result.
DCC also depends on local filter configuration. The receiving gateway needs a working DCC client or interface, enabled checks, and appropriate thresholds. A missing DCC result can therefore mean that no check ran, rather than that the message was not bulk.
Vipul's Razor is closer to HBL because it uses fingerprints of messages reported as spam. The data model still differs. Razor is centered on collaborative reporting with reporter reputation and confidence assessment, while Spamhaus applies its own collection, analysis, and listing processes to supported token types. A receiver is asking both whether a fingerprint or token has been seen and who classified it.
Cloudmark is also closer in concept because it uses message fingerprinting, reporter trust, and network feedback inside a commercial filtering system. It is not a public checksum counter, and current Cloudmark filtering includes more than fingerprints alone. Its scoring, customer deployment, and operational policy make it distinct from both Razor and HBL.
Rspamd scan results comparing content hash, DCC bulk checksum, and authentication signals.
Content reputation versus bulk detection
Content reputation systems
- Question: Does this token or message fingerprint match content classified as abusive or spam?
- Examples: Spamhaus HBL, Vipul's Razor, and Cloudmark-style fingerprinting.
- Strength: Can catch abusive campaigns that use reputable or shared infrastructure.
- Risk: Can affect legitimate senders when a listed address, URL, or shared asset appears in their mail.
Bulk checksum systems
- Question: Have participating systems reported many recipients for similar message checksums?
- Example: DCC, especially when used as one input in a larger filter.
- Strength: Good at identifying repeated mail, including obvious campaign traffic.
- Risk: High-volume legitimate mail can be handled incorrectly when operators treat bulk as unwanted.
For that reason, the core DCC checksum count should not be called a content reputation verdict. DCC also has a separate sender reputation facility, but that is distinct from its distributed bulk counts. The receiving filter decides how that evidence affects scoring or delivery.
The better receiver pattern is to interpret each result by category and local policy. A DCC bulk result needs consent or allowlist context before blocking. A confirmed malware file and a suspicious file deserve different handling, and a DMARC pass must not override either result automatically.
Example receiver decision logictext
# Illustrative policy, not production configuration if hbl_access_error or hbl_query_error: record_check_failure() elif hbl_known_malware_file: apply_local_malware_policy() elif hbl_token_match: evaluate_token_category_and_other_signals() if dcc_bulk: apply_bulk_policy_with_recipient_allowlist_context() # DMARC pass does not clear a content match.
What this means for senders
From the sending side, the mistake is to look only at DMARC pass rates and assume content filters have no reason to complain. DMARC checks whether a passing SPF or DKIM result has a domain that meets its matching rules for the visible From domain. An HBL result tells the receiver that a specific extracted token has a reputation problem.
Check the supported HBL token categories first: a sender or reply address tied to a compromised account, a URL used in unwanted mail, a cryptocurrency wallet associated with abuse, or a malicious or suspicious file. In shared sending systems, one compromised tenant can introduce a listed token into otherwise authenticated mail.
Blocklist checker
Check your domain or IP against 144 blocklists.
Suped's product supports the surrounding investigation through DMARC reporting, domain and IP blocklist monitoring, and alerts. These checks help compare a content complaint with unknown sending sources or authentication errors. A clean domain or IP result in Suped does not rule out an HBL token match, and DMARC aggregate reports do not identify the URL or attachment that triggered a content filter.
In Suped, the practical workflow is to review DMARC sources, verify which services are allowed to send, and monitor blocklist (blacklist) exposure for sending domains and IPs. The blocklist monitoring workflow adds alerts for listing changes, while the receiver's HBL evidence identifies the content token to investigate.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
How to investigate a suspected content hash problem
A suspected HBL issue is easiest to fix when you separate message content from infrastructure evidence. Do not start by changing every DNS record. Start by confirming the receiver's named rule, token context, and lookup response.
- Capture samples: Save the exact raw message that was blocked, quarantined, or scored badly, including headers, body, and attachments.
- Confirm the named signal: Read the SMTP response, filter symbols, and receiver evidence to distinguish HBL from an IP, domain, DCC, Razor, or local content rule. Request the queried hash, token context, and response code when available.
- Compare supported tokens: On controlled test copies, change one item at a time, focusing on sender and reply addresses, body contact addresses, full URLs including List-Unsubscribe, cryptocurrency wallets, and files. Compare normalized tokens rather than assuming a cosmetic edit changes the hash.
- Check authentication: Confirm whether SPF or DKIM passes with a domain that meets DMARC's matching rules for the visible From domain. Treat authentication and content results as separate evidence.
- Separate bulk signals: If the report includes DCC, confirm which rule ran and how its counts, thresholds, and recipient allowlists affected the final action. A bulk count is not an IP or domain blacklist listing.
- Test delivery: Send controlled samples through an email tester and compare authentication and content results against each change. Testers only report the checks they run; confirm any suspected HBL match with the rejecting receiver's evidence.
Do not rotate domains, IPs, or tracking hosts just to escape a content hash hit. That can turn a content issue into a wider reputation issue. Stop affected traffic and remediate the cause. For account compromise, revoke the compromised credentials and unauthorized sessions before seeking removal. If the match is a false positive, keep the raw samples and follow the listing operator's process.
If Spamhaus HBL is the suspected source, read more about Spamhaus HBL before you decide whether the issue is an email-address, wallet, URL, or file hash match, a related domain listing, or a broader reputation problem.
When removal is relevant, treat it as a technical correction process. Identify the matching token, remove or remediate the cause, then use the appropriate HBL removal path with raw-message evidence rather than guesses. If a sending provider controls the affected infrastructure or account, coordinate the investigation and removal request with its abuse team.
How to handle legitimate bulk mail in DCC
DCC still has value when a receiver wants to know whether similar mail is being seen at scale across participating systems. It is useful as one input in a larger filter. The problem starts when a receiver treats bulk as a synonym for bad.
For wanted newsletters or transactional messages, the recipient administrator should review local DCC thresholds and narrowly scoped allowlists (called whitelists in DCC documentation). DCC does not maintain a central IP or domain blacklist for its checksum counts, so a generic delisting request does not resolve a bulk match. Contact the operator that rejected the message and provide evidence that the recipient requested it.
Interpret the signal before choosing an action
Illustrative review categories, not universal scores or delivery guarantees.
No content hit
Continue checks
Continue other filtering checks; no match does not prove safety.
DCC bulk only
Review bulk policy
Review recipient consent, allowlists, and local bulk thresholds.
Reported fingerprint or HBL token
Investigate match
Identify the exact rule, context, and confidence before choosing an action.
Confirmed HBL malware file
Apply malware policy
Use the local malware policy even when DMARC passes.
What not to infer from a hash hit
A hash hit is evidence about the value queried, but it is still one signal in the receiver's decision. Do not infer that the whole domain is malicious, that every message using the same sending service is bad, or that DMARC is broken. Those are separate questions.
- Domain status: A token match can affect one message while the sending domain still has valid authentication.
- IP status: An IP can pass normal DNSBL checks while a message token still matches a content blacklist.
- Content scope: An HBL match identifies the queried email address, wallet, URL, or file hash, not every part of the template.
- Fix status: A DNS change helps only when the separate root cause is sender authorization or domain misuse.
The clean path is to prove the failing layer. If the issue is a listed token, fix or remove that token and its source. If it is sender authorization, correct the relevant authentication configuration. If a separate IP or domain listing exists, collect evidence and use that list's removal process.
Frequently asked questions
No. DCC mainly reports recipient counts for similar message checksums, and the receiver decides whether that bulk signal affects delivery. Spamhaus HBL queries hashes of supported content tokens that have HBL reputation entries.
No. Spamhaus documents separate HBL contexts for extracted email addresses, cryptocurrency wallets, URLs, and files. Filtering software normalizes and hashes the supported token for its matching context.
Yes. Vipul's Razor and Spamhaus HBL both attach meaning to fingerprints or hashes associated with abuse, although Razor is centered on collaborative spam reports and HBL uses Spamhaus's token-specific listing processes.
Cloudmark is a commercial filtering system that uses message fingerprinting, reporter trust, and wider network intelligence. It is closer in concept to Razor-style content detection than to DCC's core checksum counts, but it is not interchangeable with either system.
No. A DMARC pass requires a passing SPF or DKIM result with a domain that meets DMARC's matching rules for the visible From domain. It does not establish that an address, cryptocurrency wallet, URL, or file in the message has good content reputation.
Capture the raw message and confirm that the receiver actually named HBL. Request the token context, queried hash, and response code, then compare the extracted addresses, normalized URLs, cryptocurrency wallets, and file hashes while verifying authentication separately. A clean IP or domain lookup does not exclude an HBL token listing.
