MailThreatZero

How it works

From the sender's SMTP connection to your mailbox

MailThreatZero is a managed secure email gateway that scans inbound email before securely relaying it to your existing mail platform. It works with Microsoft 365, Google Workspace, Exchange, hosted email providers, and customer-owned mail servers.

The mail path

Mail path through the MailThreatZero gateway An internet sender connects to the MailThreatZero gateway, which runs five scanning stages — network and reputation, sender authentication, malware and attachment analysis, spam and content analysis, and optional AI analysis — combines them into one weighted decision, then either relays the message to the customer's mail platform or holds it in quarantine. Internet sender SMTP to your MX MailThreatZero managed gateway five core scanning stages · one weighted decision 1 Network & reputation RBL · GeoIP 2 Sender authentication SPF · DKIM · DMARC 3 Malware & attachments signatures · macros 4 Spam, phishing & content multi-engine scoring 5 Optional AI analysis your key weighted score vs your domain's thresholds every enabled and applicable stage runs for each message Your mail platform Microsoft 365 · Google · SMTP Quarantine held, reviewable, releasable
Inbound mail is scanned on the MailThreatZero gateway and relayed to the mail platform you already use. Nothing is installed in your environment.

Your mailboxes do not move. Microsoft 365, Google Workspace, Exchange, a hosted provider or your own server — the gateway relays to whatever you already run. Inbound messages pass through the MailThreatZero gateway for security analysis before being relayed to the configured destination mail server.

Five core scanning stages combined into one weighted decision per message

Every enabled and applicable scanning stage runs for each message, so a message that passes reputation still has its attachments inspected. Each stage contributes to one weighted score rather than voting pass or fail.

  1. Network and reputation

    Cut off traffic from hosts with a known bad history before a single header is parsed.

    • Multiple real-time DNS reputation sources
    • IP and domain reputation
    • GeoIP country and ASN policy
    • Connection rate limiting

  2. Sender authentication

    Establish whether a sender is entitled to use the domain in the From header, and let that answer inform every later stage.

    • SPF
    • DKIM (cryptographic)
    • DMARC

  3. Malware and attachment analysis

    Catch malicious files and Office macros before they reach a mailbox.

    • ClamAV
    • Linux Malware Detect
    • Oletools
    • Attachment policy

  4. Spam, phishing and content analysis

    Filter bulk and deceptive mail without punishing legitimate newsletters and billing notices.

    • SpamAssassin
    • Rspamd
    • Pyzor
    • Razor2
    • Phishing detector
    • Header analyzer
    • Content filter
    • QR code reader

  5. Optional AI analysis

    Look at the messages rules find ambiguous — the targeted phishing and business email compromise that has no signature.

    • Your own OpenAI or Anthropic key

Every capability in detail, engine by engine.

How the decision is made

Engines contribute weighted scores to a total. The total is compared with two thresholds set per domain: one for quarantine and a higher one for rejection.

  • Deliver

    Below the quarantine threshold. The message is relayed on normally, and the full breakdown is still recorded for tracking.

  • Quarantine

    At or above the quarantine threshold. The message is held on the gateway, and a notification with a review link can be sent to the recipient.

  • Reject

    At or above the reject threshold, or a confirmed virus. The sending server is told the message was refused, so a legitimate sender knows.

  • Monitor Mode

    Every message is scored and recorded per domain, and delivery is unchanged — so policy can be evaluated and tuned against live mail before it is enforced.

Two behaviors exist specifically to stop over-blocking: a verified sender suppresses the heuristics that only make sense for unverified mail, and a non-critical AI verdict cannot cross the quarantine line on its own. We publish the concepts rather than the exact weights and thresholds, which are tuning detail an evader would find more useful than a buyer.

How filtered mail reaches your platform

Filtered mail is delivered to your platform over its own supported inbound path — an Exchange Online inbound connector or a Google Workspace inbound gateway — which is SMTP with TLS, configured inside your tenant. Mailboxes, users and licensing stay exactly where they are.

Microsoft 365

An Exchange Online inbound connector receives filtered mail from the gateway. The setup wizard generates that connector's settings for the specific domain in front of you, with copy buttons.

Google Workspace

A Google Workspace inbound gateway does the same job, generated for the domain in the same way.

Any other SMTP destination

A destination host and port per domain: hosted Exchange, cPanel, Zimbra or anything that accepts SMTP.

The gateway records what it saw. The authentication result it determined is stamped on the message, so your platform can trust that verdict rather than deriving its own. ARC sealing of that result switches on once the domain's ARC key is published in DNS — the gateway will not sign with a key it cannot resolve. The tenant connection used to verify a domain before cut-over is read-only and directory-scoped — no mailbox read or send permission is requested, and mail is never carried by API. Details are on the security page.

Onboarding a domain

  1. 1. Add the domain

    Set its destination mail server and starting policy. Nothing changes for your mail yet.

  2. 2. Set up your platform

    The wizard generates the exact connector and filtering settings for that domain, with copy buttons rather than placeholders to translate.

  3. 3. Verify before you cut over

    Before MX changes, the wizard checks the tenant, public DNS, the destination and that your platform will accept mail from the gateway. Each check returns a specific remedy, and a check that could not run is reported as untested rather than counted as a pass.

  4. 4. Point MX, then monitor

    Change the domain's MX to mt0.mailthreatzero.com. Run in Monitor Mode while you tune thresholds and lists against the per-message breakdowns from real traffic.

Delivery and operational questions

What happens if a message cannot be handed over straight away?
It is not lost. Sending servers queue and retry — that is how SMTP is specified to behave — and a secondary MX can be configured for the domain.
Is outbound mail filtered?
Outbound inspection and DLP are available for mail routed through the MailThreatZero gateway. Applications and devices submit on port 587 with a per-domain credential, and a message that trips a rule is held for review rather than bounced. Coverage depends on mail-flow configuration.
What happens to a quarantined message?
It stays on the gateway until it is released or deleted, and is pruned on the retention schedule. Releasing it reinjects the retained original message content through the configured delivery path, so it delivers like any other message.
Is internal user-to-user mail seen?
Mail between two of your own users does not cross any gateway. Point your platform's journal rule at the gateway and it is retained alongside everything else; the console generates the exact steps.
What is logged?
Per-message tracking records and per-engine scores, plus an audit log of administrative actions. Retention periods are on the security page.

Evaluate it against your own mail first.

Monitor Mode scores and records every message per domain with delivery unchanged.

Evaluate One Domain Technical architecture