Handle false positives

A false positive is a finding that fired on content that is not sensitive; you fix it by confirming the report in Policy → Feedback, which adjusts the threshold for your organization, and by adding an exception or a tighter pattern when the same case keeps coming back.

Before you start

Compliance, Admin or Owner role to review feedback and edit policy.
The bounced message or the audit entry, so you can see which pack, pattern and confidence produced the finding.
A decision on who reviews feedback and how often; a weekly pass is enough for most offices.

Steps

When a rule set to warn bounces a message, the sender’s bounce includes a Report false positive link. Clicking it files the report under Console → Policy → Feedback. Held messages can be reported from Quarantine & holds when you release them.
Open the report. It shows the matched text with context, the pack or custom pattern, the confidence score and the rule that acted. Content is shown only to Compliance and Owner roles, and the view is logged.
Choose Confirm (a true false positive; the pack threshold for that pattern moves for your tenant only) or Reject (the finding was right; nothing changes).
For a recurring case, add an exception under Policy → Exceptions (recipient domain, sender group) or tighten the pattern under Policy → Custom with a validator or word boundary. Test it with the sample-message tester before saving.
Console → Reports → Detection shows precision per rule over the last 30 days. Check it after each change.

Verify

The Feedback queue is empty, the Detection report shows precision moving up for the pattern you touched, and a re-sent copy of the original message is delivered without a finding.

Troubleshooting

The same report keeps arriving from one sender. Cause: a legitimate internal number (invoice, claim, case number) has the same shape as an identifier in the pack. Fix: add a custom pattern with a validator for your number format and an exception for the sender group.
Confirming reports has not changed anything. Cause: the rule uses a custom pattern, which has a fixed confidence you set. Fix: edit the pattern’s confidence or regex under Policy → Custom; feedback only moves pack thresholds.
Staff stopped reporting and started using [PLAIN]. Cause: too many warn bounces. Fix: [PLAIN] is never honored for detected content; convert the noisy rule from warn to encrypt so mail flows, then clean up precision.
Precision looks low but no one has complained. Cause: a rule in test mode is logging findings without acting. Fix: review the findings in Reports → Detection before switching the rule on.

Example

Lakeside Family Dental, a 12-person office on Google Workspace, saw three warn bounces a day from insurance@. The audit entries showed the Social Security number pattern firing on a payer’s nine-digit claim reference in pre-authorization replies. The office manager confirmed the reports, then added a custom pattern for the payer’s claim format and an exception for that payer’s domain. The Detection report showed the SSN rule back above its previous precision within two weeks, and pre-auths with real patient identifiers still go out as locked delivery.

FAQ

Does confirming a false positive change detection for other customers?

No. Thresholds move for your organization only. We never train on customer data.

Can a sender see the content of their own report?

They see that it was filed. Only Compliance and Owner roles see the matched text, and every view is in the audit log.

Should I lower a threshold or add an exception?

An exception when the issue is one recipient or sender group; a threshold when the pattern is wrong for your whole organization.

How are false negatives handled?

Use a message should have been encrypted but wasn’t: the fixes are custom patterns, lower thresholds and the [SECURE] tag.

Still stuck? A human answers within 15 minutes on chat, 1 hour by email during business hours (24/7 for outages).