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.
If your product sends password resets or invoices, those emails hold your customers’ names and addresses. We keep a searchable copy so you can later answer did it go out, and what did it say? This page is how we hold that copy — and the list of certificates we do not have.
body — the contents of an email. envelope — who it was to, the subject, and the delivery receipt. 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.
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 Spoolway) 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. Region choice is planned and marked the way everything unbuilt is marked here — dashed, not promised. 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).
Encryption
The contents of every email, the personal details in templates, and the passwords for your mail server are stored so that a stolen backup cannot be read. For the engineer: not a bare encrypted column, but a versioned envelope — the stored value names which key locked it:
- 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 all of the above 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, so a restored backup can decrypt what it contains. 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
An Application is one of your products. Scoping a person to one Application means a contractor sees that product’s mail and nothing else. Viewers are free on every plan — which is a security feature wearing a pricing costume: nobody should share a login because a seat costs money.
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:
Retention and deletion
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
- 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.
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
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. The entire list is three: