After delivery

The message is alreadyin the mailbox.Now it has to go.

No filter judges everything correctly at the moment of delivery. A domain gets listed two hours later, a signature recognises the attachment only the next day. MailGuard then removes the message from the mailboxes it already sits in — and tells you which ones.

Why checking before delivery is not enough

Not because it is poor, but because the verdict does not yet exist at the time of delivery.

The verdict arrives later

A sender domain enters a reputation list hours after the wave. At delivery time it was unremarkable, and every filter in the world would have let it through.

The signature arrives later

At intake, an attachment is invisible to every virus scanner. The next day ClamAV ships the matching signature. Without a later check, the file stays in thirty mailboxes.

The recipient notices first

When someone reports a suspicious mail, it almost never concerns only them. Without remediation you have to search the remaining mailboxes one by one — usually by hand, often incompletely.

Deleting alone is not enough

Removing a mail from a mailbox in silence leaves a person who remembers a message that is no longer there. Without a note, that becomes a call to your service desk.

Three triggers, three responses, one log

Remediation runs through the Microsoft 365 interface, after the organisation has explicitly granted access.

Triggered by a late verdict

A new listing at Spamhaus DBL or HBL, a new ClamAV signature, or an administrator's decision starts the run. The signature number is recorded so the same set is not checked twice.

The response is your decision

Remove from the mailbox, move to the junk folder, or only flag. Flagging is the gentlest form: the message stays but visibly carries the note that it was recognised as dangerous after the fact.

Those affected are told

On request, exactly those recipients whose mailbox held the message receive a short warning email. Shipped switched off, because some organisations want to clarify internally first.

What belongs to it

The remediation run is the last step. Before it come search, re-checking, and a case that holds the trail.

Retroactive threat scan

Checks the existing mailbox contents over a chosen window against today's reputation and virus data. It changes nothing and declares nothing harmless — it reports mailbox, sender, subject and reason.

Search across all mailboxes

Subject, sender, recipient, message ID, attachment checksum, link address and country of origin. Whoever found a wave selects the rows and starts remediation from the same view.

One run per message, not per recipient

The same message in twenty mailboxes makes one run, not twenty. Progress is visible per mailbox, and one stalled mailbox does not hold up the rest.

A case instead of loose rows

A wave becomes a case with a state: open, investigating, closed. A closed case can be reopened for investigation but never set back to open — otherwise the trail is gone.

Consent you can see

Access to mailboxes requires explicit approval in Microsoft 365. The interface shows whether it has been granted and which application carries it — no button that fails on a permission error when clicked.

Every run in the log

Who took which message out of which mailbox, and when. The event log can be exported in full as CSV for the whole period under review.

In comparison

What a gateway in the delivery path can do, and what a pure interface solution cannot.

 
Conbool MailGuard
Pure API integration
Checking before delivery
Yes, in the delivery path. A threat never reaches the mailbox.
No. Checking happens once the message has already been delivered.
Remediation after delivery
Yes, three responses to choose from.
Yes, it is the only way.
Trigger on a new virus signature
Automatic, with the signature number recorded.
Depends on the vendor, often only on request.
Retroactive scan of existing mail
Over a chosen window, in slices, without loading the message.
Usually present, often without a report per mailbox.
Warning to those affected
Exactly to the recipients whose mailbox held the message.
Rare. Often only an entry in the admin log.
Permission required
Mail.ReadWrite, explicitly granted and visible in the interface.
Broad mailbox access, usually a precondition for everything.

Statements about the usual route follow the publicly documented prerequisites of common signature services that source people data from Entra ID.

Frequently asked questions

Can MailGuard remove a message that has already been read?
Yes. Access runs through the Microsoft 365 interface and does not depend on whether the message was read, moved or replied to. If it was moved to another folder, it is found there.
What happens to messages the recipient has already forwarded?
A forward is a new message and sits outside your mailbox estate. MailGuard removes the original message and reports the case; the forwarded copy at a recipient outside your organisation cannot be retrieved by any vendor.
Which permission does remediation need?
Mail.ReadWrite on the affected mailboxes, granted by an administrator of your Microsoft 365 tenant. Without that consent no remediation runs, and the interface says so instead of starting a run that fails.
Does MailGuard delete on its own authority?
No. The trigger can be automatic, the response is configured by the organisation. Anyone who stays on “flag only” never gets a deleted message, but a marked one.
Does remediation also work on an on-premises installation?
Yes, the same function. It requires a Microsoft 365 tenant, because access to the mailboxes runs through its interface.
How do I see afterwards what happened?
Every run appears in the organisation's event log with time, acting person, response and affected mailboxes. The export covers the whole chosen period, not just the page loaded on screen.

Related solutions

See what is already sitting in your mailboxes

The retroactive threat scan checks your existing mail against today's data and changes nothing while doing so.