A phishing message that one user reported is usually sitting unread in dozens of other mailboxes, and every copy left behind is another chance for someone to open the attachment or click the link. MITRE D3FEND names the countermeasure Email Removal (D3-ER) and defines it as "The email removal technique deletes email files from system storage." It sits under the Evict tactic as a child of File Eviction (D3-FEV), which in turn sits under Object Eviction (D3-OE), and D3FEND gives it the synonym Email Deletion. This card explains what D3-ER does, which ATT&CK techniques D3FEND relates it to, how mail platforms implement it, and how to prove that every copy is gone. It is written for SOC analysts, incident responders and messaging administrators who already know the material in the Email Security Guide.
Key takeaways
- Removal is an eviction step, not the whole response. D3FEND's own considerations say the organisation may also block the sources or notify providers rather than relying only on deletion.
- Find every copy before you delete any. D3FEND warns that email propagates across many storage systems over time, so early detection avoids latent stores of malicious content: forwarded copies, shared mailboxes, archives and journal stores.
- Automatic and manual removal work together. Post-delivery purge features move newly convicted messages without an analyst, while search-and-purge handles the campaign a user reported.
- Soft delete first, hard delete with intent. A soft delete keeps a recovery path if the search matched legitimate mail; a hard delete removes the copy from the user but recovery and holds still apply, so plan evidence preservation first.
- Verify with a second search. The proof that removal worked is a rerun of the same query returning zero items in user-visible folders, recorded in the incident ticket.
D3-ER at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-ER (d3f:EmailRemoval), synonym Email Deletion |
| Tactic | Evict |
| Parent technique | File Eviction (D3-FEV), under Object Eviction (D3-OE) |
| Digital artefacts | Email (relation: deletes); Mail Server (relation: may-access) |
| D3FEND reference | US patent 11368475 B1, "System and method for scanning remote services to locate stored objects with malware" (FireEye, granted 21 June 2022) |
| What it changes | Removes malicious or suspicious messages from local and remote mail folders |
| Typical tools | Post-delivery purge in the mail service, admin search-and-purge, security investigation consoles, SOAR playbooks |
| Main limitation | Removes the message, not what the message already did: opened attachments, entered credentials and created inbox rules need their own response |
How it works
D3FEND describes Email Removal as a way to prevent a user from executing malware or responding to phishing. Security software, or users themselves, detect a malicious or suspicious message in a local or remote mail folder and the technique removes it. The cited patent describes the automated form: a service is authorised against the remote mail or file store (the patent describes an OAuth 2.0 style grant), retrieves stored messages, screens them for suspicious traits such as a URL in the body or a small attachment, classifies each as malicious or benign, and reports the affected objects so the customer can request deletion, disinfection or quarantine.
In practice every implementation has the same three parts.
- Scope: a query that finds every copy of the campaign. Good queries combine several indicators: sender address, sending IP, subject, attachment hash, URL domain and a received-date window. A single indicator either misses variants or catches legitimate mail.
- Action: move to quarantine, move to Junk, soft delete or hard delete. Quarantine keeps the item under admin control; soft delete keeps a recovery path; hard delete removes it from the user's view.
- Record: who approved the action, how many items it touched, and which failed. Without a record you cannot answer the post-incident question "was every copy removed?".
D3FEND also recommends a route for users to report suspicious messages to the security team. User reports are often the first signal that starts a manual removal, so the report button and its triage queue belong to this control.
ATT&CK techniques D3FEND relates to D3-ER
Relationship type: inferred only. D3FEND marks these mappings "inferred, experimental" and derives them from the two artefact relations: D3-ER deletes Email and may access Mail Server (checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK tactic | ID and technique | What removal achieves |
|---|---|---|
| Initial Access | T1566.001 Spearphishing Attachment | Unopened copies of the lure are taken out of reach before more users open them |
| Initial Access | T1566.002 Spearphishing Link | Same, for messages carrying the malicious link |
| Lateral Movement | T1534 Internal Spearphishing | Phishing sent from a compromised internal mailbox is removed from colleagues' inboxes, where it is most trusted |
| Collection | T1114.001 Local Email Collection | Shares the Email artefact: removing sensitive or malicious mail reduces what a local collector finds; the main counter is endpoint control |
| Collection | T1114.002 Remote Email Collection | Shares the Email and Mail Server artefacts; the real counter is revoking the attacker's mailbox access |
| Persistence | T1505.002 Transport Agent | Shares the Mail Server artefact; removing messages does not remove a malicious transport agent, which needs server-side eviction |
Read the last three rows carefully. D3-ER genuinely counters the phishing rows. For email collection and transport agents the link is the shared artefact, and the eviction that matters is removing the attacker's access or the server component. For those, see the T1114 Email Collection Defensive Guide and the T1505 Server Software Component Defensive Guide. On on-premises Exchange Server, Microsoft documents Get-TransportAgent for listing the transport agents installed per service (Hub, FrontEnd, Edge and the mailbox transport services), which is where a T1505.002 review starts.
Where it is implemented
| Implementation class | What it does | Trigger | Fits when |
|---|---|---|---|
| Post-delivery automatic purge | The mail service reclassifies already delivered mail when its verdict changes and moves it to quarantine or Junk | New signature or reputation verdict | Always on as a baseline in cloud mail |
| Admin search and purge | A compliance or investigation search scopes the messages, then a delete action removes them | Analyst decision after a report or alert | Targeted removal of a known campaign |
| Security investigation console | Threat hunting views with move and delete actions, approval and action history | Analyst or automated investigation | A SOC that wants approvals and an audit trail in one place |
| Third-party API-connected scanners | Connect to the mail store by API and remove or quarantine convicted items, as in the D3FEND reference patent | Scanner verdict | A second opinion beside the native filter, or mixed mail platforms |
| Endpoint and mail client removal | Endpoint protection removes malicious message files from local stores and caches | Endpoint detection | Local mail files and offline caches the server-side purge cannot reach |
Platform features
Platforms are listed alphabetically. These are customer-side settings and actions documented by each vendor as of November 2026.
- Google Workspace: the security investigation tool's Gmail messages data source offers the actions Delete messages, Restore messages, Mark message as spam, Mark message as phishing, Send message to inbox and Send message to quarantine. Bulk actions can cover the current page or all results; action status appears in a Result column and under Tasks in the Admin console, and results can be exported. Availability: Google lists Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium for the security investigation tool.
- Microsoft 365: zero-hour auto purge (ZAP) acts on delivered mail from the last 48 hours, quarantining malware and high confidence phishing whether read or unread, and acting on spam only while unread. Admin removal uses the Remediate actions (Move to junk folder, Move to inbox, Move to deleted items, Soft delete, Hard delete) from Threat Explorer or automated investigation, tracked in Action center History for 30 days and requiring the Search and Purge role. Availability: ZAP for email needs no special licence; the remediation workflow in Explorer is documented for Defender for Office 365 Plan 2.
Both platforms act on mail stored in their cloud mailboxes. On-premises mailboxes, local client caches and external archives need their own removal step, which is why the scoping stage lists every store.
Implementation steps
- Turn on and review automatic purge. Confirm post-delivery purge is enabled for malware and phishing, and check which allow lists or mail flow rules override it. Overrides are the most common reason a convicted message stays in place.
- Grant removal rights narrowly. Give the delete role only to the incident responders who need it, use two-step approval where the platform offers it, and log every action. A purge right is powerful enough to destroy evidence or business records.
- Write the scoping query from several indicators. Combine sender, subject, attachment hash or URL and a date window. Run it as a search only and review a sample of hits before any action.
- Preserve evidence first. Export one or more copies of the message with full headers to the case store before deletion. The Email Forensics and Header Analysis Guide covers what to keep.
- Act in the reversible mode. Use quarantine or soft delete for the first pass. Hard delete is for confirmed malicious content where the recovery path itself is a risk.
- Cover the other stores. Shared and service mailboxes, journal and archive copies, mobile and desktop client caches, and any on-premises servers. Retention holds will keep copies the user cannot see; that is expected and should be noted in the case.
- Follow up beyond the message. Block the sender, domain and URLs, reset credentials for anyone who submitted them, and check for new inbox rules created after the click. The How to Audit Mailbox Forwarding and Inbox Rules guide covers that check.
- Roll back if the scope was wrong. Restore soft-deleted or quarantined items with the platform's restore or move-to-inbox action, and record why.
How to verify it works
- Rerun the search: the same query should return zero items in user-visible folders after the action completes. Record the before and after counts.
- Read the action log: check per-message results for failures and "already in destination" outcomes, and re-run the action for the failures.
- Check click and open telemetry: removal is fastest when it beats the first open. Compare delivery time, first click and removal time for each campaign.
- Test the pipeline: in an exercise, send a harmless test message to a group, then run the full report, scope, preserve and purge workflow and time each stage.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Time from first report to campaign removal | Under 60 minutes | Every minute left in inboxes is another chance of a click |
| Copies remaining after removal search | Zero in user-visible folders | Direct proof of eviction |
| Campaigns with evidence exported before deletion | 100% | Investigation and notification decisions depend on it |
| Clicks or opens after the removal action time | Zero | Shows removal reached the cached and forwarded copies |
| Share of malicious mail removed automatically versus manually | Tracked monthly | Rising manual share points at overrides or tuning gaps |
Limits, bypasses and failure patterns
- Allow lists that override the purge: safe sender lists and mail flow rules can stop automatic purge acting, so a phishing message from an allow-listed domain stays in place.
- Per-mailbox and volume limits: admin purge tools cap what one action can remove. Microsoft's cmdlet-based search and purge procedure, for example, removes at most 10 items per mailbox per action, so large campaigns need the investigation workflow or repeated actions.
- Single-indicator queries: a subject-only search misses variants and can remove legitimate mail with the same subject. Use several indicators and review the sample.
- Deleting before preserving: once the only copy is gone, header analysis and scoping of other recipients become guesswork.
- Treating removal as containment: if a user already entered a password, the mailbox may now be the attacker's. Pair removal with the steps in the Business Email Compromise Response Playbook.
- Forgetting non-email channels: the same lure often arrives through chat platforms. Microsoft documents ZAP for Teams messages separately, and other collaboration tools need their own removal route.
Where identity fits
Removal at scale runs through privileged access: an admin role with a purge right, or an application granted mailbox-wide API access for a scanner or SOAR playbook. That app registration or service account can read and delete every mailbox, so treat it as a high-value non-human identity: scoped permissions, a named owner, credential rotation and alerts on use outside playbooks. The AI Agent Email Access Security guide covers the same risk for automated agents with mailbox rights.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling | Eradication is a stage of incident handling; removal of malicious mail is one eradication action |
| NIST SP 800-53 Rev 5 | SI-8 Spam Protection, SI-3 Malicious Code Protection | Mechanisms that detect and act on unsolicited and malicious messages |
| NIST CSF 2.0 | RS.MI-01, RS.MI-02 | Incidents are contained; incidents are eradicated |
| CIS Controls v8.1 | Control 9 Email and Web Browser Protections; Control 17 Incident Response Management | Email protections and the response process that calls removal |
| MITRE D3FEND | D3-OE, D3-FEV, D3-ER | Hierarchy from the broad eviction class to email removal |
For the CIS controls in depth see the CIS Control 9 Email and Web Browser Protections Guide.
Related countermeasures
- File Eviction (D3-FEV): the parent technique, for malicious files outside mail stores. See D3-FEV File Eviction.
- Email Filtering (D3-EF): the Isolate technique that stops the message before delivery; removal handles what filtering missed.
- Restore Email (D3-RE): the Restore technique that returns wrongly removed mail.
- Session Termination (D3-ST): ends sessions an attacker obtained through a phishing click. See D3-ST Session Termination.
Practitioner checklist
- Confirm automatic post-delivery purge is on and list every allow list or rule that overrides it.
- Restrict the purge role to named responders and use two-step approval where available.
- Keep a documented user reporting route for suspicious mail and triage it daily.
- Scope with several indicators and review a sample before acting.
- Export evidence with full headers before any deletion.
- Use quarantine or soft delete first; hard delete only with a recorded reason.
- Cover shared mailboxes, archives, client caches and on-premises stores.
- Rerun the search after action and record before and after counts.
- Follow removal with sender blocking, credential resets and inbox rule review.
Standards and references
- MITRE D3FEND: Email Removal (D3-ER)
- Google Patents: US11368475B1 System and method for scanning remote services to locate stored objects with malware
- Microsoft Learn: Zero-hour auto purge in Microsoft Defender for Office 365
- Microsoft Learn: Remediate malicious email delivered in Office 365
- Microsoft Learn: Search for and delete email messages
- Microsoft Learn: Get-TransportAgent
- Google Workspace: Take action based on search results
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: MITRE ATT&CK T1566 Phishing · MITRE ATT&CK T1534 Internal Spearphishing · Email Gateway and Message Trace Detection Guide · Incident Response Guide · MITRE D3FEND Guide