MailThreatZero Features

• 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.com aligns with example.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.

• Monitored automatically

  Every protected domain is enrolled, with nothing to set up.

  About every six hours: dedicated sending IPs against SpamCop, Barracuda and PSBL, SPF, DKIM and DMARC as published, receivers' DMARC reports, registration status and expiry, and MX, DNSSEC, MTA-STS, TLS-RPT and BIMI.

  Technical details

  Spamhaus, SURBL and Google Web Risk are supported when the platform operator supplies a key or licence; their free services exclude commercial filtering providers, so they are never queried without one.

• A score you can take apart

  The MTZ External Reputation Score lists every point it loses, and why.

  It starts at 100 and loses fixed, published points per problem. A serious listing caps it, so it is never hidden by an otherwise tidy setup.

  Technical details

  There is no universal Internet reputation score, and this is not presented as one. It is a summary of the external signals on the page, each with its evidence.

• Unknown is never clean

  A source that cannot be checked says so.

  A blocklist that times out or refuses the query is shown as Unknown, with its last answer, and is left out of the score rather than counted as a pass.

  Technical details

  Each list is asked about its own published test entry before its answers are trusted, because a list that has stopped serving a resolver often answers "not listed" for everything.

• History, and why it changed

  24 hours to 90 days of history, with sudden and gradual degradation detected.

  "Why did my reputation change?" lists exactly which signals appeared or cleared, with their points: a new listing, a rise in DMARC failures, a new sending IP.

• Shared infrastructure attributed correctly

  A listing on Microsoft's or Google's shared servers is not pinned on your domain.

  Sending servers are attributed as dedicated, shared-provider or uncertain, and only your own are scored.

• Alerts without the noise

  New listings, failure spikes, new sending servers, MX moving away, expiring registrations.

  An unchanged problem never alerts twice, alerts clear themselves when the condition does, and everything for a domain arrives in one email.

• Optional sources, and how mature each is

  Some sources need an account or licence, and say so.

  Spamhaus (through a DQS key), SURBL and Google Web Risk are queried only once the platform operator supplies a key. Google Postmaster Tools is in beta testing and connects to your own Google account: once connected, it adds Google's sender-requirement verdicts and Gmail statistics for domains verified in the connected account. Google no longer publishes a domain reputation score, so none is shown.

• Stale data is marked, not reused

  When a source fails, its last answer is kept as evidence and the signal is shown as Unknown.

  Every check shows when it last ran. A source that keeps failing backs off rather than being hammered, and while it does, nothing it said before counts toward the score.

• 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.

• Links assessed at delivery

  Links are scored on where they go during content analysis, before the message 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.

1. 1

   Campaign detected

   A run across many recipients is one row, not four hundred.

2. 2

   Exact recipients and messages

   Every message carries the recipient and Message-ID the gateway recorded on arrival.

3. 3

   Message detail

   Each stage's score and what it found, against the threshold that decided the outcome.

4. 4

   Locate delivered copies

   A targeted lookup per message, on a connected mail platform.

5. 5

   Preview, then act

   What would change is recorded and confirmed before anything moves.

6. 6

   Audit and restore

   Every action attributable, and reversible where the platform allows.

Why the lookup is targeted, not a sweep

A common way to investigate a campaign is to search 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

The gateway indicator sweep is available now: it searches what the gateway recorded as mail passed through, and needs no connection to your mail platform. Live mailbox lookup and post-delivery movement are Beta: built and covered by tests against recorded Microsoft Graph and Gmail behavior, and Beta until they are independently validated on authorized provider tenants.

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. In beta testing: not yet delivered to a live customer endpoint. 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 Integration required

  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.

• 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.

• 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 Add-on

  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. Each message keeps the term in force when it was archived, and legal hold or WORM protection can keep it longer. Retention table

• Legal hold Add-on

  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 Add-on

  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 Add-on

  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 Add-on

  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 Add-on

  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 Add-on

  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 Beta testing Deployment required

  User-to-user mail that never crosses the gateway, retained alongside everything else.

  A journal rule on your platform delivers internal mail to a per-tenant journal address and the report is unwrapped to the original message, including BCC recipients that appear nowhere in the message itself. In beta testing: the journal endpoint is not yet switched on for customers, so internal mail is not captured today.

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. In beta testing: not yet delivered to a live customer endpoint.

  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 External service

  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 External service

  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 Beta testing Deployment required

  Internal mail reaching the archive without changing how users send it.

  Built and tested; the journal endpoint is not yet switched on for customers.

• 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.