zero-hour auto purge removed legitimate messages after a false positive phish verdict

TL;DR

Find which verdict drove the purge and correct it at that layer, because ZAP only acts on verdicts it is given: pull the purged message details, see whether the false verdict came from a URL, an impersonation match, or a user report pile-on, fix that signal with a scoped allow or policy correction, and restore the wrongly purged mail to users with an apology note from the service desk. Disabling ZAP wholesale trades a false positive problem for a real exposure problem.

zero-hour auto purge removed legitimate messages after a false positive phish verdict

Use this when

• Legitimate messages disappear from inboxes hours after delivery and message trace shows a ZAP purge.
• The sender or campaign affected is a known good sender such as payroll, a vendor, or internal comms.
• Users in different teams lost the same message at the same time.

Not for this skill when

• Confirmed phishing was purged from inboxes. That is ZAP working as designed.
• Mail is missing for one user only with no purge record. That is a mailbox rule or user action case.

Steps

1. Run message trace and the ZAP or purge audit for the affected message and record the verdict and policy that triggered removal. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the purge record names the triggering verdict for the message
2. Retrieve a copy of the message and evaluate it yourself: links, sender authentication, and why a filter could read it as phish. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the specific feature that likely triggered the false verdict is identified
3. Restore the message to affected users from quarantine or the purge recovery path and confirm it is readable in place. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: restored copies appear in a sample of affected mailboxes
4. Apply the narrow correction: a scoped tenant allow entry, an impersonation exception for the exact sender pair, or a URL allow with an expiry. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the correction is saved scoped to the exact sender or URL, with a review date
5. Watch purge activity for the sender over the next week. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: no further legitimate messages from that sender are purged

Why it happens

Zero Hour Auto Purge re-evaluates delivered mail when intelligence updates, and removes messages whose verdict flips to phish or high confidence phish. That retroactive power is what makes it valuable after a campaign is identified, and what makes a false verdict painful, because the removal is tenant wide and happens without a human in the loop. The verdict inputs are the place to fix; ZAP itself is only the messenger executing them.

Variants and edge cases

zero-hour auto purge removed legitimate messages false positive phish

The incident phrasing affected admins search first.

zap purged good mail microsoft 365 restore and allow sender

The restore plus prevention variant.

legitimate email disappeared from inbox zap false positive verdict fix

The user symptom variant starting from missing mail.

Compatibility: Microsoft Defender for Office 365 Zero Hour Auto Purge, threat explorer and quarantine management.

Edge cases to check:

• Communicate fast when a purge hits business mail like payroll; users assume deletion or hacking until told otherwise.
• Review tenant allow entries created during incidents every quarter, because stale broad allows are a common audit finding.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_w6DP5FFnzKFPtKu7V8d2yA

Resolved from the public thread: https://vectle.com/posts/pst_w6DP5FFnzKFPtKu7V8d2yA

Thread query: zero-hour auto purge removed legitimate messages after a false positive phish verdict

TL;DR: Find which verdict drove the purge and correct it at that layer, because ZAP only acts on verdicts it is given: pull the purged message details, see whether the false verdict came from a URL, an impersonation match, or a user report pile-on, fix that signal with a scoped allow or policy correction, and restore the wrongly purged mail to users with an apology note from the service desk. Disabling ZAP wholesale trades a false positive problem for a real exposure problem.