What we hold, and who holds it.

Ruzayo privacy policy

Last updated: 7 August 2026. Subprocessor disclosure last reviewed 28 July 2026.

What we process

To operate the service we process account email addresses, the mailbox content you store with us, API usage metadata, delivery events (bounces and complaints reported by receiving mail servers and by feedback loops), and audit logs.

Separately from the mail service, this website records what you submit to the waitlist and contact forms — your email address, your name if you give one, the plan or topic you pick, and your message — together with the network address the submission came from, which is kept briefly to rate-limit abuse of the forms.

Where your mail is stored

Mail is received, stored and sent on servers we operate at Hetzner, in Germany. Inbound internet mail arrives at Postfix on port 25 and is written to Ruzayo's durable store on the same infrastructure. Outbound mail is delivered directly to the recipient's MX servers from those servers.

There is no third-party outbound relay. Your mail is not sent through Amazon SES, Brevo, or any other smarthost, and its content is not processed by any other provider in transit beyond the recipient's own mail servers.

Nobody reads a message body

No one at Ruzayo reads the body of a message. Not to build a feature, not to train a model, not once. We do not scan, classify or index message content: mail is refused or accepted at the door on alignment and reputation — what the sending domain published, and how it has behaved — and never on what a message says.

The delivery suppression list holds addresses and outcomes. Audit records hold actions, addresses, times and results. Neither holds content.

Where the software does not yet enforce that rule, we say so rather than let the paragraph above carry more weight than it has. The deployed mail edge has one operator credential that is not scope-limited: a request carrying it can read a stored message, and that read is written to no record you or we can later inspect. It is held in a root-owned file on the mail host and it is not used to read mail. Splitting it, so that the rule is enforced rather than only kept, is open work, and this page changes when that lands.

Support access

Ruzayo support has no standing access to your mailboxes. Access is granted one session at a time: we ask, the account owner approves, and the session expires after 60 minutes. It covers headers and metadata only — never a message body, never an attachment. There is no break-glass path and no exception during an incident. If we cannot diagnose a fault from headers and our own telemetry, we ask you.

Every such session belongs in your own record, as an archive.accessed entry naming the session number, what was read, and who approved it.

That record is not yet something you can open. There is no customer console today, and the deployed mail edge has no support-session mechanism, so access is requested and approved by email and held to the same 60 minutes by hand. The host keeps an append-only audit log of actions taken on mailboxes rather than of reads, and we will produce it on request. Until a session is a row you can read for yourself, the limits above are ours to keep rather than yours to check, and that is the less comfortable sentence of the two.

Subprocessors

That is the complete list. If it changes, this page changes with it.

We do not use Amazon SES, Brevo, or any other outbound relay. Earlier versions of this page said we did; that was wrong, and mail has always been sent direct from our own servers.

AWS is no longer a subprocessor. Waitlist and contact submissions were previously held in DynamoDB; they were moved to Firestore on 28 July 2026, and no Ruzayo data is processed by Amazon Web Services after that date. Mailbox content was never held there.

Where the service runs

Ruzayo runs one region, which we name eu-north-1, and offers no residency choice: there is no second region to move to and no option to ask for one. The servers under it are the Hetzner servers named above, in Germany, and the company is operated from Göteborg.

One part of this deployment is not EU-resident, and we will not describe it as though it were. This website, the two forms on it and the function behind them run on Google Cloud in us-central1, in the United States. What is held there is what you typed into the waitlist or contact form, together with the short-lived counter keyed to the network address you sent it from. No mailbox content, no message headers and no delivery events are held there, and no mail is ever sent from there. Moving the site into the EU is open work; until it is done, that is where a form submission goes.

Delivery events

When a message cannot be delivered, the receiving server returns a delivery status notification (RFC 3464), and some providers send abuse reports through feedback loops (RFC 5965). We record these to maintain a suppression list, so that we stop sending to addresses that have permanently failed or reported mail as unwanted. These events come from the receiving mail providers, not from a relay service.

Retention

Mailbox content is retained until you delete it or close the account. Audit logs and delivery events are retained for operational and abuse handling purposes.

Deletion

A mailbox is removed on request. It stops accepting mail at that moment, and the mail already held under it is destroyed at the end of a retention window. The length of that window is stated to you when you make the request, rather than left to be found on this page.

On this deployment that window is 30 days, and it is a floor rather than a deadline. A removed mailbox is held in a deleted state, and the edge refuses to destroy its data until 30 days have passed; destruction then runs as a separate, deliberate step and returns a receipt of what was removed. So held mail is kept for at least 30 days and is not guaranteed to be gone the moment the window closes. Our own standard is 7 days. This deployment does not meet it yet, and until it does, 30 days is the number that binds us.

The record of what happened outlives the mail: actions, addresses, times and outcomes, never message content. That is what makes it possible to show afterwards what was done and by whom. Our standard is to keep it for 90 days past the end of an account and no longer. Today it is an append-only log with no expiry configured, so it is kept until it is pruned by hand. Write to privacy@ruzayo.com for the record held under your account.

What we never measure

This site runs no analytics. There is no session recording, no scroll-depth or time-on-page measurement here or in the product, no third-party tag and no advertising pixel. The page's own content security policy permits scripts and network connections from this origin only, so a tracker could not load even if one were added by mistake.

We do not track email opens, in any form, including our own. Nothing we send you carries an open-tracking pixel or a link rewritten to count the click. A product whose argument is custody does not watch people read.

One third-party request remains. Every page on this site loads two typefaces from Google's font servers, which means Google sees the network address and browser of anyone who reads it. The request carries no cookie and no identifier we set. Serving those two files from this origin would end it, and that is open work.

Your rights

You can request access to, correction of, export of, or deletion of your personal data. Contact us at privacy@ruzayo.com.

Contact

privacy@ruzayo.com