What Is Attachment Sandboxing (Detonation) in Email Security?

The short answer
Attachment sandboxing — also called detonation — opens a suspicious file inside an isolated virtual environment before it reaches your inbox. Security software watches what the file does: does it run macros, contact external servers, drop executables? Because this analysis takes time, it delays delivery of affected messages.
What is attachment sandboxing in email? Suspicious files are detonated in an isolated VM before delivery — how it works, why it delays mail, and what it misses.
On this page
What is attachment sandboxing in email security? It is the practice of opening a suspicious attachment inside a disposable virtual machine — isolated from any real system — and watching what the file actually does. If the file drops malware, phones home, or tampers with the simulated environment, the gateway blocks delivery. If it behaves cleanly across the observation window, the message is released to the inbox.
The term detonation borrows from controlled demolition: you trigger the device in a contained space to find out what it does before it can hurt anyone. Email sandboxing works on the same logic. Signature-based antivirus checks what a file is. Sandboxing checks what a file does.
Most enterprise email gateways — Microsoft Defender for Office 365's Safe Attachments, Google Workspace's security scanning, and third-party services such as Proofpoint TAP — offer some form of sandboxing. It is one layer of a defence stack, not a standalone solution.
How Attachment Sandboxing Works#
When a message arrives at an email security gateway, the gateway inspects each attachment. Files that pass a preliminary reputation check — known-clean hashes, trusted sender signals — are released immediately. Files that look suspicious enter the detonation pipeline.
- 1
File extracted and queued
The gateway strips the attachment from the message and passes the file to a sandboxing service. The original message is held in queue while analysis runs.
- 2
Isolated environment provisioned
A fresh virtual machine is spun up — typically running the most common target OS and Office version for that file type. A .docx triggers a Windows VM with a matching Word version.
- 3
File opened and monitored
The file is opened inside the VM. The sandbox records every system call: files created or deleted, registry keys written, network connections attempted, processes spawned. This is behavioural analysis, not signature matching.
- 4
Verdict rendered
If the file behaves cleanly across the observation window — typically 30 seconds to a few minutes — the gateway releases the message. If the file triggers a detection rule, the message is blocked or quarantined. The VM is discarded either way.
- 5
Delivery or quarantine
Clean messages are delivered, often with a small delay the recipient sees as a scanning notice. Blocked messages land in quarantine where an administrator can review them.
Why Sandboxing Matters: What Signature Scanning Misses#
Traditional antivirus works by matching a file against a database of known-bad signatures. A payload that has never been seen before — a zero-day exploit — has no signature. It walks straight through.
Sandboxing catches zero-days because it is indifferent to whether the file is known. It watches behaviour. A macro that tries to download a remote executable from an unusual domain triggers a detection rule whether or not that macro has ever been observed before.
Without sandboxing in the stack, the unprotected attack surface is everything the signature database has not yet catalogued. For targeted campaigns — spear-phishing against a specific executive with a custom payload written for that engagement — the signature database is always behind.
The time-to-signature gap
Sandboxing vs Antivirus Signature Scanning#
These two techniques are complementary, not competing. Most production gateways layer them: signatures run first (fast, cheap), and sandboxing runs on files that survive the signature check (slower, more compute-intensive). Understanding where each fits helps you evaluate gateway claims honestly.

| Dimension | Signature scanning | Attachment sandboxing |
|---|---|---|
| Detection method | Matches file hash or byte sequence against a known-bad database | Executes the file and observes runtime behaviour |
| Zero-day coverage | None — unknown samples have no signature | Yes — behaviour is detected regardless of prior exposure |
| Speed | Milliseconds — no delay to delivery | 30 seconds to several minutes — causes visible delivery delay |
| Resource cost | Low — a database lookup | High — a full VM per file, billed per detonation by most vendors |
| False-positive rate | Low — a signature is precise | Higher — benign macros can trigger heuristics |
| Evasion resistance | Low — obfuscate the payload, defeat the signature | Moderate — time-bombs and sandbox-detection techniques exist |
| Where it runs | Gateway, endpoint AV, mail server | Email security gateway (cloud or on-prem) |
Common Misconceptions About Attachment Sandboxing#
Sandboxing eliminates the risk of malicious attachments. It reduces that risk significantly but does not eliminate it. Attackers have developed sandbox-evasion techniques: time-bomb payloads that stay dormant until a specific date, mouse-movement checks that detect the absence of a real user, and environment fingerprinting that recognises common sandbox artefacts. A sophisticated attacker can write a payload that behaves cleanly inside the sandbox and activates only once it reaches a real machine.
Every attachment is sandboxed. Most services apply detonation selectively — to file types that are commonly weaponised (.docx, .xlsx, .pdf, .zip, .exe, .js) and to messages that passed preliminary checks but still look suspicious. Sandboxing every message at scale is cost-prohibitive, so gateways make triage decisions before detonating.
The delivery delay is a bug. It is an intentional trade-off. The alternative — delivering first and scanning asynchronously — means malicious files reach the inbox before the verdict arrives. Microsoft Defender's dynamic delivery feature threads this needle: it delivers the message body immediately but replaces the attachment with a placeholder while detonation runs, then swaps in the real file (or a quarantine notice) when the verdict is ready.
Sandboxing and quarantine are the same thing. Quarantine is the holding state for a message that failed a policy check. Sandboxing is one of the mechanisms that can inform that decision. A message can be quarantined after a signature match, after a sandbox verdict, or after a policy rule — quarantine is the outcome, not the detection technique.
How This Shows Up in AI Emaily#
AI Emaily is a mail client, not an email security gateway. Attachment detonation happens upstream — at Microsoft Defender for Office 365, Google Workspace's security layer, or a third-party gateway — before a message ever reaches the API that AI Emaily reads. By the time a message appears in your AI Emaily inbox, the sandbox verdict has already been rendered and acted on by the provider.
What AI Emaily does at the client layer is separate: its AI spam-protection feature runs additional classification on messages that reached the inbox, flagging suspicious senders, cold-email patterns, and phishing signals that slipped through upstream or that your organisation's gateway does not cover. It does not open attachments in a VM. If your security posture requires detonation, that is a gateway configuration, not a mail-client feature. We build AI Emaily — see /features/spam-protection for what the client-layer filtering actually does, and /pricing for trial terms.
Frequently asked
See it in AI Emaily
Keep reading
Sources

Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.