Our own identity service
Sign-in runs on an identity service we host ourselves. Rykon Mail’s website never sees your password: it receives a signed token, verified against the service’s published keys, using PKCE, state and nonce checks.
Trust
Email holds a company’s most sensitive conversations. This is how we protect it, written from what the service actually does, with nothing claimed that the code does not prove.
Who you are is checked by our own identity service. What you may do is decided on our servers, on every request.
Sign-in runs on an identity service we host ourselves. Rykon Mail’s website never sees your password: it receives a signed token, verified against the service’s published keys, using PKCE, state and nonce checks.
Sign in with a passkey, and add an authenticator app or passkey as a second step. A new account works only after its email address is confirmed, and repeated failed attempts from one source are turned away.
A session is sealed with AES-256-GCM into a cookie limited to one host, HttpOnly, Secure and SameSite=Lax. It lasts at most 12 hours, whatever the browser does.
The operator console needs an internal account, a confirmed email address and an allowlist. A customer typing a staff address into their profile gets nothing.
The parts that can change customer mail are not on the public internet, and the browser holds nothing that could reach them.
The service that provisions domains, mailboxes and sending is reachable only over our private network. The public consoles talk to it from the server, never from your browser.
Every console operation is its own named server route that checks the session first. There is no generic proxy, and no control plane key ever reaches a browser.
A request that changes anything is refused unless its Origin is the console itself, as well as the cookie’s SameSite protection.
Services run as a non-root user. Our pages refuse to be framed by other sites (except hosted sign-up forms, which exist to be embedded), and send nosniff, referrer and permissions policies.
What we do not keep cannot leak. What we must keep is sealed to the record it belongs to.
A key holds 256 random bits and is shown exactly once. We store only its SHA-256 hash and compare in constant time, so a database copy cannot produce a working key. Keys carry only the scopes they need; an agent’s key reaches its own mailbox and nothing else.
A DNS provider token you connect is encrypted with AES-256-GCM and bound to its own record, so it cannot be moved to another account. Disconnecting destroys it.
A mailbox password exists only in the response that sets it. The one exception is an AI agent’s mailbox, which no person signs in to; its password is sealed the same way.
Passwords, tokens and keys are redacted from audit records whatever a caller passes in.
Each customer sends as itself. One account’s problems cannot reach another’s mail.
A domain is configured nowhere until its ownership record is seen at the domain’s own nameservers.
Each customer’s mail leaves through Amazon SES under its own verified identity, configuration set and credential, which may send only as that customer’s domains, with its own rate limit.
Bounce and complaint rates are read continuously. An account that crosses the threshold has its sending stopped before it can harm anyone else’s delivery.
Every campaign and automated email carries a standard one-click unsubscribe header and link, effective at once and never tracked.
Protection that does not track the people it protects.
Public sign-up forms are protected by a small calculation the visitor’s browser does while they type. Challenges are signed, bound to one form, expire in 30 minutes and are accepted once. No third-party script, no cookie.
Public forms and each API key are rate limited, generously enough that a person is never locked out, with an overall ceiling against floods.
Transactional mail sent through the API never goes to an address that bounced or complained, and to someone who unsubscribed only account, security, receipt or order mail; a message that reads as selling is refused.
AI features receive only what the task needs, never contact lists. The instructions the model follows are fixed on our servers, each account has a daily allowance, and generated studio text is cleared after 90 days.
What happened is written down where it cannot be rewritten, and the data can be brought back.
Every change is recorded with who made it and the outcome. The database refuses to alter or delete an audit record, even for its owner.
The database runs on two servers in two German data centres, one a synchronous standby of the other.
Backups are encrypted before they leave our servers and stored offsite. The whole database cluster is restored from them once a month to prove they work.
Servers, databases and mail storage are at Hetzner in Germany. Our subprocessors page lists everyone else and where.
Rykon Mail does not hold SOC 2, ISO 27001 or any other certification today, and has not been through an external audit. We will say so here when that changes, and not before. Our data processing addendum sets out how customers can review our measures in the meantime.
If you believe you have found a security issue, write to support@rykonmail.com with “Security” in the subject, and give us a reasonable time to fix it before telling anyone else. Please do not access other people’s data, disrupt the service or send mail as part of your testing. We will not take action against research done in good faith under these rules.