Operational validation
How MailThreatZero validates filtering health
Continuous checks verify mail flow, routing, enabled security services, DNS dependencies and message-processing health — so a filter that stops working is found by the product rather than by a customer.
Continuous mail flow validation
The question that matters is not whether the software is running. It is whether a message sent right now would arrive.
Probe messages on the real path
A probe is delivered through the same gateway, the same scanning pipeline and the same relay as customer mail. It exercises what a real message exercises rather than reporting on a component in isolation.
Routing verified end to end
The probe confirms the message was accepted, scanned, scored and handed to its destination. A failure at any point along that chain raises an alert with the point it stopped at.
Delivery confirmed, not assumed
Handing a message to a destination server is not the same as that server taking it. The check follows the message to the acceptance, so a silently refusing destination surfaces as a failure.
Scanner health
A scanner that stops scoring does not announce itself. Mail keeps flowing, and it simply stops being checked — which is why the enabled services are exercised rather than polled.
Enabled scanners are tested with known samples
Each enabled scanning service is given a sample it should react to, and the result is compared with what it should have said. A service that answers but scores nothing is caught, which a liveness check would miss entirely.
Reputation sources are checked
The DNS reputation services the gateway depends on are queried against their published test points, so a source that has been retired or stopped answering is found rather than quietly contributing nothing.
Service availability
The scanning services and the mail queue are reported live in the console, so an operator can see the state of the platform behind their own domains.
Configuration validation
Routing, DNS records and the settings that decide how a domain is filtered are checked on a schedule. A record that changes underneath a customer, or a configuration that has drifted from what was deployed, raises an alert.
Message visibility
Validation is only useful if a decision can be examined afterwards. Every message keeps its own record.
Every decision recorded
Each engine's raw and weighted score is kept with what that stage actually found, alongside the total and the threshold that decided delivery, quarantine or rejection.
Investigate a single message
Search by sender, recipient, subject, address or domain, then open the message to see the full breakdown behind its verdict and the path it travelled.
Scoring you can follow
A stage that did not run records that it did not run, with the reason — so it is distinguishable from a stage that ran and found nothing. Every scanning stage that is enabled, applicable and reached runs for each message.
Monitor Mode
Monitor Mode records how MailThreatZero would classify messages while allowing normal delivery. Review decisions, tune policy, and validate the fit before enabling enforcement.
Evaluate before enforcement
Run a domain in Monitor Mode: every verdict is recorded and none is enforced, so you can decide whether the policy is right for that customer first (see what still applies, and the evaluation guide for the whole process).
Tune the policy on real mail
Thresholds, allow and block lists and which engines run are all set per domain. Monitor Mode shows the effect of a change against the traffic that domain actually receives.
Validated against your own environment
A published figure describes somebody else's mail. The evaluation that answers your question uses the senders, the suppliers and the attacks that reach you.
What this does and does not show
Operational monitoring confirms that the filtering pipeline is functioning correctly. It should not be interpreted as an independently verified detection benchmark.
The checks on this page answer an operational question — is the service working as configured, right now. Assessing how a filter performs against your own threat profile is what Monitor Mode is for, and it is the evaluation we would rather you rely on.
Evaluation log
A structured third-party test set run against the production gateway: what it found, what was fixed, and the limits of what it shows. Run by us, not by an independent tester, and not on customer mail.
- Self-run KnowBe4 Mail Server Assessment, on our own domain
- 26–30 September 2026
- Four runs; 165 messages
- Five detection gaps found and fixed in releases 2.65.60, 2.65.61, 2.65.65 and 2.65.68
KnowBe4 Mail Server Assessment, 26–30 September 2026
- Environment and scope
- KnowBe4's free Mail Server Assessment, run by us against one of our own protected domains on the production gateway. Each run sends about forty simulated threat messages (attachments, links, spoofing and impersonation) plus a completion notice.
- Sample and period
- Four runs between 26 and 30 September 2026: 165 messages in total.
- How results were classified
- From the gateway's own records, not the assessment's report, which counts anything not refused during SMTP as delivered. Each content test was judged by the score of the stage meant to catch it, not by the final verdict: the assessment's sending domain alone scored above the quarantine threshold, so a held message did not by itself show that its content had been recognized.
- Confirmed findings
- Five detection gaps, each since fixed: a lookalike sender domain written in international characters was not scored; a Reply-To on the recipient's own domain was ignored when the sender authenticated; a link-mismatch check misread "https:" as a domain; PDFs with scripts, HTML files that redirect, and macro documents inside archives scored nothing at the attachment stage; and content disarm delivered a macro document whose other findings should still have held it.
- Operational outcome
- All five were fixed, each with regression tests. Three fixes were also seen working in a later run of the same assessment, from the gateway's own records: the Reply-To check and the link-mismatch fix (second run, 26 September) and the attachment checks (30 September). The other two are covered by regression tests: the disarm fix shipped after the last run, and the lookalike-domain test message cannot be matched in later runs' records.
- Limitations
- Synthetic messages from one vendor's test set, on one domain, run by us. We have since tuned against that set, so repeating it would overstate real-world results. It is not a detection rate and does not measure customer mail. Passing health checks, described above, is not a detection benchmark either.
Request a demo before you commit
Run a customer domain in Monitor Mode to review classifications, policy behavior and message-level decisions before enabling enforcement.