MailThreatZero

Background

Why we built MailThreatZero

This is not a sales page. It is the reasoning behind three decisions that shaped the product, and what we were trying to avoid when we made them.

The licensing problem

Email security has become steadily more capable and steadily more expensive to license. Most platforms charge per user or per mailbox, which means the bill grows every time a customer hires — even though the filtering work barely changes.

For an MSP that is a particular kind of annoyance. You win a customer, they grow, and your security line grows with them on a schedule you do not control. Forecasting a portfolio means forecasting other people's headcount.

So MailThreatZero is priced per protected domain. A domain costs the same with five mailboxes or five hundred. That is not a discount strategy; it is a decision about which unit the bill should follow, and we picked the one that matches the work.

The black-box problem

The more common frustration is not a missed message. It is a message that was blocked and nobody can say why. A customer asks, the console shows "Blocked", and the honest answer is a shrug.

We wanted a gateway where the answer is on the screen. Every stage records what it found and what it contributed, against the threshold that decided the outcome — and a stage that did not run says so, with the reason, rather than showing a green tick that means nothing.

The awkward consequence is that our own weak spots are visible too. A rule that misfires is obvious in the breakdown. We think that is the right trade: a scoring system you can inspect is one you can tune, and one you can defend to a customer.

The AI problem

AI is genuinely useful for the mail that deterministic rules find hard — the invoice that reads slightly wrong, the request that does not match the relationship. It is also an easy place to hide margin, sold as an opaque bundled cost with no visibility into what was spent or on what.

So AI here runs on your own provider account. You hold the credentials, you see the usage, and you pay the provider at your own rates. We add no markup. It also means you can turn it off per domain and lose nothing else, because AI is one signal among several rather than the thing the product depends on.

Our principles

These are the tests we actually apply when deciding whether something ships.

  • Explain every decision

    If the console cannot say why a message was delivered, quarantined or rejected, the feature is not finished.

  • Keep pricing predictable

    A customer growing should not change what they cost to protect.

  • Show the uncomfortable numbers too

    A partial search says it was partial. A stage that did not run says so. A result that flatters us but is not true is worse than no result.

  • Build for many customers, not one

    Tenants, domains, policy and quarantine are separate objects because an MSP is the normal case here, not an afterthought.

  • Practical over flashy

    We would rather ship a check that catches real mail than a dashboard that looks like a film set.

  • Solve problems, not competitor feature lists

    A capability gets built when it answers a question an administrator actually has. Several things on this site are marked "not included" for exactly that reason.

Where we fall short of other platforms, the comparison says so directly.