Trust
What we can prove, and what we cannot
Everything a buyer normally has to ask for in a questionnaire, answered in one place — including the questions where the answer is no.
Last updated 2026-08-06.
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.
How to assess us
Everything on this page is verifiable rather than asserted: a documented architecture, a per-message decision record you can inspect, an administrative audit trail, published security and privacy policies, a disclosure process, and continuous automated validation of the filtering pipeline. None of it requires taking our word for anything.
What you can inspect
The architecture, the retention rules, the subprocessors, the validation methodology and the maturity of every capability are published, not held back for a sales call.
What we will not do
Claim a certification we do not hold, publish an uptime figure we do not measure, quote a detection rate from a lab test we did not run, or put a customer logo on this site without asking. If you see any of those here, it is a mistake and we want to know.
Assessing a supplier usually needs more than a public page. The operational answers a review asks for — operating entity, architecture, data locations, encryption, backups, tested recovery, tenant deletion and disclosure — are set out on the procurement and vendor review page, each one naming how it was established. Anything that page does not answer, send us: the questionnaire, the control list or the architecture questions get a direct answer from the people who operate the platform — security and data handling, or ask us directly.
Where your mail goes
Inbound mail reaches our gateway first, is scanned, and is relayed on to your mail platform. Nothing else is in the path unless you put it there.
In transit
TLS on both legs where the other side supports it, which every major mail platform does. Transport detail.
At rest
Message metadata and scoring for every message; message bodies only where quarantine, archiving or your retention settings call for it. What is retained, and for how long.
Between customers
Scoped at the query, not in the response. A tenant sees its own domains and nothing else, and the boundary is the domain rather than a label copied onto a row. Tenant isolation.
Sub-processors
Anyone other than us who can see any part of your data, and what they see. The full subprocessor register lists each one with its purpose, the data involved, whether it is required and where it operates.
- Hosting
- The gateway and its database run on infrastructure we operate. The hosting provider can reach the underlying machines, as any hosting provider can. Named on request.
- DNS reputation operators
- A reputation lookup discloses the connecting IP address of the sending server. Not message content, not recipients, not subjects. This is inherent to how blocklists work and applies to every gateway that uses them.
- Your AI provider, if you enable AI
- You supply the key and the account is yours, so the data-processing relationship is between you and them rather than through us. What is sent is governed by the privacy mode you choose, up to and including sending nothing at all. AI data handling.
- Your VirusTotal account, if you enable attachment reputation
- A file is identified by its hash. The file itself is not uploaded.
- Your own analysis host, if you enable behavioral attachment analysis
- Not a sub-processor at all, which is the point of listing it here. Behavioral analysis runs on hardware you operate. The attachment is not sent to us for analysis and not sent to any analysis service — if you have not built an analysis host, no behavioral analysis happens and attachments are judged by the reputation and static engines as before. An external analysis provider is offered as an option and is off unless you configure one, at which point it becomes a sub-processor and this page will say so.
- Nobody else
- No advertising network, no analytics broker, no data enrichment service, no resale of any kind. Your mail is not a product input.
Continuity
Backups are restore-tested
The database is dumped nightly and every dump is restored into a scratch database and row-counted before it is called a backup. A dump that cannot be restored is reported as a failure even though the file was written, because a file nobody has ever restored is a belief rather than a backup.
And encrypted
Each verified dump is encrypted to a public key and the plaintext shredded, so the process that writes a backup cannot read the previous one and a copy taken off the host is useless without the private key. Verified in the other direction too: every run proves the encrypted file still decrypts.
Mail delivery takes priority
Backups run without locking the tables the mail path writes to. If scanning cannot complete, the message is not silently discarded — the failure modes are documented in how we validate filtering health.
Configuration is version-controlled
Mail routing configuration is held in version control and continuously checked for drift against the running system, so a change nobody remembers making is visible rather than mysterious.
What is not covered
The nightly database backup covers the database. The quarantine and archive blob store, TLS material and system configuration are covered by machine image backups instead. We state the split rather than let "we have backups" imply more than it does.
Recovery objectives, measured
Database RPO up to 24 hours; database restore measured at 15 seconds on current data. Mail in flight has no RPO at all — inbound mail is queued on disk before scanning, so an outage delays mail rather than losing it. A full host rebuild takes hours and is not currently rehearsed, which we say rather than quote a number we have not tested.
Reporting a problem
Security issues
Tell us before you tell anyone else, and we will work with you. Responsible disclosure, and machine-readable contact details at /security.txt.
Anything else
Incidents affecting your domains are communicated to the contacts on the account directly rather than posted and hoped for. Contact us.
Everything, by the question it answers
Grouped the way a procurement review works rather than the way the site is organised. Every one of these is public: nothing here is behind an NDA or a sales call.
Service availability
- Service status — current availability, scheduled maintenance and incident history, each component checked against the service that provides it.
- Continuity and recovery objectives — how backups are taken, verified and restore-tested, with the measured RPO and RTO and what is not covered.
Security
- Security and data handling — mail flow, retention, transport, tenant isolation, credential handling, logging and audit.
- Responsible disclosure — how to report a vulnerability and what to expect back.
- security.txt — the machine-readable contact and policy record (RFC 9116).
- Security questionnaires — send yours; answers are published here rather than given only to you.
Privacy
- Privacy policy — what personal data passes through the gateway and the rights you have over it.
- Subprocessors — every company that can see any part of your data, what they see, and which optional integrations are accounts you hold rather than ours.
- Retention — what is kept, for how long, and what deletion actually removes.
- Where your mail goes — in transit, at rest, and how one tenant is kept out of another's data.
Product assurance
- Validation methodology — how filtering health is checked continuously, and what Monitor Mode does.
- Feature status — every capability and how finished it is, including the ones that are not built.
- Architecture — the mail path, engine categories, data flow and isolation model.
- Release notes — what changed in each release, and the version currently running.
Legal
- Terms of service — what the service does and what each side is responsible for.
- Acceptable use policy — what the gateway may and may not be used for.
- Data processing agreement — we do not publish a standard DPA today. Data-processing terms are available on request and form part of the customer agreement. Said plainly rather than implied, because a missing DPA is something you would find out at signature.
If your questionnaire asks something these pages do not answer, ask us and we will answer it here rather than only to you.
