A compromised supplier sent 4,000 staff a hijacked reply-chain link. Do you claw the messages back now?

## The situation A supplier's mailbox is genuinely compromised. The adversary replies inside an existing thread with your staff, so the message authenticates correctly, comes from the right address, quotes real prior correspondence and arrives with all the trust of an established relationship. It was delivered. Forty hours later the supplier telephones to say they were breached. Four thousand of your people have the message, most have read it, and the click log shows twelve resolutions of the link. Post-delivery retraction is the platform's answer to exactly this: an action that reaches into mailboxes that already received a message and removes the delivered copies, either automatically when a verdict changes or manually when you run it from the console. ## Decide the order before you press anything **Preserve first.** You are about to remove the artefact from every mailbox that holds it. Take a copy into a location you control, or place the relevant mailboxes under a hold, before the purge. Analysts who skip this end up reconstructing the URL from a screenshot in a helpdesk ticket. **Pull the click list second.** This is the part candidates miss. Retraction is a message action, and a message action does nothing about the twelve people who already resolved the link. Those twelve are the incident; the other 3,988 are a cleanup task. Get that list out before you start changing the state of the mailboxes, and hand it to the identity and endpoint workstream. **Then retract.** Run it tenant-wide rather than by named recipient, because your recipient list is what the platform says was delivered, and copies get forwarded internally. **Then read the per-mailbox results.** The summary count is not the answer. Individual failures tell you where the message survives. ## What retraction genuinely achieves, and what it does not It reliably removes copies that are still sitting in mailboxes hosted in the tenant. That is the whole of its power, and it is worth a lot: it stops the click that has not happened yet, and it stops the message being forwarded onward internally next week. It does not: - **Un-click a click.** Anything already resolved is already resolved. If credentials were submitted, they were submitted, and removing the message changes nothing about that. - **Reach copies outside the platform.** A message downloaded by a local client, exported, auto-forwarded to a personal address, printed, or screenshotted into a chat channel is gone from your reach. - **Reach mailboxes it cannot modify.** Holds, migrated or disabled mailboxes and archive locations can all produce failures you must handle by hand. - **Happen silently.** Messages disappearing out of read inboxes generates helpdesk calls, and users who noticed the thread will talk about it. ## The sender is watching This is the part that separates a security incident from a cleanup exercise. The mailbox that sent the lure belongs to a real supplier and is under adversary control right now. Retraction inside your tenant does not notify them, but your communications can. If your user notice says "we removed a message from the thread with this supplier" and anyone continues that thread, the adversary reads it and learns what you detected and when. Notify staff in a channel the adversary is not in, tell them explicitly not to reply in the thread, and verify with the supplier by voice on a number you already held, not one from the message. The same logic applies to blocking. A reflexive block on the supplier's entire domain protects you and simultaneously breaks a live business relationship in the middle of an incident the supplier is also working. Scope it: block the URL, quarantine further mail from that mailbox, and agree with the supplier when normal flow resumes. ## Two consoles, two people In a small team the mail platform is usually administered by IT and the security team holds the security console. Retraction across four thousand mailboxes is a change that IT will see the consequences of, whether or not they authorised it. Knowing who holds the permission, and having agreed in advance that security may run it during an incident, is the difference between acting in ten minutes and negotiating for two hours while people keep clicking. ## Answering well The strong answer is not "yes, purge it". It is "yes, and here is my order, here is what the action cannot fix, here is who I tell and through which channel, and here is the number I ring to confirm."