Features
Everything the gateway does, grouped by what it protects
Five core scanning stages combined into one weighted decision per message, plus the administration around them. Every enabled and applicable scanning stage runs for each message, and engines contribute to a weighted score rather than voting pass or fail, so no single heuristic blocks a message on its own.
Each capability shows the outcome first. Open Technical details on a card for how it works. Items marked Optional run on an account or key you supply, or are a paid add-on. Items marked Deployment depend on how mail is routed. Everything else is included with a protected domain. Certain capabilities depend on mail-flow configuration or optional integrations.
At a glance
Five things a mail security product has to do. The detail for each is further down this page; the honest status of every capability is on its own page.
-
Prevent
Stop it before delivery. Spam, phishing, BEC, impersonation, payment fraud, malicious links and QR codes, malware and attachment analysis, sender authentication.
-
Detect
See what got through and what changed. Campaign correlation, explainable per-message scoring, Monitor Mode, outbound anomalies, links that turn malicious after delivery, account-takeover risk.
-
Respond
Do something about it. Message tracking and threat hunting, quarantine and release, mailbox lookup, and removal of delivered copies with verification.
-
Protect data
Outbound DLP, archiving with WORM retention, and an emergency inbox that keeps people working when the mail platform does not.
-
Operate
Run it as an MSP. Multi-tenancy, per-domain policy, reporting, REST API, webhooks and SIEM, single sign-on, and bring-your-own AI — or no AI at all.
-
Know what is finished
Not every capability above is at the same stage. Which are generally available, which are still being proven, and which are not built is published rather than left to be discovered.
The full technical detail for each capability follows below.
Prevent
Stop it before delivery.
Threat Protection
Volume mail and targeted mail fail in different ways, so they are scored by different signals and combined into one decision per message.
20 capabilities
Spam and bulk mail
-
Rule and Bayesian scoring
The mature, widely understood baseline that most spam is decided by.
SpamAssassin runs with its rule set and a trainable Bayesian classifier.
Technical details
The rule set is refreshed on a schedule, and each customer has their own Bayesian corpus rather than sharing one. Training on your own mail changes your filtering and nobody else's, and a classification you later disagree with can be withdrawn from your corpus exactly.
-
Users see what is held for them
A summary of their own quarantined mail, with a link to release what they want.
Sender, subject and time — never the contents of a held message.
Technical details
Each release link is a signed token naming one message and one recipient, expiring after seven days, carrying no session and able to do exactly one thing. Anything the gateway judged a serious threat still needs an administrator: the message a user most wants released is exactly the one a convincing phish is designed to make them want. Off until enabled, per domain.
-
Mail waiting for a destination that is down
See what is queued for a customer, how long it has been there, and when it would start bouncing.
Read a waiting message while the destination is still down, and retry the queue when it returns.
Technical details
Mail is held for five days before anything is returned to its sender. The queue is Postfix's own — this reports on it rather than replacing it, because a second store of in-flight mail is a second place to lose it. Domain administrators are alerted when mail has been waiting more than 45 minutes, once per outage rather than every retry.
-
Response playbooks on every incident
What to do, in the order that contains the damage, with progress tracked.
Each step is an action a person triggers, never an unattended one.
Technical details
Progress is read from the incident's own timeline, so the checklist and the audit trail cannot disagree. Steps needing a mailbox integration say what is in the way rather than appearing merely undone. Blocking an indicator is a selection rather than a button, because a malicious message links to ordinary places too and the console shows how much clean mail carries each one.
-
A read API for your PSA or RMM
Per-customer counts, message metadata, quarantine and incidents, over HTTP.
Scoped keys: a monitoring integration can read counts without reading anyone's mail.
Technical details
Versioned in the path, paginated, rate limited per key. A summary endpoint reports a domain that has received nothing at all, which is the single most useful alert an RMM can raise about a mail gateway. Releasing a quarantined message is the only write, and it runs the same code the console does.
-
Ask the AI for a second opinion
Look at a message that got through and ask what it actually was.
The AI proposes; you decide; only your confirmation teaches anything, and only your own corpus.
Technical details
The AI's contribution is bounded — it can move a score by a configurable amount and no further — and a large increase is only applied in full when a deterministic stage agrees with it. It can never argue a message clean over a malware detection or an authentication failure. Message content is treated as untrusted input: it is sent as delimited data, the response is validated against a strict schema, and nothing the model returns is executed or used as a rule. Off by default, per domain, and it spends your own AI credit.
-
Second scoring engine
An independent second opinion on the same message.
Rspamd scores the message separately, enabled per domain.
Technical details
Its result is mapped proportionally onto the gateway's own thresholds rather than replacing them, so one engine cannot decide an outcome by itself.
-
Collaborative fingerprints
A campaign already seen elsewhere in the world is recognized on arrival here.
Pyzor and Razor2 check message fingerprints against collaborative reporting networks, which catches bulk mail before any local rule has learned it.
-
Connection and sender reputation
Known-bad infrastructure is weighted before content is even read.
Sending IP and domain reputation comes from multiple real-time DNS reputation sources.
Technical details
Reputation is scored alongside content rather than treated as a verdict on its own, so a listed address raises the score instead of deciding the message.
-
Geographic policy
Mail from regions you never do business with can be handled by rule.
Pick countries on a map and score their mail accordingly — set on the domain, or once on the account and inherited by every domain under it.
Technical details
A world map shows where a domain's mail actually originates before you commit to a rule, so a country rule is made against observed traffic rather than a guess.
A domain inherits the account's country rules unless it is set to use only its own. A policy that belongs to the customer relationship is written once, and a domain that has to differ from its siblings still can.
A country rule adds weight to a message's score rather than deciding the outcome by itself; the domain's thresholds still decide whether that means quarantine or rejection. Rules by ASN are not configurable from the console.
-
Honeypot spam traps
Campaigns announce themselves on addresses no legitimate sender could have.
Trap addresses collect mail aimed at recipients that should never receive any, and what lands there feeds sender reputation.
-
Content and custom rules
Policy you can express in your own words, per domain.
Keyword policy, hidden text, obfuscated HTML and blocked-URL handling, with exact and fuzzy rules written per domain.
-
Allow and block lists
The senders you already trust, and the ones you never want to hear from again.
Maintained per domain by address or by domain, and applied before content scoring.
-
Training from real decisions
Corrections you make in the console improve later classification.
Marking a message ham or spam feeds the Bayesian classifier for that deployment, so recurring false positives are fixed rather than reported repeatedly.
Phishing and impersonation
-
Display-name spoofing
A familiar name in the inbox no longer implies a familiar sender.
The display name is tested against the address that actually sent the message, catching a name claiming an address or a brand it does not own.
-
Lookalike domains
The near-miss domain registered last week is flagged the first time it writes to you.
Homograph, digit-substitution and near-miss domains are detected, including ones that differ by a character from a domain your users already correspond with.
-
Brand impersonation and credential lures
Sign-in pages dressed as your own vendors are scored on what they are asking for.
Credential-request language, urgency patterns and brand cues are weighted per domain, so a legitimate vendor notification is not treated the same as a lure.
-
Link text against link target
A reliable phishing signal, checked on every message.
Anchor text naming one destination while the underlying href points somewhere else is scored directly.
Technical details
The comparison runs at the subdomain and path level, so a link claiming a vendor's site while pointing at a lookalike host or an unrelated path is caught.
-
Header analysis
Automation and interception leave traces in the envelope.
Envelope and header inconsistencies are examined together rather than individually.
Technical details
Reply-To and Return-Path mismatches, malformed dates, a missing Message-ID and inconsistent routing each contribute, so no single anomaly has to carry the decision.
-
Business email compromise indicators
Payment-redirection attempts are caught even with no attachment and no link.
Header, reply-path and display-name mismatches are combined into a signal that does not depend on a payload existing.
Sender Authentication
Identity is settled before anything else runs, because every later stage is more accurate once it knows whether the sender is who they claim to be.
6 capabilities
-
Cryptographic DKIM verification
A forged signature header fails instead of passing as proof of identity.
Signatures are verified against the key published in the sending domain's DNS, rather than the header simply being parsed for presence.
Technical details
The body hash is checked against the canonicalized message, so a signature that no longer matches the content it covers fails rather than being accepted on its headers.
-
SPF and DMARC policy
The domain owner's published policy is applied as written.
A message that authenticates by either SPF or DKIM is treated as verified; where neither holds, the domain's DMARC policy decides the outcome.
Technical details
SPF and DKIM results are evaluated together with alignment between the authenticated domain and the domain in the From header, which is what DMARC actually tests.
-
Organizational-domain alignment
Senders using an email service provider are not punished for it.
Relaxed alignment is applied, so a subdomain envelope aligns with its organizational domain the way real senders operate.
Technical details
An ESP envelope of
em1234.example.comaligns withexample.com, so ordinary bulk-sending arrangements authenticate instead of failing alignment. -
Failure classification
A mailing list is not scored like a spoofing attempt.
Signature failures are categorized by cause rather than counted as one event.
Technical details
A DKIM failure caused by a list rewriting the subject or footer in transit is scored differently from a signature that fails against the published key, and differently again from a missing key, a syntactically invalid signature or an expired one.
-
Authentication-aware scoring
Verified senders stop triggering the heuristics that exist to catch impostors.
This helps reduce false positives by considering authentication context alongside other message signals.
Technical details
Once a message authenticates and aligns, the spoofing and impersonation heuristics stand down, so a verified sender is not scored on signals that only make sense for an unverified one.
-
ARC sealing of the verdict
Your mail platform can trust the gateway's authentication result rather than re-deriving its own after the hop.
The authentication result is stamped on the way out. ARC sealing of it switches on once the domain's ARC key is published in DNS.
Technical details
Any inbound Authentication-Results header claiming to originate from the gateway is stripped before ours is added, so the seal cannot be forged upstream.
Impersonation, BEC and Executive Protection Optional
The general phishing checks cover well-known brands from a fixed list. That is the right check for consumer phishing, and it structurally cannot catch vendor fraud — the supplier being impersonated is not a household name, and the only place they appear is in one customer's own mail history.
6 capabilities
-
Lookalikes of your own domain
A sender domain that reads as yours but is not.
Scored even when SPF and DKIM pass. Authentication proves the sender owns the domain they registered this morning; it says nothing about that domain imitating yours.
-
Lookalikes of your suppliers
Compared against the domains this recipient actually corresponds with, built from their own delivered mail.
Optional per-domain impersonation protection: lookalikes of the customer's own domain, lookalikes of suppliers they actually correspond with, and named people whose display name an attacker writes. The supplier list is built from the domain's own delivered mail and is visible in the console.
Technical details
A domain counts as an established correspondent after several delivered messages — received is not enough, or anyone could manufacture a relationship by sending junk. Other domains you own can be listed and are excluded, so a company holding both its .com and its .org does not flag its own mail.
-
Named people
A message whose display name claims to be someone on your list, from an address that is not theirs.
Both parts of the name must match. A first name alone would flag everyone who shares it. Configured per domain, because one customer's finance director is nobody to another.
-
Payment and account-change requests
Wire fraud, invoice redirection and gift-card requests.
Payment and account-change language never scores on its own. It counts only when something independent corroborates it — an unknown sender, a divergent Reply-To, a lookalike domain, or a claimed executive. The people who write about invoices and bank details all day are the finance team.
-
Warning banners Optional
A note at the top of a delivered message, for the mail that is probably fine and occasionally is not.
Optional warning banners on delivered mail. One banner per message, never a stack: a message qualifying for several triggers gets only the most serious. Signed and encrypted messages are never modified.
Technical details
Triggers are chosen per domain and are all off by default, including “external sender” — on a typical domain that marks nearly all mail and so distinguishes nothing. Attachments are never modified, both the plain-text and HTML parts are banded, and a message crossing the gateway twice does not get two banners.
-
Off until you switch it on
None of this is enabled by an upgrade.
Every check here is per domain and disabled by default, and the correspondent list it compares against is visible in the console — a detection nobody can inspect is one nobody trusts.
Attachments
Three separate things happen to an attachment, and they are worth keeping apart: local signature engines scan it, optional reputation services say what the wider world already knows about it, and policy decides whether the file type belongs in your mail at all.
6 capabilities
-
Signature scanning
Known malware is stopped by engines running on the gateway, with no third-party account required.
ClamAV scans every message with official and unofficial signature sets.
Technical details
Signature sets are refreshed on a schedule, so coverage tracks the published updates without waiting for a product release.
-
Second signature set
Coverage that one vendor's database missed.
Linux Malware Detect applies its own signature database over the same message, switched on per domain.
-
Document and macro analysis
A renamed macro document does not get through on its extension.
Office containers are opened and their parts examined, so a macro-enabled format is identified by structure.
Technical details
The container is unpacked and its relationships, part names and stream layout inspected: an embedded VBA project, an OLE object, an external template reference or a mismatch between the declared extension and the real container each carry their own score.
-
Attachment policy
File types that have no business arriving by mail are handled by rule rather than by judgment.
Executables, double extensions and archive contents are governed per domain.
Technical details
Archives are opened and their contents assessed against the same policy, including files found inside nested archives.
-
Attachment reputation and multi-engine analysis Optional
The verdict of many engines on a file, without waiting for your own signatures to catch up.
Optional attachment reputation and multi-engine analysis through VirusTotal, using the customer's own account.
Technical details
Attachments worth checking are identified by SHA-256 and matched against what the service already holds, so the file is recognized without its contents being disclosed. Where the service has no record, the result is recorded as inconclusive rather than as a pass, so an attachment's status is never overstated.
-
Allow lists cannot override malware
A trusted sender who has been compromised still cannot deliver a dangerous file.
The attachment verdict is evaluated after allow lists are applied, and a confirmed malware result is rejected regardless of other scores.
Behavioral analysis is available, off by default, and runs on a provider account you supply or a CAPE analysis host you operate. Attachments are also checked against your own VirusTotal account for multi-engine reputation, and a file nobody has seen before can optionally be submitted there for multi-engine analysis — off by default, because submitting discloses the file to a third party.
URLs and QR Codes
Most credential theft arrives as a link, and increasingly as a link a filter cannot read because it has been drawn as an image.
7 capabilities
-
Links assessed at delivery
Every message is scored on where its links go before it reaches a mailbox.
Links are extracted during content analysis and weighted on where they lead.
Technical details
Shorteners, unencrypted destinations, link volume and the URLs a domain has chosen to block each contribute to the score.
-
Click-time checking Optional
A link weaponized after delivery is still caught, because the check happens when someone clicks.
Optional URL rewriting and click-time destination analysis. Configured per domain.
-
Links re-checked after delivery
Click-time checking protects whoever clicks next. It does nothing for the message already sitting in forty inboxes.
Links delivered in the last week are re-checked against reputation sources every six hours. A host that was clean on arrival and is now listed raises an incident carrying the messages that delivered it.
Technical details
Hosts carried by delivered mail in the last seven days are re-evaluated against the same reputation sources the click-time check uses, so a link cannot be judged one way at click time and another on re-check. Blocked mail is not re-checked — there is nothing in a mailbox to act on.
-
The real destination is shown
Users see the address they were about to visit, which is the one thing that helps at that moment.
A destination found dangerous is displayed in full with the reason it was blocked, rather than a generic warning page.
-
QR codes are decoded
The payload that moves an attack onto an unprotected phone is read on the gateway instead.
Codes in image attachments, PDFs and Office documents are decoded and their destination assessed, configured per domain.
-
Judged on where they lead
Invoices and event tickets carry codes legitimately, so presence alone scores nothing.
What scores is the destination behind the code, not the code itself.
Technical details
A shortener hiding the destination, a bare IP address, a sign-in path, or a brand named in the message that does not match the host each carry weight.
-
What was decoded is recorded
An investigator can read the link nobody could read in the message.
The decoded destination appears in the message record whatever it scored, alongside the rest of the per-message breakdown.
AI Analysis
Optional AI analysis uses the provider and credentials selected for the deployment and can be enabled or disabled per domain.
6 capabilities
-
Your account, your rates Optional
Provider usage is billed to you directly, with nothing added on top.
Credentials belong to the deployment, so the provider invoices you at list rates and the gateway takes no margin on the call.
-
Two-phase by design
Most mail never costs an AI call.
Deterministic scoring runs first, and only the messages it cannot settle reach the model.
Technical details
AI analysis runs only when the deterministic stages leave a message inconclusive, so most mail is decided without any AI call.
-
Model selection
Model choice stays current without waiting for a product release.
Supported models are selected in the console.
Technical details
Supported OpenAI and Anthropic models are configured in the product rather than listed here, because provider model availability changes frequently. The current list is shown in the admin interface under AI Settings.
-
Bypass rules
Trusted, high-volume senders are exempted before any call is made.
Skip AI for senders or patterns you already trust; allow-listed senders are bypassed automatically.
-
It cannot act alone
No message is quarantined on a language model's opinion by itself.
Below a critical result, an AI verdict requires corroboration from a deterministic engine before it can change the outcome.
-
Spend visibility
Provider cost is visible per tenant as it accrues.
Per-tenant credit tracking records what each customer's mail consumed, so an unexpected month is explainable.
Understand
Know why a decision was made, and what happened to a message.
Explainable scoring and investigation
Every decision is reconstructable after the fact. You can say exactly why a message was held, which engine contributed what, and which stages never ran — and search the same evidence across every domain you manage.
What you can see
-
Per-message filter breakdown
You can say exactly why a message was held.
Each engine's score, what that stage found, and the threshold that decided the action are recorded together rather than reduced to one verdict.
-
A stage that did not run says so
Absence of a finding is never mistaken for a clean result.
Stages that were disabled or not applicable are recorded as not run, with the reason, so they are distinguishable from stages that ran and passed.
-
Search across domains
One search answers "what happened to this message" for any customer you manage.
Message tracking covers sender, recipient, subject, IP, domain and verdict across every domain your role can see, with the filter breakdown behind each row.
-
Campaign view
A run against four hundred recipients reads as one incident, not four hundred rows.
Messages are grouped into campaigns rather than listed individually.
Technical details
Grouping is on normalized subject and sender domain. Campaigns with mixed outcomes sort first, because a campaign that was fully blocked is history and one with delivered mail is still open.
Live mail flow and per-message tracking are in the console rather than on this page; how a message is scored walks through one end to end.
Respond
Act on what got through, including mail already delivered.
Mailbox Threat Response
Classifying a message is not the end of the job. When something is recognized as malicious after it was delivered, the questions are who received it, is it still there, and what was done about it. Mailbox Threat Response is those steps as one workflow rather than four screens.
The investigation, end to end
-
Campaign detected
A run across many recipients is one row, not four hundred.
-
Exact recipients and messages
Every message carries the recipient and Message-ID the gateway recorded on arrival.
-
Message detail
Each stage's score and what it found, against the threshold that decided the outcome.
-
Locate delivered copies
A targeted lookup per message, on a connected mail platform.
-
Preview, then act
What would change is recorded and confirmed before anything moves.
-
Audit and restore
Every action attributable, and reversible where the platform allows.
Why the lookup is targeted, not a sweep
Most products investigate a campaign by searching every mailbox for something that resembles it. That is expensive and imprecise: a subject search is one pass over every mailbox on the domain, and it returns mail that merely looks similar.
This gateway already knows the answer. Every message that passes through is recorded with its recipient and its Internet Message-ID, so investigating a campaign means one exact lookup in the one mailbox that received each message — not a sweep. A twenty-six message campaign is twenty-six lookups instead of twenty-six passes over every mailbox, and each result is the actual message rather than a resemblance.
The same records are what make the message detail, the campaign grouping and the audit trail exact rather than approximate.
Start from the indicator
When something already delivered turns out to be malicious, an indicator sweep finds every message that carried it — by URL, hostname, file hash, sender, QR destination or campaign fingerprint. This runs on what the gateway recorded as the mail passed through and needs no mail platform connection.
Indicators are extracted from every message as it is delivered, so the search is an indexed lookup rather than a re-scan of stored mail. A URL pasted from an intelligence feed is normalized the same way the index was built, so its tracking parameters do not stop it matching — without that a sweep quietly finds nothing and reads as an all-clear.
Recipients are deliberately not indexed. A sweep looks for what an attacker sent, and an index of recipients keyed by indicator is a mailing list waiting to be queried.
Incidents raise themselves
-
A link that has since gone bad
Links delivered in the last week are re-checked against reputation sources every six hours. A host that was clean on arrival and is now listed raises an incident carrying the messages that delivered it.
-
A confirmed report that reached other people
Confirming a reported message sweeps its indicators. One message to one recipient stays a report; a run that reached several becomes an incident. Raising one for every confirmed report would bury the ones that matter.
-
An account whose sending has changed
Account takeover is detected from sending behavior: volume, the number of strangers an account suddenly writes to, and whether outbound mail is itself phishing. Each account is compared against its own history, not a shared threshold.
Sign-in logs, mailbox rules and forwarding configuration are not consulted — they require permissions on a connected mail platform. Every alert names what it could not check. Automatic containment is off and requires an explicit per-domain opt-in.
-
Anywhere you already watch
Incidents can be delivered to a SIEM as JSON, or to Slack or Microsoft Teams. Every delivery is signed with HMAC-SHA256 and carries counts and a reference — never recipients, subjects or message contents. High and critical incidents also email the domain's administrators — not low or medium, because an alert that arrives for everything is filtered to a folder within a fortnight.
Delivered and located are different numbers
They are never merged here, because merging them would hide the thing an administrator needs to know.
- Delivered
- The gateway relayed the message and the destination mail platform accepted it. This comes from our own log and does not change.
- Located
- A later lookup confirmed the message is still in the mailbox. This comes from the mail platform, at the moment you ask.
Located is routinely lower than delivered, and legitimately so: the recipient deleted it, a mailbox rule moved it, retention removed it, or an administrator already cleaned it up. Reporting one as the other would either put messages in inboxes that are not there, or make a campaign that landed look like one that failed.
What runs where
-
Included with a protected domain
Indicator sweeps and incidents, campaign detection and grouping, exact recipient and Message-ID tracking, message search, per-stage message detail, and the audit history of every administrator action. None of this needs a mail platform connection — it runs on what the gateway recorded as the mail passed through.
-
Requires a connected mail platform Deployment
Locating delivered copies, previewing an action, remediating and restoring require a Microsoft 365 or Google Workspace connection on the domain. Supported actions depend on the connected platform. These connected-platform actions are built and tested but not yet verified against a live customer tenant, and are not represented as generally available.
A sweep can say what was delivered, to whom, and what was blocked. Whether a copy is still in a mailbox is a question only the mail platform can answer, so it is reported as unknown unless a Microsoft 365 or Google Workspace connection is present — never inferred, and never reported as zero.
Quarantine and release
Every decision the gateway makes is reviewable afterwards, which is what turns a false-positive complaint into a two-minute answer.
3 capabilities
-
Readable message body
Held mail can be inspected safely, without forwarding it to someone's desktop.
Rendered, plain-text and raw views are available.
Technical details
HTML is shown in a sandboxed frame that cannot run scripts or load remote content, so opening a held message does not fire its tracking or its payload.
-
Release that actually delivers
Released mail delivers like any other message, carrying the content that was held.
Release reinjects the retained original message content through the configured delivery path, rather than rebuilding a message from indexed fields.
Technical details
The stored bytes are re-injected, so the message queues and retries like any other piece of mail and its signatures still verify at the destination.
-
Recipient self-service
Routine releases stop landing on your help desk.
Quarantine notifications carry tokenized links, so a recipient can review and release their own mail without an administrative account.
Protect data
Control what leaves, and keep what must be kept.
Outbound DLP Deployment
Outbound inspection and DLP are available for mail routed through the MailThreatZero gateway. Coverage depends on mail-flow configuration.
5 capabilities
-
Authenticated submission on 587
Applications and devices send through the gateway on a credential you can revoke on its own.
Each domain gets its own SMTP credential, bound to that domain's addresses so it cannot be used to send as anyone else.
-
Sensitive data detection
Regulated data leaving by mail is caught before it leaves.
Payment card numbers, US Social Security numbers and IBAN bank account numbers are detected, plus whatever bespoke patterns the domain configures.
-
Validated, not just matched
An invoice number does not hold up a sales quote.
Every built-in detector carries its own checksum or allocation rule, so a sixteen-digit run is not assumed to be a card.
Technical details
Card numbers are checked with Luhn and IBANs with mod-97, so a match has to satisfy the scheme's own validation before it can hold a message.
-
Matches are stored masked
Enforcing the policy does not copy regulated data into your logs.
Detected values are masked in findings, alerts and reports, so enforcing a policy does not copy regulated data into your reporting.
Technical details
Each detector masks at the point of detection, so the matched value is not written into the scan result, the mail log, or any report or alert built from them. The held message itself is retained with its original content — that is what makes review and release possible — and opening it is audit-logged.
-
Held for review, not bounced
A wrong rule costs a release, not a lost message.
Messages that trip a rule are held with their original content retained, so they can be examined and released rather than lost.
Retention and Archiving
Message history for investigation comes with the subscription. Optional archive storage is billed separately based on retained capacity and retention term.
9 capabilities
-
Message retention
Recent mail stays searchable for investigation without buying anything extra.
Message history and quarantine data are retained for administrative review, with the periods published on the security page.
-
Retention you choose, per domain Optional
One customer's seven-year requirement does not set the bill for the rest.
Buy a bucket of archive storage and split it across domains yourself, from one to seven years. The term purchased is the term that applies.
-
Legal hold Optional
Mail under hold survives the retention clock.
A message on hold is retained regardless of its retention period until the hold is released.
-
Search what was actually said Optional
The first thing anyone tests in an archive is whether it finds a phrase.
Full-text search covers message bodies and the text inside PDF, Word, Excel and plain-text attachments.
-
Scanned documents are read too Optional
A signed contract that was scanned and emailed is findable by its words.
Image-only documents are put through OCR, so a photographed agreement is reachable by content rather than only by filename.
-
Read and export Optional
Producing mail for counsel or an auditor does not need our help.
Download the original message exactly as sent, or export a set as mbox, which every mail client reads.
-
Every read is logged Optional
An archive holds everything everyone received, so access to it is accountable.
Archive searches and downloads are recorded separately from the general audit log.
-
Tamper evidence and write-once retention Optional
Archived mail can be shown to be the mail that arrived.
A write-once period can be set per domain, during which archived mail cannot be deleted or altered.
Technical details
Each completed day is hashed into a chain, so a later change to a sealed day is detectable rather than silent.
-
Internal mail, with a journal rule Deployment
User-to-user mail that never crosses the gateway is retained alongside everything else.
Point your platform's journal rule at the gateway and internal mail is archived, including BCC recipients that appear nowhere in the message itself. The console generates the exact steps for your platform.
Operate
Run it across a portfolio of customer domains.
MSP Management
Built for someone running mail for a portfolio of customers rather than for one organization with a security team.
9 capabilities
-
Multi-tenant console
One sign-in covers every customer you manage.
Each tenant's data is scoped to them.
Technical details
Access control is applied in the data layer rather than only in the interface, so a scoping mistake in the console cannot expose another tenant's mail.
-
Roles and delegated access
Customers can hold their own quarantine without touching anyone else's.
Platform administrator, tenant, domain administrator and read-only roles are available.
Technical details
A customer contact can hold a domain-administrator account scoped to their own domain, so delegating quarantine does not mean sharing your console.
-
Domain onboarding
A new customer goes live from a wizard rather than from a runbook.
Domain, destination and platform are collected once, and the console generates the platform-side configuration.
Technical details
Generated values are copy-ready rather than placeholders to translate, so the connector is built from the console's output instead of from a runbook.
-
Per-domain policy
One customer's tolerance never becomes everyone's.
Thresholds, which engines run, AI scanning, country rules, allow and block lists, DLP, link rewriting, QR reading, archiving and retention are set on the domain.
Technical details
AI scanning is switched on or off per domain, so one customer can run it while the domain next door does not. The provider credentials it uses belong to the account, so a single key serves every domain without being entered again for each one.
Country rules work the same way, with an account-level default: a domain applies the account's rules unless it is set to use only its own. The common case is written once, and the domain that has to differ still can.
-
Monitor Mode
Policy can be tuned against real mail before anything is enforced on it.
Monitor Mode records how MailThreatZero would classify messages while allowing normal delivery. Review decisions, tune policy, and validate the fit before enabling enforcement. How validation works.
-
Log-only advanced filters
New filters prove themselves before they can block anything.
The advanced content filters run in log-only mode with a would-have-blocked count on the dashboard, then enforce when the count looks right.
-
Portfolio health triage
The customer most likely to call you tomorrow is at the top of the list today.
Customers are ranked worst-first, and every row opens to the findings behind it, each carrying its fix.
Technical details
A finding can be a DNS record result, connector status, quarantine backlog, an administrator without two-factor, or an active domain that has received no mail for seven days.
-
Usage and billing figures
The number you put on your own invoice is already calculated.
A per-tenant statement shows domains at the tier rate alongside archive storage usage.
-
Two-factor authentication
An administrative account covering many customers is worth protecting properly.
TOTP is available on any administrative account.
Technical details
Repeated failed sign-ins trigger lockout by account and by source address.
Reporting and Integrations
Evidence you can hand to a customer or an auditor, and a gateway that sits in front of whatever you already run.
19 capabilities
Reporting and auditability
-
Dashboards
What your mail looks like this week, per domain or across the portfolio.
Volume, verdict mix, threat categories and per-domain breakdowns over selectable ranges.
-
Scheduled summaries
Customers see the value of the service without you writing a report.
Summary emails are opt-in per domain, with a separate platform summary for the operator.
-
DMARC aggregate reports
DMARC reporting is part of the service rather than another subscription.
Reports are ingested and parsed, with no mailbox to create and no third-party processor.
Technical details
Point the record's
rua=at the mailbox the console shows you, and incoming aggregate reports are parsed into the sending-source view. -
Who is sending as you
Most organizations have never seen this list, and it is where shadow IT surfaces.
Every sending source that used the domain in the From header, with volume, country and whether it authenticated.
-
Alerts worth reading
Authentication problems reach you before the customer notices delivery failures.
Alerts fire on the authentication patterns that precede a delivery problem.
Technical details
Covered: a source failing authentication at volume, a source that authenticated but did not align, a source that has never appeared before, and reports that stop arriving at all.
-
DNS validation
A record changed underneath you is caught the next day, not the next incident.
MX, SPF, DKIM and DMARC are checked on demand and swept daily, with alerting when a record changes.
-
Audit log
Administrative activity is accountable after the fact.
Administrative and security-sensitive activity is recorded to support investigation, with archive access recorded separately.
-
Service health and continuous validation
"Is filtering actually running for this customer right now" has an answer.
Automated health checks continuously validate the filtering pipeline and enabled scanning services. See how validation works.
Technical details
Every scanning service and the mail queue is reported live in the dashboard, so a service that has stopped is visible rather than inferred.
Integrations
-
Microsoft 365
Tenants are verified and configured before cut-over rather than during it.
Filtered mail is delivered over an Exchange Online inbound connector.
Technical details
Microsoft Graph is used read-only and directory-scoped, to verify the tenant and generate its configuration.
-
Google Workspace
The same pre-flight check, on the same read-only basis.
Delivery is over a Google Workspace inbound gateway.
Technical details
The Directory API is used read-only on
admin.directory.domain.readonly. -
SIEM, Slack and Microsoft Teams
An alert that only exists in a console is one nobody reads at 3am.
Incidents can be delivered to a SIEM as JSON, or to Slack or Microsoft Teams. Every delivery is signed with HMAC-SHA256 and carries counts and a reference — never recipients, subjects or message contents.
Technical details
The signature covers the timestamp and the exact body, so a captured delivery cannot be replayed later. Only HTTPS to a public host is accepted. Delivery attempts are recorded and a persistently failing endpoint is disabled and shown as broken, rather than retried into silence while everyone assumes the SIEM is receiving alerts.
-
Cross-tenant intelligence
An attacker who phishes one client phishes the next within the hour.
Indicators confirmed malicious on two or more separate tenancies are shared across the platform as counts. No tenant, domain, recipient or sender address is recorded in the shared data, and a customer's own domain is never shared.
Technical details
Volume never promotes an indicator — a busy legitimate host appears in millions of messages across every tenancy. An indicator becomes shared knowledge only when it has been deliberately confirmed on two independent tenancies, so one customer's opinion never filters another customer's mail.
-
Any SMTP destination
Customers on older or self-hosted platforms are not excluded.
Destination host and port are configured per domain: hosted Exchange, cPanel, Zimbra or anything that accepts SMTP.
-
Authenticated SMTP submission
Applications and devices get a route that is inspected like everything else.
Port 587 with a per-domain credential, for applications, devices and outbound routing.
-
OpenAI and Anthropic Optional
Bring your own key and keep the commercial relationship.
Supported models are selected in the product rather than fixed in marketing copy, so the list stays current.
-
VirusTotal Optional
Multi-engine attachment intelligence on your own account.
The lookup uses the customer's own API key and quota, with no intermediary account holding your submissions.
-
DNS-based reputation networks
Shared threat intelligence that updates without a release cycle.
Sending-IP reputation from multiple real-time DNS reputation sources, plus the collaborative fingerprint networks.
Technical details
The URI lists the anti-spam engines query are used alongside the Pyzor and Razor2 fingerprint networks.
-
Journaling ingestion Deployment
Internal mail reaches the archive without changing how users send it.
A journal rule on your platform delivers internal mail to the gateway for archiving.
-
JSON API
Custom integrations, automation, reporting, and external security tools can build against the documented API.
The console's own API is published as an OpenAPI schema.
Technical details
Requests are authenticated with the same signed session token the console uses, so an integration needs no separate credential store.
See it against your own mail.
Monitor Mode shows what would have been caught, without changing delivery. Evaluate One Domain to run it on your own traffic, or read how filtering health is validated.