Restoring email is routine until the restored message is the phish that was just removed, or the mailbox comes back with the attacker's rules still in it. D3-RE Restore Email is the MITRE D3FEND countermeasure for giving a user back access to an email. D3FEND defines it as "Restoring an email for an entity to access", places it in the Restore tactic under D3-RF Restore File (itself under Restore Object, D3-RO), and cites CISA's Cybersecurity Incident and Vulnerability Response Playbooks as its reference. It is the counterpart of D3-ER Email Removal. This card covers the three situations that lead to an email restore, the platform features that perform it, how to verify a restore is safe and the mistakes that re-deliver the threat. It is written for messaging administrators, security operations and incident responders. Platforms are listed alphabetically.
Key takeaways
- Three situations, three risks. Releasing a message a filter held, recovering mail a user or attacker deleted, and rebuilding a mailbox after mass deletion each need different checks.
- Release only after a verdict. A quarantined or purged message is restored after analysis shows it is clean, never on the recipient's request alone.
- Deleted mail is evidence. Attackers in a mailbox delete replies and warnings; recovering those messages supports both the user and the investigation.
- Retention windows decide what is possible. Native recovery windows are measured in days, so holds or a separate backup are needed for anything older.
- D3FEND's ATT&CK links are inferred from the Email artefact. They include T1114.001, T1534, T1566.001, T1566.002 and T1667, plus ICS technique T0865.
D3-RE at a glance
| Field | D3-RE Restore Email |
|---|---|
| D3FEND ID | D3-RE |
| Tactic | Restore |
| Parent technique | Restore File (D3-RF), under Restore Object (D3-RO) |
| Digital artefact | Email (D3FEND: the technique "restores" an Email, defined as a document sent between computer users across computer networks) |
| Reverses | D3-ER Email Removal, filter quarantine, user or attacker deletion |
| D3FEND reference | CISA: Cybersecurity Incident and Vulnerability Response Playbooks (November 2021) |
| Main risk | Re-delivering a malicious message, or restoring a mailbox without removing attacker changes |
ATT&CK techniques D3FEND relates to D3-RE
Relationship type: inferred only. D3FEND relates D3-RE to ATT&CK because these techniques read or produce the Email artefact that D3-RE restores. D3FEND states its offensive mappings "are inferred, experimental, and will improve as the knowledge graph grows" (checked November 2026). All IDs were checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation to Email | What it means for a restore (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1566.001 | Spearphishing Attachment | Produces | Removed messages must stay removed; release only clean messages from the same campaign |
| T1566.002 | Spearphishing Link | Produces | Check links at release time, not just at first delivery |
| T1534 | Internal Spearphishing | Produces | Messages from a compromised internal mailbox look legitimate; check the sender's account status before releasing |
| T1667 | Email Bombing | Produces | Legitimate mail buried or removed in bulk clean-up may need restoring selectively |
| T1114.001 | Local Email Collection | Reads | Restored mail stores and exports are themselves collection targets; protect them |
| T0865 (ICS) | Spearphishing Attachment | Produces | The same release discipline applies to mail reaching operational technology staff |
D3FEND does not list them, but two further techniques often drive a restore: T1070.008 Clear Mailbox Data, where an attacker deletes messages to hide activity, and T1564.008 Email Hiding Rules, where inbox rules move or delete messages. See MITRE ATT&CK T1566 Phishing, MITRE ATT&CK T1534 Internal Spearphishing and T1114 Email Collection Defensive Guide.
Three restore situations
| Situation | Typical cause | Check before restoring |
|---|---|---|
| Release from quarantine or reverse a removal | Filter false positive, over-broad purge during a phishing response | Analyst verdict on the message, current URL and attachment reputation, and whether the sender's account is compromised |
| Recover deleted messages | User error, or an attacker deleting replies and alerts to hide fraud | Preserve the deleted items as evidence first; review inbox rules and forwarding before returning mail |
| Rebuild a mailbox | Mass deletion, ransomware against synchronised clients, account deletion | Restore from holds or backup to a clean account with credentials reset; see D3-RUAA Restore User Account Access |
Where it is implemented
Email platforms provide restore at three levels: quarantine release, recovery of deleted items within a retention window, and restore from holds, archives or third-party backup. The table names documented features for two widely used platforms.
| Platform | Quarantine release | Deleted mail recovery |
|---|---|---|
| Google Workspace | Admin quarantine dashboard (Gmail, Manage quarantines): messages in Pending triage can be released for delivery or denied. Unactioned messages are deleted after the quarantine retention period | Deleted messages stay in Trash for 30 days; after that an administrator has a further 25 days to restore them through Users, Restore data, selecting Gmail and a date range. Restored mail appears in the inbox, the restore cannot be paused, and Google advises placing a Vault hold before restoring where Vault is used |
| Microsoft 365 | Defender for Office 365 quarantine: administrators release, deny or preview messages and can submit false positives. Released mail is re-delivered rather than restored in place. Zero-hour auto purge always quarantines delivered messages later judged malware or high confidence phishing, and recipients can only request release of those | Exchange Online keeps deleted items in the Recoverable Items folder for 14 days by default, configurable up to 30. With single item recovery or Litigation Hold, purged items are kept in the Purges subfolder and remain recoverable by administrators through eDiscovery or Content Search |
Both platforms document that native windows are limited. Holds, retention policies or a separate backup are the way to keep restorable copies for longer, and they need their own access controls because they hold every message. Recipients being able to release their own quarantined mail is a configuration choice; for phishing and malware verdicts keep release with administrators.
Allow entries created during release
Releasing a message as a false positive can also create an allow entry for the sender, URL or attachment. In Microsoft 365 such entries default to expiry 45 days after last use. An allow entry created for a sender whose account is later compromised lets the next phish through, so record who created each entry and review them.
Implementation steps
- Set release rules. Define who may release which quarantine verdicts, and keep phishing and malware releases with the security team.
- Analyse before release. Preview the message safely, check URLs and attachments again and confirm the sender's account is not compromised. See D3-UA URL Analysis.
- Preserve evidence. Before recovering deleted mail in an investigation, place a hold or export the items so the restore does not alter the record.
- Clean the mailbox. Remove attacker inbox rules, forwarding and delegates before returning recovered messages. See the Business Email Compromise Response Playbook.
- Restore selectively. Use date ranges and searches to restore only the messages needed, not the whole mailbox.
- Tell the user. Users are not always told when messages are moved by automated purge, so explain what was restored and why.
- Keep rollback ready. If a released message proves malicious, remove it again with D3-ER and block the sender or URL.
How to verify the restore
- Verdict recorded: every released message has an analyst decision linked to the case.
- Completeness: the restored items match the evidence export by count and date range.
- Mailbox state: no unexplained rules, forwarding or delegates remain.
- Allow list hygiene: new allow entries from the release are reviewed and time-limited.
| Metric (example, not a standard) | What it shows | Direction |
|---|---|---|
| Released messages later reclassified as malicious | Quality of release decisions | Zero |
| Median time from release request to decision | Business impact of quarantine | Falling |
| Phishing and malware releases made by recipients | Release policy enforced | Zero |
| Restore requests that fell outside the native retention window | Need for holds or backup | Zero |
| Allow entries older than their review date | Allow list drift | Zero |
Limits and failure patterns
- Release on request: the user asks for the "missing invoice" and receives the phish.
- Releasing a whole campaign: one message is confirmed clean and similar ones are released without checks.
- Restoring into a compromised mailbox: recovered mail flows straight back to the attacker through a forwarding rule.
- Window missed: mail deleted weeks earlier is beyond native recovery and no hold or backup exists.
- Evidence altered: recovering items without preserving them first changes the state investigators rely on.
- Permanent allow entries: false-positive allows outlive the reason they were created.
Framework mapping
| Framework | Reference | Relationship to D3-RE |
|---|---|---|
| NIST SP 800-53 Rev 5 | CP-9 System Backup, CP-10 System Recovery and Reconstitution | Backup and recovery of mailbox data |
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling | Recovery after a phishing or mailbox compromise |
| NIST SP 800-53 Rev 5 | SI-12 Information Management and Retention | Retention windows and holds that make restore possible |
| MITRE ATT&CK mitigation | M1053 Data Backup | Closest in intent |
D3FEND cites only the CISA playbook for D3-RE; the other rows are NHI Mgmt Group's mapping by intent.
Practitioner checklist
- Keep phishing and malware quarantine release with the security team.
- Re-check URLs, attachments and sender account status before every release.
- Preserve deleted mail before restoring it during an investigation.
- Remove attacker rules, forwarding and delegates before returning mail.
- Restore selectively by date range and search.
- Know the native retention windows and add holds or backup where they fall short.
- Time-limit and review allow entries created on release.
Standards and references
- MITRE D3FEND: Restore Email (D3-RE)
- CISA: Cybersecurity Incident and Vulnerability Response Playbooks (D3FEND reference)
- Google: Restore a user's permanently deleted email
- Google: Manage quarantined messages
- Microsoft: Recoverable Items folder in Exchange Online
- Microsoft: Manage quarantined messages and files as an admin
- Microsoft: Zero-hour auto purge in Exchange Online
Related NHI Mgmt Group resources: D3-ER Email Removal · Phishing Incident Response Playbook · Email Security Guide · MITRE D3FEND Guide