The best way would be to first check in MAL for the record associated with that message.This will show you the complete list of rules and policies that fired on the email, as well as the list of policies that were skipped/bypassed.This will help you determine if it is getting caught by some local policy that has an action of "treat as spam".(releasing a message from the spam quarantine will have no effect on any local policies or customer specific rules).IF it is getting caught by a local policy, then you can adjust that policy.IF it is getting caught by a Customer Specific Rule, then you can use the provided interface to kill the CSR.IF it is getting caught by a global policy, and you release the message from Spam Quarantine, then an FP submission will be generated and sent. These submissions go into a pool and are evaluated, but there is not 100% guarantee that the global rule will be killed/deleted, since the lifecycle of global rules is dependent on global, not customer specific, feedback.(If it did, then you could get the scenario where a spammer purchased a cheap license and procedded to submit FPs against rules that were catching his/her spam messages)Also note that even if a global rule is killed/removed there is a possibility that it will be re-activated, based on global statistics.Final thing to take into account is latency: individual rulesets "generally" update every 5-7 minutes (some rulesets take longer). Assuming a rule WAS killed, it will take some time for the new ruleset to be propagated out to your installation.Recap:Check the Message Audit Log to get the bare truth.Start "locally": local policies, local black/white lists, Customer Specific Rules, etc. and work "outward".If it turns out to be a global rule, submit as an FP.If you still don't get the result you are happy with, open a support case.If it is business impacting, you might want to consider implementing a local policy to mitigate the impact while you are working with customer support.Hope this was useful.