Osiris Labs
Osiris LabsMay 29, 202612 min Read

The Email Was Detected. Why Was It Still Delivered?

Hero

Here is a sentence that appears in incident reviews more often than any security team would like: the email was detected. Not missed, not overlooked. Detected. It shows up in the logs, correctly flagged as malicious, with a verdict and a timestamp. And yet the money still moved, or the credentials were still entered, because the detection and the delivery were not the same event, and the gap between them was all the attacker needed.

This is the uncomfortable space between knowing an email is dangerous and actually stopping it from doing harm. Most email security is measured on the first thing, whether it can spot a bad message. The attacks that succeed exploit the second thing, the time it takes to act on what was spotted. A verdict that arrives after the click is a record of what happened, not a defence against it.

Detection is a moment, and the threat moves after it

The oldest assumption in email filtering is that a message can be judged once, at the door, and that the judgement holds. Attackers have spent the last two years dismantling that assumption, and the main tool is delayed weaponisation.

The technique is simple and effective. The attacker sends an email containing a link that, at the moment of delivery, points to a perfectly innocent page. Every scan at the gateway sees a clean destination and lets it through, correctly, because at that instant the link is clean. Some time later, after the email is sitting safely in the inbox, the attacker changes where that link points, swapping the harmless page for a credential-harvesting one, sometimes by editing the destination and sometimes by repointing the domain through DNS after delivery. The scan was not wrong. It was just taken at the only moment the link was safe. Attackers have grown sophisticated enough to abuse even the protective link-rewriting that gateways add, with security researchers tracking a rise through 2025 in multi-layered URL rewriting chained through trusted providers to hide the final malicious destination.

The consequence is that a one-time verdict at delivery cannot be trusted to still be true an hour later. The email that was safe when it arrived is not the email the user clicks.

People move faster than the alert does

Even when a threat is detected after delivery, there is a race between the detection and the human, and the human usually wins. Verizon's 2025 Data Breach Investigations Report puts hard numbers on it. The median time for a person to click a phishing link after receiving it is 21 seconds, and where credentials are entered the whole sequence from opening the email to handing over the password takes a median of 49 seconds. The same report finds the median time for a user to report a suspicious email is around 28 minutes.

Set those two numbers next to each other and the problem is stark. The click happens in twenty-one seconds. The first human warning arrives almost half an hour later. Any response that depends on a person noticing, reporting and a team reacting is starting the race roughly twenty-eight minutes behind an attacker who has already finished. The window between delivery and action is not a technicality. It is the entire attack.

The exposure window runs from delivery to removal. A rescue is only possible in the first seconds, before the click; everything after is cleanup, and the human report at 28 minutes lands deep inside it.

Detection without action is just a well-documented breach

There is a quieter version of this failure that has nothing to do with clever attacker timing. An email is flagged. The verdict lands in a console. And then it sits there, because flagging a message and removing it from every mailbox it reached are two separate jobs, and the second one did not happen fast enough, or did not happen automatically at all.

This is why the platforms email runs on now include retroactive clean-up. Microsoft's zero-hour auto purge, for example, continually monitors for updated verdicts and moves messages already sitting in mailboxes once they are recognised as malicious. It is a genuine and useful acknowledgement that delivery-time detection is not enough. But it has limits worth understanding: it acts only as fast as the signal that triggers it, and its retroactive search reaches back only across the last 48 hours of delivered mail. Retroactive purging helps, but it is still a cleanup crew arriving after the event. The question that decides the outcome is how much time passed between the verdict becoming available and the message actually leaving every inbox.

A malicious email that is detected but not removed in time is not a near miss. It is a breach that happens to be well documented.

Why classification alone was always going to lose this race

Traditional email security is built around a single question asked once: is this message bad, yes or no, at the moment it arrives. That model made sense when a message was static, when what arrived was what the user would later act on. It does not survive contact with delayed weaponisation, hijacked threads or payload-free requests, because in all of those the danger is not fully present at the moment of the scan. The link weaponises later. The trust was borrowed from an earlier message. The request only becomes an attack when a human acts on it.

