Antispam: Aggressive False Positives

Here’s a discussion point.

Some rules in almost all antispam solutions (indeed in some software almost all rules) cannot be turned on or off.
Some can be desensitised or their aggression lowered but they still remain active.
What do you do if they still collect false positives? Even worse, what if those false positives relate directly to your financial arm, credit control or remittence?

Support
First thing, of course is to escalate the issue through whatever support you have available for the product. You never know, there are often hidden features or obscure switches that control all sorts of things in software. Of course this is far less likely if your solution is SaaS based.
Workaround
If the product support are unable to provide a solution, ask them about workarounds.
The chances are you will be asked to use some sort of whitelist. Probably a sender whitelist, or approved senders.
On the face of it this seems a reasonable solution. But it has repercussions.
Problems with Whitelists
I can see three primary issues with whitelisting:

1. Spoofing
   The domain or addresses can be directly spoofed by spammers and your new approved sender rule bypasses all your checks.

2. Domain Trusts
   The vendor/customer has now been completely trusted by your domain. If they get hijacked and become a source of spam you won’t be blocking it. Indeed, you may never be aware if it, unless your users complain.

3. IP Trusts
   Even worse than whitelisting a domain can be whitelisting an IP Subnet. Now any mail from that array of machines will bypass your antispam. This is a favourite of marketing firms as it allows mail for all their customers through your filters.

Viruses
Don’t be afraid of viruses, though. Malware of all types should still be blocked. The antivirus portion should be applied independently of the antispam. It is an important question to ask your provider though.
SPF
Of course you could try implementing Sender Policy Frameworks. This indicates trusted sources for a particular domain.
But most of the time these are deny checks in support of the standard set of deny checks rather than allow rules. They simply help prevent spoofing of the senders domain. But they can contain a ‘maybe‘ option that is nearly always enabled that means most of the time they are fairly useless, unless the recipient insists on strict SPF interpretations.
However, if your antispam is good enough then you can specify which sender domains have SPFs applied and you can enforce it just on those domains. Perhaps you have the ability to do this IP limiting independently of SPFs. Of course if the sending domain changes it’s habits then you’ll end up blocking it.
Problems with IP Whitelists
Above all this you could trust the sending servers but this should only be done if they are unique to the specific sender you want to receive from. Many companies use third parties to filter/control/archive outbound mail and so this isn’t an option without allow all customers of that service. We live in a SaaS age so this is likely for the majority of large companies.
Then we have outsourced CRM, Finance, marketing (and required mass mailing) etc.
You can see the problems caused.
Recommendation

1. I think the only solution is to push the vendor as hard as you can to resolve any False Positives.
2. Whitelists of any sort should be used with caution but you may simply have no choice.
3. Never whitelist addresses in you own domain. Don’t even consider ever whitelisting your entire domain.
4. If you enable inbound SPF checks try to be strict with any that exist but SPFs won’t help get past the antispam but may add protection where Whitelists exist.
5. Only whitelist IPs or Subnets where the source can be trusted.
6. Seriously Consider changing antispam provider.

Not a good position to find yourself.