Guide
How to investigate a disputed email filtering verdict
A customer says a message they needed was held, or that one which should have been stopped reached them. This is the order to work through it in MailThreatZero, two worked examples, what to send the customer, and what the record cannot tell you.
Before you start
- A console account that can see the domain. A tenant or domain administrator sees only their own domains; message search covers every domain your role can see.
- Something to search on. The sender, the recipient, roughly when it was sent, and ideally the subject or the Message-ID from the sender’s copy.
- The domain’s mode and thresholds. Whether it is in Monitor Mode, and its quarantine and reject thresholds. The defaults are a quarantine threshold of 10 and a reject threshold of 20, and both are set per domain.
The steps
- Find the message. Search message tracking by sender, recipient, subject or Message-ID. Generally available If it is not there, check live mail flow for SMTP refusals: a connection refused before the message was accepted has a reason recorded but no message. If it is in neither, it never reached the gateway — it went to an old MX still cached by the sender, or was never sent.
- Read the decision sentence first. One sentence states what happened and why, with the thresholds that applied. In Monitor Mode it says what scoring would have chosen, and the message was delivered.
- Find the deciding stage. The breakdown lists every stage with its score and what it found. Generally available Take each stage’s score away from the total in turn: the stage without which the outcome would have been different is the one that decided it, and usually the only one worth changing.
- Check what did not run. A stage that did not run, timed out, or could not read an artifact is reported as exactly that, never as a pass. An encrypted archive the gateway cannot open is a coverage gap, not a clean result.
- Check authentication. A legitimate sender whose own SPF or DKIM is broken often scores on authentication alone. That is their configuration to fix, and the DMARC guide explains each result.
- Look sideways before you act. One message opens every other message from the same sender, lure or link across the tenant. Generally available A wrong verdict on one message is often the same verdict on twenty.
- Act on the cause, not only the message. Release a held message once; then decide whether the fix is a per-domain threshold, a stage switched off for that domain, a narrow list entry, or a request to the sender.
- Reply with the record. What scored, why, and what changed. The reply template below is a starting point.
Worked example: “you held our supplier’s invoice”
Synthetic data, the same scenario as the self-guided
demo. An invoice from billing@supplier.example.com to
accounts@customer.example.net was quarantined.
| Stage | Score | What it found |
|---|---|---|
| Network and reputation | 0 | Sending IP not listed on any enabled blocklist. |
| Sender authentication | 4 | SPF passes for the relaying service but does not align with the From domain; no DKIM signature, so DMARC is unverified. |
| Malware and attachment analysis | 0 | PDF scanned, no signature match, no active content. |
| Spam, phishing and content analysis | 7 | Invoice wording plus a first-time sender for this recipient. |
| Optional AI analysis | – | Not enabled on this domain: shown as skipped, not as a pass. |
| Total | 11 | Over the quarantine threshold of 10. |
Reading it. Neither signal decides it alone: without the 4 for authentication the total is 7, and without the 7 for content it is 4, so either change would have delivered it. The durable fix is the sender’s: once they sign with DKIM, every future message from them loses those 4 points.
What to do. Release the message once (the release is recorded with who did it). If the supplier cannot fix signing quickly, add an exception scoped to that sender and that recipient domain, with an expiry and a reason, rather than allow-listing their whole domain. An allow-list entry matches on an address a sender can write into a header, which is why the evaluation guide treats them as claims.
Worked example: “why did this reach us?”
Synthetic data, the demo’s delivered link scenario. Release notes from a partner, delivered at 08:05. At 12:20 the recipient clicked a link whose destination had since turned hostile.
- The record at delivery. Authentication passed and aligned; the link resolved to a documentation host with no redirects; total 2 against a quarantine threshold of 10. On the evidence available at 08:05, delivering it was the right decision — and the record shows that evidence, which is the answer to the customer’s question.
- What made a difference later. The domain had optional link rewriting on, so the 12:20 click was checked and refused at the rewriter, and the message was reclassified from the click. Without rewriting, the gateway’s part ended at delivery.
- Who else got it. Link destinations are recorded per message, so the other recipients of the same link are a search, not a guess.
- Removing delivered copies. Moving them to a recoverable folder needs a connected Microsoft 365 or Google Workspace tenant. Beta testing
A message that scored low and was genuinely malicious at delivery is a different finding: note the stages that ran and what each saw, and send it to us. A miss with its record is the most useful report an evaluator can make.
What to send the customer
Short, specific, and from the record. Adapt it:
We found the message from [sender] to [recipient] at [time]. It was [held / delivered] because [the deciding stage and what it found], which took it to [score] against your threshold of [threshold]. [We have released it / It was delivered as normal]. To stop it recurring we have [the change made], and we have asked [the sender] to [their fix, if any].
What the record cannot tell you
- Rejected mail cannot be released
- A rejected message is discarded and recorded as rejected, with the deciding stage; the sender is not notified. Only held mail can be recovered, which is why the reject threshold is the last one to lower.
- A release is not a rescan
- Release delivers the stored original message and bypasses re-scanning.
- Only mail that reached the gateway
- Mail delivered around it — to an old MX, or to a platform that still accepts direct delivery — has no record here. Restricting the platform to accept mail only from the gateway closes that.
- Recipient reports are off by default
- A footer link that lets a recipient report a delivered message as spam exists, switched on per domain on request. Generally available
- Weights are not published
- The per-stage scores for every message are in your console; the exact scoring weights are tuning detail we do not publish.
See a real breakdown before you trust one.
Walk through the four synthetic verdicts on your own, or ask us to show the console on a call.
Related: reviewing a sample of verdicts during an evaluation · how a message is scored · for MSPs
