Protecting a Trusted Lab Sender Without Whitelisting the World

A sender-address allow list is weak because the From header is trivial to spoof, and the partner domain has already been spoofed. It also does not reliably address an IP-based DNSBL hit when the partner uses multiple sending IPs. Instead, use an IP policy or access control rule that matches the published 198.51.100.0/24 range and applies a dedicated antispam profile. In that profile, disable the DNSBL and SURBL checks that are producing the false positives, keep SPF, DKIM, and DMARC validation active, and retain antivirus and content scanning. Because the exception is tied to source IP, a spoofed message from an unrelated network still receives normal antispam treatment. Confirm that the partner's DKIM signature validates and that SPF passes before treating the range as trusted. Log matches to the exception and review volume periodically so a compromised partner host does not become a free pass.

The content rule is too broad. Matching the single word 'result' will hit legitimate clinical language and many ordinary messages. Replace it with a specific dictionary or regular expression that combines a relevant phrase with attachment or recipient context, and test it against a sample corpus before enabling it. Scope the content profile to the policy where it is needed rather than applying it globally. The antivirus discard action is also too aggressive for encrypted archives. FortiMail cannot scan inside a password-protected ZIP, so treating every encrypted archive as a virus destroys legitimate studies. Change the action to quarantine, notify the recipient or service desk, and define an approval process for release. The trade-off is that a malicious encrypted archive may sit in quarantine until reviewed, so the service desk needs clear handling and timely response. Do not disable antivirus globally or allow all encrypted archives from all senders.

Use role-based administration rather than sharing a super-admin account. Create an administrator or quarantine-management role limited to the relevant domain or quarantine area, with permission to view and release quarantined messages but not to change antispam profiles, policies, or system settings. If recipients should handle their own legitimate false positives, enable personal quarantine access for the appropriate user group and provide instructions. Log every release and review the audit trail regularly. Restrict service desk accounts with strong authentication and separate named accounts so actions are attributable. Define what may be released without escalation, such as known partner lab reports, and require security review for encrypted archives or messages with suspicious attachments. This preserves scanning while giving the business a controlled path to recover false positives.