Fig. 1. Which filter caught the message decides the quarantine policy, and the policy decides whether the user ever finds out.

The ticket always reads the same: “the supplier says they sent the message, but I have nothing”. The message exists, it sits in quarantine, and nobody told the user. This is not a bug but a consequence of how quarantine policies work in Exchange Online, and it is worth understanding before the support team starts hunting for a fault that is not there.

Several routes into quarantine

A message can end up in quarantine for several independent reasons, each handled by a different filter:

  • anti-spam: spam, high confidence spam, phishing, bulk mail,
  • anti-phishing: user and domain impersonation,
  • anti-malware: attachments recognised as malicious,
  • Safe Attachments: attachments found malicious after sandbox analysis,
  • mail flow rules: administrator-defined conditions with a deliver-to-quarantine action.

Each of these filters decides separately what happens to the message it caught. Everything else follows from that.

The quarantine policy decides everything

Every filter verdict has a quarantine policy assigned to it. The policy defines what the user can do with the message: view it, release it themselves, request a release, block the sender, or nothing. The same policy also decides whether the user receives a notification about the quarantined message.

The practical consequences:

  • Malware and high confidence phishing verdicts default to a policy accessible to administrators only. The user does not see these messages and is not told about them. From a security standpoint that is intentional.
  • Ordinary spam and bulk mail can use a policy that gives the user full access, but notifications are a separate setting that has to be switched on.
  • Messages caught by mail flow rules use a system policy that cannot be edited and does not send notifications to users. If the organisation quarantines messages based on its own rules, the user will never know until somebody checks the quarantine by hand.

On top of that, storage is time-limited: quarantined messages are deleted after the retention period, thirty days by default and shorter for some verdicts.

What to do on the administrator’s side

  1. Map verdicts to policies. For each filter, write down which quarantine policy is assigned and what that means for the user. This table is the basis for communication with the support team.
  2. Enable notifications where possible and sensible. For spam and bulk mail, a daily digest notification reduces the number of tickets. For phishing and malware, no notification is the right choice.
  3. Establish a review routine. Messages invisible to users have to be reviewed by somebody: daily, against a checklist, with a clear procedure for releasing and for adding senders to the allow list.
  4. Tell users what they will not see. A short guide: which messages will appear in a notification, which they will never see, and where to report a missing expected message.
  5. Measure. Number of quarantined messages by verdict, number of releases on user request, number of false positives. If most releases concern one sender or one type of message, the problem is in the filter configuration, not in the users.

Summary

Quarantine is not one place with one behaviour. It is a set of verdicts, each with its own visibility policy. An administrator who knows this map answers the “I did not receive the message” ticket in a minute. An administrator who does not goes looking for a routing fault.