Winning this race needs two things a one-time classifier does not have. The first is continuous evaluation: treating detection as something that keeps happening after delivery, re-checking where a link actually leads at the moment of the click rather than trusting the verdict from an hour ago, and watching for the account behaviour that betrays a compromise. The second is automated response measured in seconds, not the minutes or hours it takes a human to notice and a queue to clear. Detecting a threat and removing it from every affected mailbox have to be one motion, not two tickets.

This is the level Osiris is built to work at. Rather than issuing a verdict at the door and moving on, it keeps investigating after delivery, re-evaluates links and sender behaviour as things change, and couples that judgement to automated remediation that pulls a message the moment the verdict turns, across every inbox it reached, while explaining what it found. The aim is to collapse the exposure window rather than to document it. A detection that arrives in time to act is worth far more than a more confident one that arrives late.

What to do about it

The practical shift is to stop measuring email security only by detection rate and start measuring it by time to remediation. A tool that catches 99 per cent of threats but takes twenty minutes to remove them has left every fast-moving attack a clear run, because the damage is done in under a minute. Ask any prospective or incumbent control not just what it catches, but how quickly a confirmed-bad message leaves every mailbox, whether that removal is automatic, and whether it re-checks links and behaviour after delivery or trusts a single verdict from the moment of arrival.

For the people in the organisation, the same reporting habit still matters, but it should be understood for what it is: a useful backstop, not the primary defence. Twenty-eight minutes is far too slow to be the front line against an attack that lands in twenty-one seconds. The front line has to be automated.

Frequently asked questions

How can an email be detected as malicious but still cause harm? Because detection and removal are separate events. A verdict can arrive after the email was delivered and acted on, whether because the link was weaponised only after delivery, or because the flagged message was not pulled from inboxes quickly enough. A detection that lands after the click is a record of the incident, not a defence against it.

What is delayed weaponisation? It is when an attacker sends an email with a link that is harmless at the moment of delivery, so it passes every scan, then changes where the link points afterwards, swapping in a malicious page once the email is already in the inbox. It defeats any security that judges a message only once, at the door.

Does Microsoft already remove malicious emails after delivery? Yes, to a degree. Zero-hour auto purge retroactively moves messages that are recognised as malicious after they were delivered, which is a real improvement over delivery-only filtering. But it acts only as fast as the signal behind it and looks back only across the last 48 hours, so the time between a verdict becoming available and the message leaving the inbox still decides the outcome.

Why is time to remediation more important than detection rate? Because the damage in a fast attack is done in under a minute. Verizon's 2025 data puts the median time to click a phishing link at 21 seconds. A control that detects a threat but takes minutes or hours to remove it has already lost that race. How fast a confirmed threat is removed matters as much as whether it is caught.

How should email security handle threats that change after delivery? By treating detection as continuous rather than a one-time gate: re-checking a link's real destination at the moment of the click, watching sender and account behaviour after delivery, and coupling any new verdict to automated removal from every affected mailbox in seconds. The goal is to close the exposure window, not to document it.

Key takeaways

An email can be correctly detected and still cause harm, because detection and removal are different events and the gap between them is where attacks succeed. Delayed weaponisation lets a link pass a delivery-time scan and turn malicious afterwards, so a single verdict at the door cannot be trusted. People act faster than alerts arrive: a median of 21 seconds to click, against 28 minutes to report. Native retroactive purging helps but is only as fast as its signal and reaches back just 48 hours. The metric that actually predicts safety is time to remediation, which means continuous evaluation after delivery and automated removal measured in seconds, not a more confident verdict that arrives too late.

See how Osiris closes the exposure window

Osiris keeps investigating after delivery, re-evaluates links and behaviour as they change, and couples every verdict to automated remediation across all affected mailboxes, so a confirmed threat is removed in seconds rather than logged for later. See how Osiris approaches inbound email, or talk to us about your environment.

Sources