Technical architecture
How the gateway is put together
Enough detail to evaluate the design: deployment model, mail flow, what runs at each stage, how tenants are separated, and what we integrate with.
Deployment architecture
Managed gateway
An SMTP gateway operated by us, addressed by your domain's MX record. Nothing is installed in your environment.
Multi-tenant
One platform serves many tenants and domains, with access scope applied in the data layer rather than only in the interface.
Per-message scanning
Each message is scanned as it passes through, so policy and scanning changes take effect without a service interruption.
Mail flow
- AcceptInbound SMTP connection accepted at the gateway
- AnalyzeFive core scanning stages, each using one or more engines
- DecideSignals combined against the domain's policy
- ActRelay to your platform, hold in quarantine, or reject
- RecordPer-engine breakdown kept for per-message investigation
Reputation and authentication are evaluated before content analysis, so the later stages know whether the sender is cryptographically verified. That ordering is what lets spoofing heuristics stand down for a verified sender, and it is the main false-positive control in the system.
Filtered mail is relayed to the destination you configure: an Exchange Online inbound connector, a Google Workspace inbound gateway, or any SMTP destination host and port. Authenticated submission on port 587 is available per domain for applications, devices and outbound routing, and outbound inspection and DLP are available for mail routed through the MailThreatZero gateway.
The scanning pipeline
Every enabled and applicable scanning stage runs for each message. Which engines are enabled, and how strict the policy is, are set per domain.
-
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 on the connecting address, IP and domain reputation scoring, GeoIP country and network policy, and connection rate limiting.
-
Sender authentication
Stop senders claiming to be a domain they do not control.
SPF evaluation, cryptographic DKIM signature verification against the published key, and DMARC policy handling with organizational-domain alignment. The result is ARC-sealed so your platform can trust our verdict rather than deriving its own from our address, and it informs the later stages.
-
Malware and attachment analysis
Catch malicious files and Office macros before they reach a mailbox.
Signature-based virus scanning with a second signature database available per domain, Office document and macro analysis, and attachment type and structure policy. Multi-engine attachment reputation is optional, on your own provider account.
-
Spam, phishing and content analysis
Filter bulk and deceptive mail without punishing legitimate newsletters and billing notices.
Rule and Bayesian spam scoring, collaborative fingerprint checks, URL reputation, and dedicated phishing, header and content filters. QR codes in images, PDFs and Office attachments are decoded and their destinations assessed. Checks that authentication makes redundant stand down for verified senders.
-
Optional AI analysis
Look at the messages rules find ambiguous — the targeted phishing and business email compromise that has no signature.
Runs only when the deterministic stages leave a message inconclusive, using the provider and credentials you select. Can be disabled per domain.
Decision model
Weighted, multi-signal scoring, not a chain of independent yes/no gates.
Contributions, not vetoes
Each engine contributes a score. Those scores are weighted and combined, and the result is evaluated against the policy set for that domain.
Malware is decisive
A confirmed malware detection is acted on in its own right, independently of the rest of the scoring.
Authentication-aware
Checks that only make sense for unverified senders are recorded rather than scored when the sender is cryptographically verified.
Set per domain
Which engines run, how strict the policy is, and the allow and block lists are configured per domain.
Fully explained
Every message carries a per-engine breakdown showing what each stage found and what produced the decision.
Monitor before enforcing
Monitor Mode scores and records every message while leaving delivery unchanged, so policy can be tuned against real mail first.
Data handling in the pipeline
- Message bodies
- Yes. Full message bodies are retained for 30 days to support quarantine review, release and per-message investigation.
- Tracking records
- Tracking records — sender, recipient, subject, size, sender IP, per-engine scores and the delivery decision — are retained for 90 days.
- Quarantine store
- Quarantined messages remain available for review until they are released or deleted; released and deleted items are removed 30 days afterwards.
- Temporary files
- A message may be written to a temporary file during malware scanning and is removed when the scan completes.
- Optional AI analysis
- 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.
- Transport encryption
- Mail connections use encrypted transport where supported and configured, and the administrative console and API are HTTPS only.
Tenant isolation and access
Scoped queries
Access scope is applied where data is read, so isolation does not depend on the interface hiding things.
Roles
Platform administrator, tenant, domain administrator and read-only user.
Two-factor
Administrative access is protected through authenticated accounts, role controls, and MFA where enabled, with lockout on repeated failed sign-ins.
Signed sessions
Administrative sessions use signed tokens over HTTPS.
Password storage
Passwords are stored hashed, never in a recoverable form.
Audit trail
Security-sensitive administrative actions are recorded to support investigation and accountability.
Operations and resiliency
- Signature updates
- Virus and spam signature feeds refresh on a schedule.
- Health monitoring
- Automated health checks continuously validate the filtering pipeline and enabled scanning services, with service state surfaced in the dashboard and alerting on failure.
- Backups
- Nightly database backups plus nightly full-system image backups.
- Configuration management
- Mail routing configuration is version-controlled and continuously checked for drift against the running system.
- Mail-delivery resilience
- SMTP retry behavior and optional secondary routing provide mail-delivery resilience.
- DNS supervision
- MX, SPF, DKIM and DMARC records are checked on demand and swept daily, with an alert when a record changes underneath you.
Supported integrations
Destination platforms
Microsoft 365, Google Workspace, Exchange, hosted providers such as cPanel-based mail, and customer-operated SMTP servers. If it accepts SMTP relay, it works.
Tenant integration
Mail is handed to your platform over its standard inbound path — an Exchange Online inbound connector or a Google Workspace inbound gateway, which is SMTP with TLS. That connector is configured inside your tenant, and it is what lets you restrict the platform to accepting mail from the gateway instead of straight off the internet. Mailboxes, users and licensing do not move.
Authentication passthrough (ARC)
The gateway records what it saw. Put anything in front of Microsoft 365 or Google Workspace and the platform starts evaluating SPF against the gateway rather than the real sender, so SPF fails for almost all inbound mail and DMARC fails with it — this is the single most common way a gateway deployment quietly degrades a tenant's security. We stamp the authentication result we determined, so your platform can trust our verdict instead of deriving a wrong one from our address. ARC sealing of that result is built and switches on for a domain once its ARC public key is published in DNS; until then the result is stamped but not sealed, because the gateway refuses to sign with a key it cannot resolve rather than emit a seal nobody can verify. We also strip any Authentication-Results header claiming to be from us before adding our own, because otherwise a sender could simply assert that we had validated them.
Pre-cutover verification
Before you touch MX, the setup wizard connects to your tenant and checks the five things that actually break an onboarding: that the application credentials work, that the domain is present and verified in the tenant, that public DNS points at the gateway, that the domain is configured here with a destination host, and — the one that matters most — that your platform will genuinely accept mail for a real mailbox from this gateway. That last check speaks to your mail server over the exact path filtered mail takes and stops at the envelope, so it proves the connector works without ever delivering a message. Each check returns a specific remedy rather than a bare pass or fail, and a check that could not run is reported as untested rather than counted as a pass. The tenant permissions are read-only and directory-scoped: Domain.Read.All on Microsoft, admin.directory.domain.readonly on Google. No mailbox read or send permission is requested. Integration credentials are encrypted, are never returned by the API once stored, and are never written to logs.
Direction of flow
Yes. Applications and devices can submit on port 587 with a per-domain SMTP credential, and outbound inspection is available for mail routed through the gateway: payment card numbers, US Social Security numbers and IBAN bank accounts, each validated by its own checksum rather than matched by shape, plus any patterns you configure. A message that trips a rule is held for review rather than bounced, so it can be examined and released.
AI providers
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.
API
The administrative API is REST over HTTPS with token authentication, published as an OpenAPI schema, and is what the console itself uses.
Reporting
Scheduled per-domain summary emails, plus dashboards and exportable reports.
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.
Want the deeper technical conversation?
We are happy to walk through the design, the deployment and the integration with your platform — and to answer security-review questions directly.