Security & data handling
How MailThreatZero protects your mail and your data
MailThreatZero is a managed secure email gateway that inspects inbound mail before it reaches your platform. This page sets out where mail flows, what is retained and for how long, how access is controlled and protected, how administrative activity is recorded, and how to raise a security question with us.
Last reviewed 2026-08-26.
Mail and data flow
Inbound messages pass through the MailThreatZero gateway for security analysis before being relayed to the configured destination mail server.
Your domain's MX points at mt0.mailthreatzero.com, the message is accepted and scanned on our
infrastructure, and it is then relayed to the destination mail server you configure. Your mailboxes
stay where they are — we sit in front of them.
What is retained, and for how long
- Message bodies
- Yes. Full message bodies are retained for 30 days to support quarantine review, release and per-message investigation.
- Tracking metadata
- Tracking records — sender, recipient, subject, size, sender IP, per-engine scores and the delivery decision — are retained for 90 days.
- Quarantined messages
- Quarantined messages remain available for review until they are released or deleted; released and deleted items are removed 30 days afterwards.
- Aggregated statistics
- Aggregated daily statistics are retained for 365 days.
- Temporary files during scanning
- A message may be written to a temporary file during malware scanning and is removed when the scan completes.
- DMARC aggregate reports
- DMARC aggregate reports addressed to a domain's report mailbox are parsed and stored as structured data (sending IP, volume, authentication results, published policy). They describe mail sent as the domain, not mail sent to it, and contain no message bodies. Reports are kept for 120 days and then removed automatically — except where an alert raised from one is still unreviewed, in which case the report is held so the evidence behind an open finding cannot expire out from under it.
Retention runs on a scheduled job. Shorter retention can be configured for a domain that needs it.
Service status
Current service availability, scheduled maintenance and incident history are published on our public status page. Each component is checked against the service that provides it rather than inferred from a web server returning a page.
Monitoring is not a service-level agreement. We publish what we measure; we do not offer an availability guarantee.
Secure mail and data transport
- Credential and secret protection
- API keys, provider secrets and integration credentials are sealed with an application key before they are written, so the database does not hold them in the clear — not even to an operator reading rows directly. Access to the underlying systems is limited to the operators who run the platform, and every administrative action against your data is recorded in the audit log. Storage-level questions are answered directly for security reviews: ask us.
- Mail transport
- Mail connections use encrypted transport where supported and configured. SMTP connections to and from the gateway use TLS (STARTTLS) with every server that supports it, which is the standard configuration for a public MX. A server that does not offer encryption still receives the mail rather than having it bounced, because the alternative to delivering in the clear is not delivering.
- And you can see which it was
- Every outbound delivery records what the handshake actually produced — encrypted with a certificate that validated, encrypted without one, or in the clear — along with the destination, so “was that message encrypted on the way out” is a lookup rather than an assumption. A destination that offered encryption and was nevertheless reached in the clear is counted separately, because that one is a fault worth chasing.
- Requiring it for a particular destination
- A destination can be promoted from “encrypt if you can” to “encrypt or do not deliver”. Mail to it that cannot be encrypted is then held and retried rather than sent in the clear. We will not turn that on for a destination until the record above shows it has been negotiating encryption reliably: requiring it somewhere that has been answering in plaintext delays that mail and eventually returns it, which is a self-inflicted outage rather than a security improvement.
- Administrative interface
- The admin console and API are served over HTTPS only, with HTTP redirected.
- Delivery into your platform
- Filtered mail is handed 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. That connector is also what lets you restrict the platform to accepting mail from the gateway rather than straight off the internet.
- Authentication passthrough
- The gateway stamps the authentication result it determined, and strips any inbound Authentication-Results header claiming to be from us before adding our own, so a sender cannot simply assert that we validated them. ARC sealing of that result switches on once the domain's ARC key is published in DNS; until then the result is stamped but not sealed.
- Where message data is held
- Message data is held on infrastructure we operate. Access requires an authenticated administrative account with a role, and administrative activity is recorded.
Behavioral attachment analysis
Optional, off by default, and only active once you have built an analysis host of your own. Until then nothing described here happens.
-
Where a suspicious file goes
To an analysis host you operate, on hardware you control. It is not sent to us for analysis and not sent to an analysis service. If you choose to configure an external analysis provider instead, that provider becomes a sub-processor and the Trust Center says so.
-
Which files are eligible
Not all of them. Cheaper checks run first — file type, reputation, antivirus, structure, macros, archive contents — and only a file those cannot answer, on a message that already looks wrong, becomes a candidate. Most attachments are invoices, and running every one of them through behavioral analysis would cost a great deal and tell you almost nothing.
-
Isolation is your responsibility, and we say how
The analysis host should sit on its own network with no route to the gateway, the database, your management network or any customer network. Analysis guests revert to a clean snapshot after each job, so nothing from one analysis reaches the next. The console repeats this where the host is configured.
-
What is kept
The verdict, the behavioral evidence behind it and the file's hash are stored against the message so a decision can be explained later. Analysis artefacts themselves stay on your analysis host under its own configuration — we do not collect them.
Tenant isolation
Scoped at the data layer
Mail, quarantine, archive and reporting views enforce tenant and role scope according to the authenticated user, so isolation does not depend on the interface hiding things.
One tenant, one view
A tenant sees its own domains, quarantine, message tracking and reporting, and nothing belonging to another tenant.
Delegated customer access
A customer can hold a domain-administrator account scoped to their own domain, without visibility of the wider portfolio.
Policy stays with the domain
Thresholds, allow and block lists, which engines run and retention are set on the domain, so two customers under the same account do not share a policy.
Authentication, MFA and role-based access
Administrative access is protected through authenticated accounts, role controls, and MFA where enabled.
Roles
Platform administrator, tenant, domain administrator and read-only user, each limited to what that role needs.
Two-factor authentication
TOTP is available on any administrative account, with lockout on repeated failed sign-ins by account and by source address.
Sessions
Administrative sessions use signed tokens, and the console and API are reachable over HTTPS only.
Need security or vendor-risk information?
Security teams, MSPs and regulated organizations can contact us for the detail a review actually needs, answered against this deployment rather than from a template.
Assessment material
Security questionnaires, vendor-risk questions, architecture and data-flow detail, and technical control specifics.
Data handling
Retention and deletion behavior, tenant isolation, where data is processed, and the current subprocessors.
Deployment
Integration security, authentication and access questions for your own rollout.
Anything not covered here
If this page does not answer it, ask — we would rather answer the question than have you guess. Contact us.
Current service availability is on the status page, and the maturity of every product capability is on the feature status page.
If something goes wrong here
- Detection
- Mail flow is probed end to end every five minutes and every filter is exercised every fifteen, so a failure is found by a test rather than by a customer. Configuration drift, integration failures and DNS problems are checked daily and alert on findings only.
- Who is told
- An incident affecting your domains is communicated to the contacts on the account directly. We do not post a notice and hope it is read.
- Mail first
- The ordering rule when something breaks is that delivery outranks filtering. A scanning stage that cannot be reached is bypassed with the result recorded, rather than holding mail until somebody notices.
- Reporting a vulnerability
- Send it to us — see responsible disclosure, or the machine-readable contact at /security.txt. We will work with you and we will not threaten you for telling us.
- Assurance and vendor-risk questions
- Security teams and procurement reviewers can ask us directly about controls, architecture, data flow, retention and assurance. We answer specific questions rather than publishing a generic pack — send yours.
Credential and secret handling
- Administrator passwords
- Passwords are stored hashed, never in a recoverable form.
- Single sign-on
- The console accepts OpenID Connect, so your technicians sign in with the identity provider you already run — Microsoft Entra, Google, or any conformant OIDC provider — and offboarding somebody happens once, there, rather than in every tool. The sign-in uses the authorization code flow with PKCE, and each provider is configured with the email domains it is permitted to authenticate: a provider that could assert any address would be able to sign in as anyone. The provider establishes who somebody is; what they may do here comes from their account on this platform, and no identity provider can create a platform operator.
- Integration credentials
- Credentials for a Microsoft 365 or Google Workspace integration are encrypted, are never returned by the API once stored, and are never written to logs.
- Scope of platform permissions
- Tenant permissions are read-only and directory-scoped. No mailbox read or send permission is requested.
- Per-domain submission credentials
- Authenticated submission on port 587 uses a credential issued per domain, so it can be rotated or withdrawn for one domain without affecting others.
- Provider keys you supply
- An AI or attachment-reputation key belongs to your own provider account. You can revoke it at any time, and disabling the integration for a domain stops its use entirely.
- What is encrypted where it is stored
- Stored credentials — integration secrets, provider keys, submission passwords — are encrypted with a key held separately from the one that signs sessions, so rotating a signing key cannot make them unreadable. Database backups are encrypted to a public key and the plaintext shredded, so the machine that writes a backup cannot read the previous one. Message content itself is stored in the database rather than separately encrypted; what is retained and for how long is set out under retention below, and the honest summary is that an administrator of this platform can read a quarantined message.
Logging and administrative accountability
Key administrative and security-sensitive actions are recorded to support investigation and accountability.
Administrative audit trail
Sign-ins, quarantine releases from the console and from recipient links, allow-list additions, classifier training decisions and storage-allocation changes are recorded with the user, address and time. Each entry can be attributed and reviewed.
Per-message decision record
Every message carries each engine's score, what each stage found, and the total against the threshold that decided the action — the record an investigation actually needs.
Archive access auditing
On the archive add-on, searches and downloads are recorded, and each completed day is hashed into a chain so a later change to a sealed day is detectable.
Monitoring, backups and recovery
- Continuous health monitoring
- Automated health checks continuously validate the filtering pipeline and enabled scanning services, alerting on failure. How we validate filtering health.
- Signature and rule updates
- Virus and spam signature feeds refresh on a schedule. Application updates are applied by us; scanning is per message, so most updates do not interrupt delivery.
- Backups
- The database is backed up nightly, and the gateway is covered by nightly full-system image backups.
- Configuration control
- Mail routing configuration is version-controlled and continuously checked for drift against the running system.
- DNS supervision
- Each domain's MX, SPF, DKIM and DMARC records are checked on demand and swept daily, with an alert when a record changes underneath you.
- Mail-delivery resilience
- SMTP retry behavior and optional secondary routing provide mail-delivery resilience.
- Incident communication
- Incidents affecting your domains are communicated directly to the contacts on the account.
Optional integration data handling
Optional AI analysis uses the provider and credentials selected by the customer, and can be disabled per domain. Data processed by optional integrations is subject to the configuration and terms of the selected provider.
Off unless enabled
AI analysis is disabled unless it is turned on for a domain, and can be disabled per domain at any time.
Your key, your provider
You supply an OpenAI or Anthropic key. The commercial and data-processing relationship for that analysis is between you and them.
Only inconclusive mail
AI analysis runs only when the deterministic stages leave a message inconclusive, so most mail is decided without any AI call.
Third parties in the filtering path. Public DNS reputation operators receive the query inherent in a reputation lookup — the connecting IP address, not message content. Attachment reputation, if you enable it, runs on your own VirusTotal account and identifies a file by its hash rather than disclosing its contents. A list of sub-processors, including hosting, is available on request.
Vulnerability reporting
If you have found a security issue in MailThreatZero, we want to hear about it before anyone else does.
-
How to report
Use the contact form and choose Security vulnerability report, with enough detail to reproduce. Our security.txt points to the same place.
-
What to expect
We acknowledge your report, investigate it, and tell you when it is fixed. See the disclosure policy for how we handle reports and credit.
Security Reviews and Vendor Assessments
Security teams, MSPs and regulated organizations can ask us for the detail a review actually needs, answered against this deployment rather than from a template.
- Security questionnaires and vendor-risk questions
- Architecture and data-flow detail
- Retention, deletion and tenant-isolation specifics
- Technical control detail, including storage and access questions
- Deployment and integration security for your own rollout
- Current subprocessors — published rather than available on request
Send us the questionnaire, the control list or the architecture questions. You get a direct answer from the people who operate the platform.
Running a security review?
Talk to the people who operate the gateway about your mail flow, your controls and your evaluation.