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.
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 relays over standard SMTP, so it can sit in front of Microsoft 365, Google Workspace, Exchange, hosted email providers or a customer-owned mail server.
The mail path
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
The stages enabled for a domain run on each message unless an explicit rule or an allow-list entry for that sender says otherwise, so a message that passes reputation still has its attachments inspected. Most stages contribute to one weighted score rather than voting pass or fail; a confirmed virus is the exception and is refused on its own.
-
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
- Sender IP and sender domain reputation
- GeoIP country and ASN policy
- Connection rate limiting
-
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
-
Malware and attachment analysis
Catch malicious files and Office macros before they reach a mailbox.
- ClamAV
- Linux Malware Detect
- Oletools
- Attachment policy
-
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
-
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.
That is what makes the filtering explainable: every message keeps each stage’s score, what it found, and the threshold it was compared with, so a disputed verdict is answered from the record. How to investigate one.
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 gateway has already accepted the message by the time it is scored, so it is discarded and recorded rather than bounced: a bounce would usually go to a forged sender.
Monitor Mode
Each message is scored and recorded per domain, and the verdict is not enforced — so policy can be evaluated and tuned against live mail before it is. A few controls still apply; they are listed below.
Where each decision happens, and how it shows in tracking
- Refused during the SMTP conversation
- Only before the message is accepted: a connecting server listed on Spamhaus ZEN, SpamCop or Barracuda (unless excepted, and not for a domain in Monitor Mode), and mail for an address or domain the gateway does not serve. The sending server receives the refusal. These are shown in the console's refused-connections view, because no message was ever received.
- Decided after acceptance
- Everything the scanning stages score. Delivered and quarantined messages appear in message tracking with their full breakdown. A rejected message is discarded and recorded there as rejected, with the deciding stage; the sender is not notified.
- Deferred
- If the scanner itself fails, the message is deferred with a temporary error, and the sending server retries it later. Nothing is lost or silently passed.
- Bounced
- Only for a configuration refusal or a permanent failure delivering to your mail platform, where the sender needs to know.
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.
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. Add the domain
Set its destination mail server and starting policy. Nothing changes for your mail yet.
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. 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. 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; held mail does not expire on its own. Released and deleted items are removed 30 days later (retention table). 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, so it is not seen. Journal ingestion, which captures it for the archive through your platform's journal rule, is built and in beta testing; it is not yet switched on for customers.
- 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 each message per domain without enforcing the verdict. Here is exactly what still applies.
Exactly what Monitor Mode does and does not do
- Every verdict is simulated. Every scoring verdict is simulated. A message that would be delivered, quarantined or rejected is delivered and recorded instead — including one a scanner confirmed as malware. Monitor Mode measures what the policy would do; it does not protect the domain while it runs.
- SMTP-time blocklists are switched off. The SMTP-time DNS blocklist refusal is switched off for a domain in Monitor Mode. It has to be: that refusal happens at RCPT, before the message is ever scanned, so leaving it on would refuse mail the mode exists to observe.
- What still applies. Controls that are not part of scoring still apply. Your mail server's own recipient, size and rate limits are unaffected, and if the scanner itself fails the message is deferred with a temporary error for the sender to retry, exactly as it would be outside Monitor Mode.
- The message may still be modified. Delivery is unchanged; the message is not necessarily unchanged. Warning banners and link rewriting are separate per-domain settings and are not suspended by Monitor Mode, so if you have either enabled the body is still modified on the way through.
- It needs your MX. It needs MX pointed at the gateway, because it can only score mail it receives. That is the one change you make to start; nothing else about delivery changes.