We hold other companies’ customer email. Here is exactly what that means.
Written for the person sent here to say no — and for the owner who just wants a straight answer. No badges, no shields. Where the mail lives, who can open a body, how deletion actually works, and the list of things we do not have yet, stated at full size.
Where your data lives
At rest: Canada. Message bodies, metadata and credentials live on Oracle Cloud Infrastructure in ca-toronto-1, operated by YS Progress Inc., a company registered in Canada. Jurisdiction is usually a reviewer’s first question, so it goes first: data at rest is under Canadian law, held by a Canadian legal entity, in a Canadian region. Encrypted backup snapshots (restic, encrypted client-side with keys held by YS Progress) are stored with Cloudflare R2.
In transit: through Cloudflare first. spoolway.com is proxied through Cloudflare — every request, including message bodies posted to the API, reaches the nearest edge node, TLS terminates there, and the traffic is re-encrypted to the Canadian origin. The certificate your browser sees is Cloudflare’s, and an edge node may be anywhere. Run dig spoolway.com and you’ll see exactly that — this page should survive the check, so it says so first.
One region today. If your review requires EU residency now, we are not your vendor yet, and we’d rather you know from this page than after you have signed a data processing agreement (the contract that says we handle your customers’ data only on your instructions).
body — the contents of an email. envelope — who it was to, and the delivery receipt. A non-sensitive subject stays with that metadata until the plan’s metadata window ends. A sensitive subject is deleted with the body. Application — one of your products (the billing site, the app). transport — the mail server or provider you already have. subprocessor — a company we use to run the computers or the network.
Encryption
Inside the database, the contents of every email, the variables sent with it, its attachments, and the passwords for your mail server are locked in a versioned envelope. The stored value names which key locked it, so it is not a bare encrypted column. A stolen backup is a different lock: each snapshot is encrypted on our side before upload (restic) and stored with Cloudflare R2, and those keys are held by YS Progress.
- Everything on the wire is encrypted — the API and the panel always, and sessions to your mail server whenever its transport is set to STARTTLS or implicit TLS (the same kind of lock as a bank website). A transport set to no encryption sends in the clear, and only because its settings say so.
- Transport credentials are never displayed again after saving — rotating one means pasting a new one.
- The keys that unlock the envelope live in one file on the server, readable only by the application user. It is not in git and not in the deploy payload — but it is inside the nightly backup root, which is why the envelope alone does not protect a stolen backup. The snapshot’s own encryption does. Restores are operator-only, and a restore can bring back data erased after that backup was taken; each backup is kept for 35 days. We would rather say that than claim an exclusion a reviewer would not find.
Who can see what
Viewers are free on every plan — nobody should share a login because a seat costs money.
An Application is one of your products. Scoping a person to one Application means a contractor sees that product’s mail and nothing else. That limit ships on Team and Enterprise; on Free, Pro and Scale a member sees every Application.
Each customer’s data is kept in its own locked room. If the software forgets which customer it is serving, it crashes in our tests rather than showing anyone else’s mail. For the engineer: a global query scope that throws when tenant context is missing, not one that silently returns everything:
pans sideways →Retention and deletion
You choose how long bodies are kept, down to zero. A non-sensitive subject stays with the metadata until the plan’s metadata window ends. A sensitive subject is deleted with the body.
After a body is deleted from the live archive, a copy can still exist in backups. The backup tail is 35 days. Then that copy is gone too.
Credentials and keys
Every key is narrow, belongs to a person and is revoked in one step. How each of those holds:
- API keys are hashed at rest — stored as a fingerprint, never as the secret itself, shown exactly once at creation. Prefix-indexed so we can look one up without storing the rest.
- No API key may carry both messages:send and messages:read-content, so a leaked sending key can send mail in your name, but it can never open a stored message body. Abilities are chosen when the key is created and cannot be widened later. There is no wildcard.
- Revocation is immediate, keys can carry an expiry, and every key belongs to a person — removing someone revokes their keys in the same action:
- Two-factor sign-in is available on every account, from your profile. It is encouraged, not required — and because this panel can decrypt bodies, we would turn it on.
No SOC 2. No ISO 27001. No third-party pen test yet.
A small team in Canada, stated at full size because hiding it would cost more than saying it. Certifications attest processes; we’re early enough that you can read the actual processes above instead. Here is the honest ledger:
Vulnerability disclosure
Report to [email protected]. You’ll get an acknowledgment within 2 business days, a fix or a dated plan within 14 days, and credit if you want it. No PGP key published yet — when there is one, it will live here. No bug bounty — we’d rather say that than imply one.
Subprocessors
The entire list is three. A subprocessor is a company we use to run the service — they see some of your data because they host the computers or sit on the network path.