I looked at many, came away upset that most vendors do not understand the problem that they are purporting to solve.
Currently I am using SmarterMail+Declude as my first spam filter, but my Declude implementation is heavily customized. It blocks unwanted traffic based on source attributes. Then my messages go through two commercial spam filters. Those are pretty good at filtering based on content, but I cannot recommend either of them as well designed products capable of protecting you as a standalone solution.
During my search, I was close to recommending ProofPoint, only to discover that their secure web relay solution violates DMARC when a non-client responds to a message started by one of their clients. Subsequently found evidence that Cisco IronPort does the same. I opened security complaints with both vendors, which were ignored. My opinion is that if you are going to advertise your skill at filtering inbound mail based on DMARC criteria, you should not be violating DMARC policies when sending outbound mail. I do not have enough experience with Zixmail to know if the Mimecast/Zixmail combination has this problem or not.
My distributor, who handles many product lines, said that Cisco IronPort is a good but expensive solution if you buy into their whole portfolio (including desktop protection), but not cost effective as a point solution for email only.
If I were to reopen the procurement process, I would start with ClearSwift. They appeared to have the exception management features that I wanted, and were likely to be about half the cost of ProofPoint or MimeCast.
Here is what you should be looking for in exception management features. Some who have seen my previous posts will recognize the content.,
My incoming spam has one of two characteristics:
1) Spammer-controlled infrastructure using the spammer's identity for both SMTP MAILFROM and message FROM addresses. They rely on the fact that you probably don't recognize their identity and that you allow-by-default rule for unrecognized senders.
When you catch them, you need to be able to block based on any or all of: Source IP, Reverse DNS name (or portion), HELO name (or portion), SMTP domain, and From domain or full address. Many products do not examine or log all of these identifiers and therefore cannot filter on them. (Spammers do not change their host identity as often as you might expect, so blocking on host name is pretty effective at blocking all of their IP addresses even when you only know one address.)
2) Spam sent from email service providers like SendGrid.com
or MailChimp.com. In these cases, the service provider identity is in the SMTP MAILFROM address and the spammer identity is in the message FROM address. Some messages from these vendors will probably be essential to your organization, while others will be toxic, depending on the client identity. So you must have a product that can filter on From address, You need to be able to say that if the From address is your trusted electric utility you want the message whitelisted, but if it is from a known spammer then you want the message blacklisted. If the service provider has a really bad track record, you might decide to quarantine any new client of that service provider, so that you can check whether it is safe or hazardous, rather than finding out the hard way.
Eventually, you will find some message source that needs to be whitelisted. You need to be able to configure a whitelisting rule that allows messages from that sender without allowing spoofs of that sender to be whitelisted. That means you need multi-attribute whitelisting, meaning:
(a) the message has one or more identifiers, received together, which constitute the "fingerprint" for the trusted message source,
(b) at least one of those identifiers can be verified as true.
Possible verification methods are:
Source IP (assumed true),
HELO or Reverse DNS host name that forward confirms to the Source IP
SMTP MAILFROM that produces SPF PASS
Message FROM that produces DMARC PASS
For blacklisting, a single attribute match is usually sufficient reason to block a message. Too many products implement whitelisting the same way -- you pick a single identifier and say that it is trusted, without any ability to ensure that it is verified and without any ability to require multiple identifiers to be observed together.
Finally, you need an ability to apply filter rules in test mode, to collect data, without acting on them. Lot's of products lack this. So maybe you decide to block based on SPF or DMARC failures, only to discover that some of your most wanted traffic is triggering false positives. Find a product that allows you to detect your trusted-but-misconfigured senders in advance, so that you can implement a whitelist rule to workaround their defective SPF policy or missing DKIM signature. Better to know in advance than to discard an email that the company president considers essential.
Every spam filtering product should be able to do all of these things, because these are requirements that are inherent to the problem space, and we all face the same problems. Declude does most of these things well, and its customization capability allowed me to do the rest. It is free, so I gave up my search for a commercial solution. If you find one or more that can meet these criteria, I would love to know about it, either as a reply to this post or a personal message.