Tailspin: a 'delivered' message the user cannot find, and two blocked-count numbers that disagree

The tracking chain stops at the mailbox boundary. 'Delivered to mailbox' is an Exchange transport fact; it is not a statement that a human can see the message in the inbox. Each candidate below needs a distinct check:

1. Junk Email folder. Exchange's own junk filtering runs after transport delivery and is not recorded in message tracking. Check the Junk folder directly in OWA, plus the junk-quarantine if the org uses one. This is the single most common explanation and the fastest to eliminate.
2. A mailbox-level rule. Outlook rules, including client-side rules, move mail with no transport trace. Inspect rules via the mailbox settings and via the mailbox audit log; look for a rule created around the delivery date.
3. Retention or archive policy. If a retention tag moves mail to the archive or to a subfolder shortly after delivery, the inbox search misses it unless you search the archive explicitly. Check the applied retention policy and search the archive scope.
4. Delegate or shared-mailbox routing. If the user has delegate access or the message was addressed to a distribution list, it may be in another mailbox. Confirm the exact recipient address in the tracked message and compare it to the user's primary address and aliases.
5. Forwarding. Transport rules, mailbox forwarding, or an inbox rule may have redirected it. Confirm from the tracking detail whether the message had a redirect, and check the forwarding address configuration on the mailbox.
6. Search limitation rather than message state. OWA search is indexed and can lag or miss; a targeted eDiscovery/compliance search across all mailboxes for the message ID settles it definitively.
7. Client-side visibility. A cached-mode profile with a corrupt OST shows an inbox that disagrees with the server. OWA is the control.

Sequence them cheapest-first: junk folder, rules, eDiscovery across all folders, then retention and delegation. Do not ask the supplier to resend until you have run the eDiscovery search - you need to know whether this is one message or a pattern across that supplier's mail.

Sources of divergence, in order of likelihood:

1. Message-level versus recipient-level counting. A message addressed to 40 recipients is one message but 40 deliveries. Dashboards typically count messages; delivery/quarantine counts are per recipient. A handful of large distribution-list blocks explains a gap of this size on its own.
2. Different definitions of 'blocked'. The dashboard may include virus, spam, bulk, policy, and connection-level rejections; the message-tracking query may cover only quarantined plus dropped. Connection rejections at SMTP often never become 'messages' and are invisible to message-level search.
3. Time window and timezone. Reports commonly run on a different boundary (UTC vs local, week start Sunday vs Monday) and on ingestion time versus delivery time. A few hours of offset on a Monday morning is worth hundreds of messages.
4. Retries and duplicates. Retried connections can appear as separate events; a deduplicated count is lower.
5. Late state changes. Quarantine releases, re-classification, and TAP retractions alter the disposition after the report was generated, so a later query sees different numbers than the snapshot.

How to decide what to publish. Publish neither raw number until both are rebuilt from the same query definition: same date range, same timezone, same unit (state recipients explicitly), same inclusion list of verdicts. Then publish the smaller, fully-defined number with the definition printed alongside it - plus a one-line note that connection-level rejections are excluded. Accuracy that survives scrutiny is worth more than a larger figure.

If the two counts cannot be reconciled, do not split the difference. Report the message-tracking figure as the operational metric, flag the dashboard as under review, and fix the dashboard query - a security metric that changes depending on who runs it will be discounted by its audience within two reporting cycles.

What to tell the user, today. Be specific and avoid 'it was delivered, so it is your problem':

• The message reached our mail system at 10:12:47 and reached your mailbox at 10:12:52; it was not blocked and was not quarantined.
• State where it actually is once you know - junk folder, an archive folder, a rule - and if it was a rule, name the rule and offer to remove or adjust it.
• Ask the supplier to resend only after you have confirmed the delivery path, and give the user a named contact and a reference number so they are not re-explaining the issue to three teams.
• If the message turns out to have been misrouted, say so plainly. Users calibrate their trust in the mail team on exactly these tickets.

Process changes.

1. First-line triage script for 'I did not receive it': check junk, check rules, run a message-ID search, run an eDiscovery search across all folders - before escalating to the mail team. Most of these tickets terminate at step one or two.
2. Record the pre-delivery and post-delivery state separately in the standard ticket fields, because conflating 'accepted by Proofpoint' with 'visible in inbox' is the root cause of the confusion.
3. Alert on rule creation in monitored mailboxes (finance, executives), since silently created rules are also the post-compromise persistence mechanism - this ticket type doubles as a security signal.
4. Publish a one-page metric definition for blocked/quarantined/delivered, and reference it in the monthly report so the numbers are reproducible by anyone who runs the query.
5. Close the loop on search indexing lag with the messaging team if eDiscovery finds the message while OWA search did not; a user who cannot find a delivered message in search will report every future missing message as a mail failure.