advanced hunting query for reported phish returns no results because the cluster was already purged

TL;DR

Query the evidence that survives a purge instead of the mailbox copy that does not: search EmailEvents and EmailUrlInfo for the delivery and post delivery events, widen the time window to before the purge, and use the network message ID from a user report to join the records. A purged cluster disappears from mailboxes and from some views, but its delivery telemetry remains, and hunting only in the wrong table makes a real campaign look like a user hallucination.

advanced hunting query for reported phish returns no results because the cluster was already purged

Use this when

• Users reported a phish with headers or screenshots, but an Advanced Hunting query for the subject or sender returns nothing.
• Message trace or quarantine shows the messages were purged or removed.
• You have at least one network message ID, sender, or URL from a report.

Not for this skill when

• The mail was rejected at the gateway before delivery. Hunt in gateway logs, not in delivery tables.
• No user can produce any artefact of the message. Treat as an unverified report and gather evidence first.

Steps

1. Take one user report and extract hard identifiers: network message ID, sender, subject, URL, and delivery time. 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: at least two hard identifiers are captured from a real report
2. Query EmailEvents for those identifiers across a window that starts before first delivery and ends after the purge. 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: delivery rows for the cluster appear in the results
3. Join EmailUrlInfo and EmailAttachmentInfo on the network message ID to recover URLs and attachments for the cluster. 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: the cluster URLs and attachment hashes are listed
4. Check the post delivery action fields to confirm which messages were purged, delivered, or are still present. 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: each cluster message is classified by its current state
5. Save the working query with the campaign notes so the next hunter can rerun it for related reports. 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: the saved query returns the cluster when rerun unchanged

Why it happens

Advanced Hunting tables record events, not current mailbox state, but each table has its own retention and its own view of a message. A purge removes the item, and queries written against mailbox or current state views then return nothing, even though delivery, URL, and attachment telemetry still describe the campaign completely. Hunters who start from the strongest identifier and the event tables reconstruct the cluster; hunters who search only by subject in the wrong place conclude it never existed.

Variants and edge cases

advanced hunting query reported phish no results cluster purged

The exact empty result situation hunters hit.

email events hunting purged phishing campaign network message id

The identifier join variant for event tables.

threat explorer no results user reported phish already removed zap

The purge linked variant naming ZAP as the remover.

Compatibility: Microsoft Defender for Office 365 Advanced Hunting EmailEvents, EmailUrlInfo, and EmailAttachmentInfo tables, KQL.

Edge cases to check:

• Retention differs per table; hunt promptly, because a cluster near the retention edge loses detail table by table.
• A subject search alone is fragile after a purge; message IDs and URLs are the durable keys.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VCm34ZFdkbK-3cVQuI8-6A