Procurement and vendor review

Answers

Operating entity

MailThreatZero is operated by mspreboot.com, an infrastructure and managed-services operator. The contracting entity is confirmed in writing during review.
How this was established: Stated by the operator; matches the About page and the site-wide operator value.

Service architecture

An MX gateway in front of your existing mail platform. Inbound mail is accepted by the gateway, queued to disk, scanned, and relayed on to your platform. It is a multi-tenant deployment with tenant, domain, policy and quarantine separated in the schema. It is not an API-only add-on and does not replace your mailbox provider.
How this was established: Read from the deployed mail path: Postfix accepts and queues, then hands each message to the scanner as a post-queue content filter.

Data-processing locations

United States. Both the gateway and the public website answer on addresses registered to AS19531 (Nodes Direct), and both machines are virtual (KVM). That identifies the operator of record for the network; where the service is bought through a reseller the contracting entity may differ, and the specific data-center region is confirmed during review before it is treated as contractual.
How this was established: ARIN registration of the addresses the services actually answer on.

Current subprocessors

Listed in full on the subprocessor page, which separates the companies we engage to handle your data - which you cannot opt out of and keep the service - from optional integrations where the provider account is yours rather than ours. See the detail.
How this was established: Not duplicated here on purpose. The subprocessor page is the authoritative list and it distinguishes companies we engage from accounts you open in your own name. A second copy would be the one that goes stale.

Encryption in transit

The console and API are TLS-only. Inbound SMTP uses opportunistic TLS: it is offered and used whenever the sending server supports it, and mail from a server that does not is still accepted rather than rejected. That is the same trade-off every public MX makes, and it is stated rather than described as 'encrypted in transit' without qualification. Relay to your platform can be configured to require TLS.
How this was established: Read from the deployed Postfix TLS configuration.

Encryption of stored credentials

Provider credentials you supply - AI provider keys, connector secrets - are encrypted at rest and are never returned by the API once stored. User passwords are stored as hashes, not as recoverable secrets.
How this was established: Read from the credential store: values are written through an encrypt step and only a ciphertext column is populated.

Backup encryption

Every database backup is encrypted with a 4096-bit RSA GPG key. The public key used to encrypt lives on the service account; the private key required to decrypt is held on a separate keyring the service account cannot read.
How this was established: Confirmed against the stored files, which identify as PGP RSA 4096-bit encrypted, and against the two separate keyring paths in the backup job.

Backup frequency and retention

Nightly. Retained daily for a fortnight, then weekly for a quarter, with each run reporting how many files it removed. The backup covers the database - every message record, policy, decision and audit trail - and the archive's stored message content, so a restore returns the archived messages themselves and not only the index of them. Quarantined message bodies are held in the database and are covered with it. Not covered: TLS material and system configuration, which are covered by machine-image backups instead.
How this was established: Read from the scheduled job and its retention policy; file listing confirms nightly files present. The archive half was verified by restoring the encrypted blob backup and checking all 123 stored objects against the SHA-256 the database records for each: 123 verified, 0 missing, 0 mismatched.

Off-host backup copies

Provided during security review.
How this was established: Deliberately null, and more specific than it was: the database, the archived message content and every backup file all sit on the SAME filesystem - one partition on one virtual disk - so a lost volume takes the data and its backups together. Verified by comparing device ids, not assumed. Encryption and the nightly restore test protect against a corrupt or unreadable dump; neither protects against losing the volume. The host is a VM, so the underlying storage may be redundant at the hypervisor, which cannot be confirmed from inside it. Saying 'we have backups' without this qualification would be the misleading half of a true statement. Off-host arrangements are agreed during review.

Tested recovery status

Every nightly backup is restore-tested before it is encrypted, and the run exits non-zero if the restore fails - so a backup that cannot be restored is a failure that night rather than a discovery during an incident. A full host rebuild is not currently rehearsed, and we say so rather than quote a number we have not tested.
How this was established: Read from the backup job: verification is on by default and the scheduled run does not disable it.

Recovery point and recovery time objectives

Measured, not contractual: database RPO up to 24 hours, database restore measured at 15 seconds on current data. Mail in flight has no RPO - inbound mail is queued to disk before scanning, so an outage delays mail rather than losing it. A full host rebuild takes hours and is not rehearsed. Contractual RPO/RTO terms are provided during security review; none are published because none have been agreed.
How this was established: Restore time measured on a current dump. RPO follows from the nightly schedule. The host-rebuild figure is deliberately absent.

Tenant deletion behavior

Deleting a tenant removes its users and, through them, their domains, along with the tenant's rules, filter configuration, AI configuration, per-tenant spam-filter training and hourly statistics. Domains marked as protected infrastructure are the exception: the database refuses to delete a user or a tenant that holds one, rather than removing it quietly. Deletion is an operator action, not a self-service button.
How this was established: Enumerated from the live foreign-key rules (seven cascade to tenants) and the three installed protection triggers, which were confirmed to refuse the delete rather than being assumed to.

Security incident contact

The contact form, marked security, reaches the people who operate the platform directly. An incident affecting your domains is communicated to the contact on the account. There is no separate paid support tier that reaches someone faster.
How this was established: Contact routing confirmed; matches the published security.txt contact.

Responsible disclosure

A published policy with a machine-readable security.txt at /.well-known/security.txt naming the contact, the policy URL and the canonical location. See the detail.
How this was established: Both files are published and were read as served.

Feature maturity

Every capability is published with its maturity - generally available, production validation, or not built - rather than described uniformly as available. See the detail.
How this was established: The registry is checked against the code on every deploy: a capability marked generally available must name the module that implements it.

Public service status

A public status page listing each component, read live from the gateway's own status endpoint. See the detail.
How this was established: Independent third-party monitoring is not deployed. Because the status endpoint runs on the gateway, it cannot report a total gateway outage; the page says so.

Data processing agreement

No standard DPA is published today. Data-processing terms are available on request and form part of the customer agreement. Said plainly, because a missing DPA is otherwise something you find out at signature.
How this was established: Current commercial position, stated by the operator.

Vendor questionnaire process

Send the questionnaire, control list or architecture questions through the contact form and they are answered directly by the people who operate the platform. There is no portal and no NDA gate for the questions this page already answers. Where the answer is that a control does not exist, that is the answer you get.
How this was established: Current process, stated by the operator.