Domain reputation blocklists are fast and cheap to check. A URL arrives in an email; your security stack queries a reputation database; it gets a clean or blocked verdict in under a millisecond. For URLs that have been seen before and scored as malicious, this works exactly as intended.
The problem is the lag. A malicious domain registered this morning has no reputation score yet. It may stay unscored for hours — long enough for a targeted phishing campaign to run through its entire intended victim list before the first blocklist entry appears. URL sandboxing, also called detonation-based analysis, was developed specifically to close this time-window gap: instead of asking whether a URL is known to be bad, it asks whether the URL behaves maliciously when actually visited.
This article covers how URL detonation works technically, where it succeeds and where it has limits, and what it means for your phishing detection stack.
How Detonation-Based Analysis Works
When a message arrives containing URLs and routes to detonation inspection, the process runs roughly as follows:
1. URL extraction and normalization. All URLs in the email body, headers, and any linked HTML are extracted and normalized — expanding shortened URLs through initial resolution, stripping tracking parameters that don't affect destination, and de-obfuscating any encoding (percent-encoding, HTML entities, Unicode lookalike characters in the domain portion).
2. Isolated environment instantiation. A sandboxed browser instance is created in an isolated environment — a virtual machine or container with no access to the production network, no cookies or credentials pre-populated, and instrumented to capture all network requests, DOM mutations, JavaScript execution, and navigation events. The isolation is critical: a malicious page that attempts to install malware or exfiltrate data runs into a walled environment with nothing valuable to exfiltrate.
3. Controlled page load and behavioral capture. The URL is loaded in the sandboxed browser. The sandbox captures: all redirect chains (including server-side 301/302 and JavaScript-initiated redirects), the final destination domain and page content, any form fields that request credential input, any JavaScript that attempts to execute system commands, any network requests to known command-and-control infrastructure, and resource loading from known-malicious CDN patterns.
4. Behavioral scoring and verdict. The captured behavior is scored against indicators of compromise: credential harvesting forms, download prompts for executable files, DNS requests to known-bad resolvers, DOM structure matching known phishing page templates, JavaScript obfuscation patterns associated with malware droppers. The verdict is behavioral rather than signature-based — the URL doesn't need to be previously known as malicious; its behavior during detonation determines the score.
Why This Catches What Blocklists Miss
The blocklist lag problem is quantified in threat intelligence research. The average time between a malicious domain's first use in a phishing campaign and its first appearance in a major blocklist is measured in hours — some research puts median time-to-listing in the 4–12 hour range for new domains with no prior reputation. For a targeted campaign designed to hit 50 specific recipients, 4 hours is more than enough to complete the attack before any blocklist protection applies.
Detonation analysis sidesteps the lag entirely because it doesn't depend on prior observation. A URL registered 30 minutes ago that serves a pixel-perfect Microsoft 365 login clone has zero blocklist entries. When detonated in a sandbox, it exhibits clear behavioral indicators: the form submits credentials to a non-Microsoft domain, the page loads fonts from a CDN not associated with Microsoft, the certificate is a 90-day Let's Encrypt cert issued this morning rather than Microsoft's enterprise certificate infrastructure. The verdict is malicious based on behavior, not prior history.
Consider a plausible scenario: a 900-employee professional services company in the Southwest. An attacker sends 15 targeted messages to finance and executive assistant roles, each containing a link framed as a DocuSign notification. The linked URL was registered 6 hours before send time. The security stack queries the blocklist — no result, domain too new. Without detonation, the email reaches the inbox. With detonation-based analysis, the sandbox loads the page, observes the credential form submitting to a non-DocuSign endpoint, and returns a malicious verdict before delivery. The email is quarantined. The 6 hours of blocklist lag never opens a delivery window.
Evasion Techniques and Their Limits
Sophisticated attackers are aware that detonation analysis exists and have developed evasion techniques. Understanding these is important for calibrating expectations about what detonation catches and what it doesn't.
IP-based geofencing: The malicious page checks the requesting IP's geolocation and only serves malicious content to IPs in the target region, while returning a clean page to other IPs. Sandbox environments that use cloud egress IPs — typically from major cloud providers in known data center ranges — may hit the clean version of the page. Effective detonation systems rotate egress IP pools and use residential-proxy-sourced IPs for some checks to reduce this bypass surface.
User-agent filtering: The malicious page checks the requesting browser's user-agent string and returns clean content to automated browsers and headless Chromium environments. This requires sandboxes to accurately emulate real browser fingerprints — user-agent, viewport size, touch support, JavaScript engine quirks — not just HTTP user-agent headers.
CAPTCHA gating: The destination page presents a CAPTCHA that requires human interaction before revealing phishing content. Automated detonation cannot solve CAPTCHAs without machine vision integration. This is a documented evasion category noted in threat intelligence from Proofpoint and others. CAPTCHA-gated phishing represents a real limitation of detonation-based analysis and is part of why URL sandboxing is most effective as one layer in a defense stack rather than a comprehensive solution.
Time-delayed activation: The malicious content only activates after a defined time delay (e.g., the page is clean for the first 2 hours, then starts redirecting). Detonation timing matters here — a sandbox that checks once at delivery time may encounter the clean version of a time-delayed payload.
We're not saying detonation analysis is ineffective because evasion techniques exist. We're saying the realistic performance envelope of detonation-based analysis catches a large fraction of URL-based phishing — particularly the majority that uses off-the-shelf phishing kits without sophisticated evasion — while more targeted, technically sophisticated campaigns may use evasion techniques that reduce its effectiveness. This is why detonation sits alongside, not instead of, other detection layers.
Microsoft Safe Links and Where Detonation Fits
Microsoft Defender for Office 365 Safe Links provides time-of-click URL analysis — it rewrites URLs in email and checks them at the point the user clicks, not just at delivery time. This is a real improvement over delivery-time-only checking. Safe Links detonation capability (the sandboxed page analysis) is included in certain Safe Attachments/Safe Links configurations in Plan 2.
The limitations of Safe Links are documented in the M365 phishing gaps article. Relevant to URL sandboxing specifically: Safe Links' detonation does not fully traverse all redirect chains for multi-hop redirects through legitimate services, and CAPTCHA-gated pages are a known bypass category. Supplemental URL detonation that uses more aggressive redirect-chain traversal and multiple evasion-resistance techniques provides additional coverage on the residual cases Safe Links doesn't catch.
In a Google Workspace environment, there is no built-in URL detonation equivalent to Safe Links. Google Safe Browsing provides URL reputation checking — the blocklist-based approach — but not behavioral detonation. Organizations on Google Workspace have more to gain from supplemental URL sandboxing than comparable M365 environments.
Operational Considerations for Mid-Market Teams
Deploying URL detonation introduces latency. Depending on implementation, detonation can add anywhere from 30 seconds to several minutes to email delivery for messages containing URLs that route to detonation analysis. For most business email, this is acceptable. For time-sensitive communications — conference call links, two-factor authentication codes, e-signature requests — delay policies need to be calibrated carefully.
Most implementations handle this through selective routing: not every URL in every email routes to full detonation. Fast-path checks handle URLs from known-good domains (internal domains, major SaaS platforms with consistent certificate infrastructure). Detonation is reserved for URLs matching elevated-risk indicators: newly registered domains, first-time-seen domains for this mailbox, URLs arriving in messages that already have social engineering risk signals from the semantic inspection layer.
NIST SP 800-53 SI-3 (Malicious Code Protection) requires organizations to use malicious code protection mechanisms at network entry points — URL detonation in the email inspection path directly implements this control for link-based threat delivery. For organizations subject to SOC 2 Type II audit requirements, automated URL detonation with logged disposition records supports the audit evidence for email threat protection controls.
For more on how URL sandboxing integrates with Phishaver's broader URL threat defense layer, including how detonation results feed the behavioral risk scoring for the full email inspection pipeline, see the URL sandboxing threat type page. The integration with the full platform connects detonation verdicts with the LLM-based semantic analysis layer — URLs in high-social-engineering-risk messages receive detonation priority even when the domain is not intrinsically suspicious.