8.5 Zero-Hour Auto Purge (ZAP)
Zero-Hour Auto Purge (ZAP)
By the end of this subsection, you will understand how ZAP works as post-delivery remediation, know the gap it creates and how to monitor it, and track ZAP actions with KQL.
How ZAP works
ZAP is the safety net. When an email passes all scanning at delivery but is later identified as malicious (new threat intelligence, updated ML model, manual submission analysis), ZAP retroactively removes or moves it from the user’s mailbox.
The ZAP sequence:
- Email delivered to inbox (passes all scanning at delivery time)
- Hours later: Microsoft threat intelligence updates the URL/file verdict to malicious
- ZAP checks all delivered emails against the updated verdict
- ZAP takes action: moves to Junk, soft deletes, or replaces the email
ZAP actions
| Action | What happens | When used |
|---|---|---|
| Move to Junk | Email moved to Junk folder | Spam verdict update |
| Soft delete | Email moved to Deleted Items, then to Recoverable Items | Phishing or malware verdict update |
| Quarantine | Email moved to quarantine | High-confidence phishing verdict |
The ZAP gap
ZAP is not instant. In Module 13, ZAP removed 4 of 23 phishing emails — but only 23 minutes after delivery. During those 23 minutes, 7 users clicked the link and 5 reached the phishing proxy. This is the ZAP gap: the time between email delivery and ZAP action.
A 23-minute gap means 23 minutes where users can interact with the phishing email. Click rates for phishing emails peak in the first 5-10 minutes after delivery. ZAP at 23 minutes catches some users (those who had not yet opened the email) but misses the fast clickers. Your goal is to minimize the gap through better initial detection (anti-phishing thresholds, Safe Links) and faster verdict updates (first contact safety tips, user reporting).
Monitoring ZAP with KQL
| |
| ZapAction | Date | ZapCount | AvgDelayMinutes |
|---|---|---|---|
| SoftDelete | Mar 20 | 8 | 34 |
| MoveToJunk | Mar 20 | 12 | 18 |
| SoftDelete | Mar 19 | 4 | 47 |
ZAP configuration and interaction with other controls
ZAP is enabled by default for all Exchange Online mailboxes. It is not a policy you configure per se — but its behavior is affected by other configurations:
| Factor | Impact on ZAP |
|---|---|
| Anti-phishing policy action | If your policy delivers phishing to Junk (not quarantine), ZAP moves the email from Inbox to Junk. If policy quarantines, ZAP moves to quarantine. |
| Transport rules | Emails that match a transport rule “stop processing” condition bypass ZAP — the transport rule takes precedence |
| User-moved emails | If a user moves the email to a custom folder, ZAP behavior varies — it may not be able to act on emails in certain folder types |
| Mailbox on litigation hold | ZAP removes the email from the user’s view but preserves it in Recoverable Items for compliance |
If your initial detection catches 95% of phishing at delivery, ZAP catches some of the remaining 5% post-delivery. But ZAP cannot catch 100% of what initial detection misses — its effectiveness depends on when Microsoft's threat intelligence updates the verdict. The strongest email protection minimizes reliance on ZAP by maximizing initial detection: aggressive thresholds, comprehensive Safe Links, and transport rules.
Correlation: ZAP + Safe Links + initial detection
The three controls work in sequence:
- Initial detection blocks emails at delivery (best outcome — user never sees the email)
- Safe Links protects at click time (user received the email but the URL is scanned when clicked)
- ZAP removes post-delivery (user received and potentially read the email, but it is removed before further interaction)
The Module 13 timeline illustrates this: initial detection caught 0 of 23 (CAPTCHAed URL). Safe Links warned 7 clickers (5 clicked through). ZAP removed 4 after 23 minutes. The 19 that remained in inboxes were the exposure window. Each control layer reduces the exposure, but none alone is sufficient.
ZAP effectiveness over time
Track ZAP’s contribution to your overall email security over 30 days:
| |
| Week | TotalZAP | PhishZAP | MalwareZAP | SpamZAP |
|---|---|---|---|---|
| Week 1 | 23 | 8 | 3 | 12 |
| Week 2 | 18 | 5 | 2 | 11 |
| Week 3 | 47 | 31 | 1 | 15 |
| Week 4 | 14 | 4 | 1 | 9 |
Try it yourself
ZAP removed the email but cannot undo what the user already did. For each user who read the email:
1. Check UrlClickEvents: Did they click a link in the email?
2. Check SigninLogs: If they clicked a phishing link, check for suspicious sign-in activity (token replay, new IP, new location).
3. If credentials may have been entered: Revoke sessions, reset password, force MFA re-registration — the containment sequence from Module 13.7.
ZAP handling the email is not the end of the investigation. It is the start — ZAP tells you the email was malicious, but you must determine whether any user acted on it before removal.
Check your understanding
1. ZAP removed 4 of 23 phishing emails. Why not all 23?