We are an ESP provider from Czech Republic, Europe. Our clients are regular Czech companies with their own client database. Since yesterday, we have a problem with our domains used in emails for online version, logout link and tracking the links. We are receiving a bad score because of these domain names.

The score is, e.g.:

RAZOR2_CF_RANGE_51_100 = 0.365

RAZOR2_CF_RANGE_E8_51_100 = 2.43

RAZOR2_CHECK = 1.729

We found out that one of our client probably sent a campaign on bought DB (100.000 addresses), so we blocked him, but now we need to solve this issue.

To buy a new domains is a solution, but not long-term solution. Do you have any idea how to solve it?

Would it help that every user of our system would have (for these links in email) a subdomain like username.redirectdomain.com Or another solution—registering to some whitelist?

There should be a solution when you from 95% do not send spam and you don't want to replace your domains every week. HW and IP addresses we have solved well, we have problem with this penalization in email body—especially for domain names used for tracking the links (official links are replaced with ours).


Razor2 is a hash sharing system based on fuzzy checksums. It builds a feature vector from the content of the email and then makes a distance comparison between it and known spams in a cloud database. AFAIK, it does not consult domain blocklists, though I don't have intimate details of its feature selection.

Regarding blocklisted domains, you'll have to reach out to each DNSBL service that lists your domains and ask for them to remove your entries. Many of these will automatically retract your domains after some buffer period following the end of the spam campaigns that used them. M³AAWG's documents, especially the Help – I'm on a Blocklist guide, could provide the exact guidance you need.

If you want further help, specifically from within this industry, I'd suggest that your employer joins M³AAWG, which creates a venue for well-behaved ESPs to meet with ISPs and other receivers as well as security companies (including Cloudmark, which owns and operates Razor2).

M³AAWG meets three times a year; San Francisco, East Coast US, and Europe. The next meeting will be in San Francisco in February and the meeting after that will be in Dublin this June. Maybe I'll see you there.


Razor2 is a blocklist, period.

It is a blocklist like every other blocklist, and despite their attempt to appear to be "trustworthy" where every user has a "trust" score, this list is also being fed from data that is collected from spamtraps in an automatic way. The mere fact that it is operated and owned by Cloudmark means that Cloudmark can set up their own trap accounts and give them a trust score of 100 very easily. and why not? it is their product now (Vipul stopped working there very long ago), their property, and they can choose what to do with it.

The only difference here, is that unlike other blocklists, you have no way of removing yourself from the list, and listing will automatically stop once the originating source that sent the blocked email ceases. So realy, the only way to have yourself not listed in it - is simply not to send emails to their spamtraps, and the only way to do that is to have double opt in or confirmed-opt in lists.

I have written a blog post about why Razor2 is a blocklist, where you can get some actual details about how and why it works the way it is.

  • 2
    Your blog post is extremely incorrect. Razor2 was written by Vipul Ved Prakash, who then went on to found Cloudmark (they didn't "buy" it), and it uses locality-sensitive hashing (fuzzy matching) specifically to cluster content that changes its characteristics (such as sender IP or domain). I've never heard anybody mention that it is a sender blocklist (because it's not). It is a "content blocklist" if you insist, but that term doesn't exist. See my answer from 3 years ago for further detail.
    – Adam Katz
    Sep 11 '17 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy