Trust & data

Your mail routes through us.
Here is exactly what that means.

A filtering service sits in a position of enormous trust. We think the only honest response is to be specific — about what we hold, for how long, and what we never touch.

The line we don't cross: message bodies are never stored, never shown, never read. This isn't a policy that could quietly change — it's how the system is built. The customer website and its API have no access to message content; that capability doesn't exist on the public surface. What you see in the site (and what our staff tools see through it) is metadata: sender, routing, subject, score, and the checks that fired.

What we hold, and for how long

Data	What it includes	Kept for
Message record	Sender address, recipient address, subject line, sending server (IP / network / country), spam score, the checks that fired, and what we did (delivered / held / rejected). No body, no attachments, no content.	90 days, then deleted
Held-mail delivery copy	For borderline mail we hold, a full copy exists so it can still be delivered if you release it. It is stored for delivery, not read for filtering-after-the-fact.	~14 days, then purged — after that only the metadata record remains
Account data	Your domain, delivery server, team members, allow/block lists, and the optional business context you give us.	Life of the account + a short grace window after closing

"What if you go down?"

The question every MX-based service should answer up front. Email is designed for exactly this: when a receiving server is unreachable, sending servers queue the message and retry automatically — typically for at least several days — before anything bounces. An outage on our side therefore delays mail; it does not lose it. Combined with the setup flow (we confirm delivery to your server with a coded test email before you change DNS), there is no step in the lifecycle where your mail can silently disappear.

Separation of duties, by architecture

The customer-facing site talks to a deliberately limited API: it can read metadata, release held mail, and manage your lists — and nothing else. Privileged operations live on a separate, network-isolated internal system. The public surface can't leak what it was never given.

You can always leave — with your data

Lock-in is a trust failure. The account page includes a guided exit that walks you through repointing your MX before filtering stops (so no mail is lost in the hand-off), gives you a CSV export of your lists and message history, and only then closes the account.

Infrastructure